I'm making a quick Google App Engine program that presents a publicly available form that users can fill out with their name and email address, then can enter a friend's name and e-mail address. The application pulls in the data via POST, then sends a pre-formatted e-mail like 'Hi, , your friend wants to invite you...'
What should I be doing to prevent spammers from exploiting this publicly facing e-mail sending program? Is there a good resource for best-practices in this field? I've spent a few hours searching, but I haven't really found anything definitive...
Principally creating a publicly available form that anyone can use to send[s] a pre-formatted e-mail is another name for creating a spam machine.
You can mitigate by making it harder for non-humans to use it, recaptcha is the typical way to achieve this.
You could send a confirmation email to the sender and require a secondary action (like clicking a link) before sending the email. Or, if you expect your users to return, ask them to sign up (with a similar confirmation) before allowing them to send email.
I would first impose some limit to the # of email addresses a specific user/IP can send. This won't solve the problem but will limit the damage in case someone does try to send spam to 1000 emails.
Second, you could try sending the emails in small batches if an user puts in a lot of email addresses. Send 5 at a time, and monitor to see if there's any spam complaints (you can probably automate this somehow). If no complaints after 2 days, keep sending the rest.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In Cuba, web access is extremely censored, so I created a tool that allows more than 50,000 people to browse the Internet through email. Cubans send me an email with an URL in the subject line, and I email them back with the response. Read more at https://apretaste.com.
It was working like a charm, till the communist government of Cuba started blocking my emails. My solution was rotation.
I started with Amazon SES, and I was changing the domain each time it was blocked, but Amazon adds a header to all emails, and once they blocked the header no email from SES was able to reach Cuba any more. The same happened with Mailgun and others, they all add headers.
Currently I am creating Gmail accounts and sending via SMTP, but Google blocks me for no reason and only allows to send 100 emails a day per account. Also I can only create few emails using the same IP address/phone, so I was forced to use anonymous proxies and fake Chinese phones. Now I am fighting a war on two fronts.
An email can be blocked by three parameters: IP address, domain, and email address.
It will be terrific if I can set up my own Postfix server at a VPS that auto-rotates the IP address. Even better if I can simulate "gmail.com", to avoid purchasing a new domain every day.
All the intents to create what I call "the ultimate sender" just either reach the spam folder or add unwanted headers making it too easy to block. I feel exhausted. I hit a knowledge barrier here.
I know I am crossing to the dark side, but this is for a very good cause. Thousands count on this service as their only source of unbiased news, social network and to feel part of the 21st century.
Can you please help me implementing "the ultimate sender", or pointing to another solution that I may be missing?
I have a few suggestions for you.
The first one relies on The Onion Router also known as Tor.
Since you are crossing to the dark side, why not also take a look into the darknet?
Take a look at this list of Tor email providers. If you have your own email server that can be accessed through Tor, it becomes much harder for anybody to stop people from using this service. After all, Tor was developed to offer people uncensored access to the web.
You can read about Tor in detail here, it uses Onion Routing and this is how you would set up your server to use Tor.
Here is an example how you could use it:
The steps that involve the setup, receiving an URL request and sending back the reply are as follows:
Set up an email server.
Configure your email server to use Tor.
Publish the public service name. (e.g. "duskgytldkxiuqc6.onion")
Deploy a client that takes the service name and a URL, and let it send an email with a request to your server.
The client now waits for a reply.
You send a reply and the client receives it.
You can change your service name on a regular basis, but you need to make it accessible to those who will use this service.
Having an own email server means being able to control the email header.
Here is one example how you could make use of it:
Configure your email server so that it receives and recognizes
emails which contain the requested URLs.
Before you send a reply modify the email header so that it shows a random IP address and a random sender email address including a random domain name.
Send your reply.
Sending an email that way means that you cannot be replied back to. But since your reply already contains the requested information there is no need to.
I hope this helps.
Crowd source it.
Find a way that volunteers can send some emails for you. This is the only long term approach that I can think of. A simple web interface with mail to links would be be enough to get started although there are other potential problems with this approach too.
Because you are talking about low numbers of users, you could also use crowdsourcing to create the single email address per person approach. They can create an account on a specific set of email providers and give you the credentials. This would allow the single email per user approach or could be used to rotate through a large set of email accounts to send emails.
The simplest solution is perhaps to set up a local SMTP server on your own computer. You don't even need a server per se.
https://sourceforge.net/projects/winsmtpserver/
There are many other such applications. They are usually used to test SMTP functions during local development, but there is nothing against actually sending spam through them.
I know this would be quite a large task, but how about pairing the users with one or just a few emails so they always receive an email from that email.
I'd assume people wouldn't have more than 100 queries per day, if so they could start receiving them from a backup email
I'd imagine it would look less suspicious for them to appear to be in constant contact with one unique email rather than 50,000 being in contact with one
I know this would be a huge undertaking, but I feel like it solves your issue.
Since the users are willing to receive emails form you then your shouldn't be blocked.
When you mentioned you are getting block does it mean your mail is going in spam or is getting lost in between sending and receiving or it is getting bounced back??
My suggestion would be to setup your own mail server and follow as below:
-Get approx 25 or more ip to rotate. (IP is the most imp part which is tracked and is accountable for the reputation of your mail server)
Don't start sending emails in bulk from the word go it is better to gradullay increase the email volume so that mail server reputation nicely built
keep changing the format of the email often
encourage user to add yourself to there contact list
your best part is user are willing to receive emails from you and you would reply to revived email is the USP of yours but still i will recommend you to register for FBL so that you would know which user is reporting you as spam and you can remove him from your list and never send him email again.
using best practice to send emails like dkim, SPF, dmarc are also vital.
Hope my answer was of some help to you. If you need step by step guide to step up mail server let me know.
My friend, do you remember what made Hillary Clinton lose the last elections to Trump?
It was the "mail" affair. And what was it? People discovered she shared confidential information through a non-official, non-governmental email account (i.e., she used some Gmail, Yahoo or another of a kind). Until here, nothing new with direct relation to your matters. But there is an small particularity on this history, and this can put, maybe not a solution, but maybe a light on a new path you could follow: Clinton actually never sent those emails; the email account she used had the password shared and the communication between people (Clinton-someone) occurred only using the drafts of the account.
How? One side logs in and accesses the drafts folder. There he/she reads the last message and edits it, cutting and writing new data - then save the draft message. On the next turn, the other side of the communication line logs in and do the same. And so forth, so never really sending those messages, but instead just updating the drafts (this "Hillary" method does schooled people... Dilma Rousseff, impeached ex-president of Brazil, actually did this method down there in Brazil too).
So, maybe if you could establish a pact with your user that he/she doesn't delete the account's password, you could pass those information by this method - without "really" exchanging emails. Maybe a "parent" email account (some that could reset a lost password) could be useful too.
Alternative: aren't you able to contract a regular HTTP webserver? You could rely on FTP to publish data to your user, he/she asks for it and you publish a page with that content.
Salvi, have you tried something with Telnet? OK, we are talking here about a text-only environment, but if nothing more would rest in the future, this could be better than nothing. Maybe you could implement a podcast-like, or push-like service based on it. Look what people do with it with references to your walk on the dark side...
If in Windows, open your command prompt.
Type telnet and press Enter.
Type "o" without quotes and press Enter.
Type "towel.blinkenlights.nl" without the quotes and press Enter.
My company is developing a cloud contact management service and on our iOS app we're having some problems launching a particular enterprise email client app when the user presses the "Email" button on one of their contacts.
One member of our team came up with an idea to get around the problems with this enterprise app:
We let the user specify their email address in the app's settings and create our own email composing screen. Tapping the email button on a contact would open the composing screen, they would write their message and then we would send it on their behalf from our servers (or via service like mailchimp).
Basically, this would mean we would have to create an endpoint on our api that would accept a POST request with 'from', 'to', 'subject', and 'body' fields which would send the appropriate email.
This seems like a very bad idea as it's essentially creating a free, anonymous email service that could easily be abused send spam.
A few extra notes about our setup:
We don't verify an accounts email when they sign up
Even if we did verify the account's email, the user would need to be able to specify any email, as they may have signed up with personal email, but want to email someone from their work email.
Our API doesn't currently have any kind of rate limiting
Instead of having a from field in the request, we could instead send the id of the contact they want to email. This doesn't really change anything because if someone wants to abuse the send email endpoint they can also abuse the create contact endpoint.
So exactly how much of a bad idea is this, and how can I convince my team not to do this?
A few thoughts against doing it:
This is the perfect spamming service, which could damage the reputation of your company (reputational risk).
Your email servers would very quickly make it into blacklists (RBLs), making your outgoing emails land in spam folders in very many recipients' mailboxes.
Even if your servers are not yet in RBLs, if you send a forged email like that and proper email security is set up at the recipient end, your emails will still have a good chance to get classified as spam. Have a look at things like SPF and DKIM.
This could even have legal implications. Imagine the scenario when one of your users uses this service for something like blackmail. Would you be able to prove it was not you? Probably yes with the right controls, but would you want the hassle?
Still on the legal side, many countries (the EU, mainly) have data protection regulations which strictly control how personal data like email addresses can be used, especially for commercial advertisement. You probably want to adhere to that, but that would be hard with such a service (note that I'm not a lawyer, in such a case it's probably the abuser of your service that would offend these regulations and not you, I don't know, but it's something to consider).
If anyone can just send emails, it will be fairly easy to perform a denial of service attack against your services.
A few controls you could implement to mitigate some risks:
When adding a sender (from) address, you should validate that by for example sending a (cryptographically random) token and checking if the user can send it back (eg. by clicking a link in the email). If he can, that proves to some extent that he controls the email address and is probably a valid sender.
Limit the possible recipient addresses if you can. The best would be if recipients had to opt in to receive emails. If this is not possible, at least let recipients opt out from further emails. For this, you would have to add something like a footer to emails with "never again" links, and implement a facility to maintain recipients to which you must not send anymore.
Implement rate limiting. Depending on your exact scenario and use case, only allow to send the least number of emails acceptable for your application.
Implement proper logging so that you have an audit log of who exactly sent what email to whom. For this, log metadata like IP addresses as well. For this, you will likely have to authenticate your users.
On an operational level, have monitoring in place, and be prepared to ban offending users, based on a clear ToS shared with your users.
I created event registration web sites (you can imagine something like http://www.eventbrite.com/), which allow users to subscribe for event updates. When subscribed, we send mass emails (with the same content) to those users.
It was ok before, but recently I noticed that GMail always put the email into Spam folder.
As any texts would always go to Spam folder, I suspect that my domain was blacklisted by Gmail.
1) Is there a way to request google to put my domain into the whitelist?
2) Let's say it can't and I decide to register for new domain.
Is there a way to avoid the mass email to be marked as spam by Gmail? (may be something like what Facebook email notification do?)
Yes, don't send mass email :-) If you really want to avoid being considered a spammer, send out emails with less recipients, and don't swamp the mail server with them. Let's say, for example, you have thirty recipients for a given update. You can send out emails with one recipient every minute for a half hour.
Now the numbers may be different (and will of course depend on the success of your site) but the basic theory will stand up for quite a while.
As to how to get yourself whitelisted in GMail, that's really up to the recipient. They can usually do it by simply adding your email address to their contact list.
Keep in mind whitelisting there refers to individual GMail accounts, GMail itself does not whitelist IP addresses.
It does blacklist them if you misbehave but that generally means you get delivery rejects when trying to send. The fact that your messages are going in to the mail system and being delivered to spam folders indicates that this is an account-based thing, not a global GMail blacklisting of your IP/domain.
In any case, the place to report problems for GMail delivery problems is here.
As a school, we send out mass emails to our parents about events and issues. There's no way we have the time to spend sending out one email per minute. What we did was sign up with AOL as a business account, and we are allowed to do "bulk mailings" until they get multiple complaints. However, gmail clients usually have to list us as a valid sender or else those emails end up in spam folders. Works the same for clients using college alumni accounts from edu addresses. Gmail is the only one who regularly gives us this problem for our recipients on their email servers. We let parents know at orientation that they will have to specifically admit our emails via some setting on gmail.
First, let me get this out of the way and say this isn't a spam application. I'm writing an app that allows users to share files with multiple friends easily via email.
Right now, I'm using SKPSMTPMessage to send out emails to a list of recipients at the user's request. It works, but I wonder if there isn't a better solution here. For example, if it might be better to send the smtp info and attachments to my server, and conduct the sending from there in order to avoid repetitive attachment uploads on the device.
I am also considering how to handle cases where there is no connection available (determining connection error vs other kinds of errors and persisting the failed message for a later retry).
Any advice on the best way to structure this service would be greatly appreciated.
In order to customize the user experience for sending e-mail you need access to their email details, IMAP, POP, etc. if you want that user to be the one sending the e-mail.
The solution I use is to have the from address be an e-mail I control and use a 3rd party email provider, ex: SendGrid, PostMark, Mandrill and plug in to their api's to send e-mails.
Let say I have a website that allows users to send articles on that website to a friend.
The way it works is that when the "send to a friend" link is clicked a form appears and it allows users to fill in the details and an email is sent to their friend.
The user can put in a "from" email address and a "to" email address into this form and a small amount of content.
When the email is received the from email address appears in the FROM and REPLY TO.
This website also sends a great deal of its own email communications to its users.
My question is:
Is there risk to allowing users (bots, attacks etc) to use this application to send emails from my SMTP, and how great is the risk?
My assumption is yes, this is not ideal.
Is it possibly worse than "not ideal"?
I do not know about bots using your form. Should it be a problem? I don't know.. I do know they program bots to be pretty clever, using your custom forms and all.
I do know that some email servers check if the FROM email address has the same IP address as the IP the mail was sent from. So imagine I put in my hotmail email address, and the mail server sees your server, it might flag the email as spam.
In the past I've an e-card websystem. It was a small joint venture with a girl I knew. She created the (cute) cards and I build her an e-card system. The website was pretty simple. Select card, enter email address, placing senders email address in the FROM and sent the email that you would have received an e-card.
Life was good...
Until I found that my entire web server IP was blacklisted at three major spam filtering mechanisms. And that 15% of all email recipients who used to receive e-cards from my site, would not receive their e-cards, because all my emails were blacklisted as spam from the get go. We have receive many many emails from angry "customers" demanding that their e-cards did not arrive. (I still find it funny how some people demanded the service, especially since it was a free service, go figure). My automatic reminder function was telling them the e-card still were not viewed, and they perhaps mistyped the email address, so that might have ticked them off :P
It was pretty annoying for my other customers as well, since they relied on sending out played newsletters and such and calling me that over 20% of the customers did not receive the newsletters.
Sending e-mails is hard. You should also check out Jeff's blog about this. So, learn from my mistake, and please put an email address associated with your email server in the FROM. This will spare you a lot of headaches ;)
yes this is definitely not ideal if this is a public website that any bot can access. but there are easy ways for you to limit spam use.
have your code limit any email
address to send ~50 emails a day and
only ~10 an hour based on your
needs. a bot would probably try to
send a million at once so limit them
on an hourly and daily basis.
store every email communication in a
database and come up with a good
program to monitor the most active
email senders. if you can verify
that an email is trusted, then let
them send as many emails as they
want
think about this site itself, it has very defined actions and reputation guidelines that limit you until you have proved you are trusted.
It may depend on whether you do any authentication to determine who's allowed to send emails. If the user has to be logged in to send articles, then you're probably fine. Bots will fail because they'll never be logged in.
The risk will increase the greater traffic you get to your site, and yes it's probably less than ideal. Unprotected, a bot will inevitably find your unprotected form, and start sending emails from your server.
There are some pretty easy solutions though, the most common probably being to implement something like Captcha
Fairly safe. I assume you do check the "From" address, if only by sending it one (standard!) mail first and asking the owner of that email address to confirm they are really humans ? This prevents most bots from finding and abusing your form. Of course, a directed attack with a human responding to your verification email will still allow spamming. But you've got a much better trail if you have received at least one reply from the alleged "From" address.
However, I don't think this will work reliably. The introduction of techniques like SPF will mean that mails from "example.com" will only be accepted if they originate from an outgoing SMTP server in the *.example.com domain. If you're faking emails with From: addresses #example.com, the receiving SMTP server will see that you are in fact not part of *.example.com and reject the email - and probably blacklist your IP range for good measure.