Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I just want to ask you why is email activation useful. I mean when you register on a website, many ask you to activate your account by email. Is this for preventing spam, or just for websites to be sure you entered a real email address, to send you emails in the future? If it is for spam, how is that preventing spam, cant bots access mail, or what?
EMail activation is primarily used to ensure that you're signing up with a "real" email address, and also one that you have access to (and therefore, presumably, are the legitimate "owner" of the email address).
This enables the website to be able to contact you at some later date since it now has a legitimate email address for you, the user. This can be used for password resets, or general communication etc.
EMail activation also effectively prevents you from signing up your friend/enemy even though you know their email address, unless you also have access to their email account, which is unlikely.
This is mostly used to stop one person from registering another person's email address with a site in order to generate spam from the site to the innocent victim. Most website's that employ such "email validation" will ignore sign-up requests unless they are "verified", usually by clicking a "secret" link or entering a "secret" code back on the website that is originally sent in the email message.
Many legitimate website users are sometimes distrustful of giving their "real" email address to websites for fear that they themselves will recieve spam from the website. Many times, this depends upon the user's trust of the website that they are visiting.
To this end, there are a number of services (such as Mailinator, SpamGourmet, and many others) that legitimate and non-legitimate users alike can employ to provide a "real" email address that is accessible by the user, yet also disposable and temporary to allow the user to ensure that they recieve no spam to their real email address.
This, to some degree, can defeat the effectiveness of an "email validation" system employed by a website, since the website now cannot guarantee that the user (identified by the email address) is "genuine" (i.e. it's not a "throwaway" email address). To this end, many website will prevent users from registering with an email address on a known "disposable" domain.
It verifies the supplied e-mail address and also prevents registering somebody else for an account or mail-list.
At least: If you forget your password, a password reset link can be sent to that email address.
There are many reasons
That way you can make sure password recovery can be done
You can be sure someone will not register someone else email to spam him
You will be protected from spambot
I think its for both , i.e to avoid spams and to make sure that you have entered a valid email address that you have access to
Well, I suppose the main reason is spam prevention and password retrieval, but if your users do something illegal, you might want to identify them.
It sure helps to ensure a valid email addresses but also helps to avoid bots that automatically register and then proceed to spam forums etc.
I'd say it's a mechanism to keep "one-stop users" away, as you have to enter a valid email adress which you have to be able to check to gain access to the website.
Related
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'm building a membership system keyed by email address. I.e. Email/password.
As I do it there is always this niggling concern in the back of my mind that a spammer is going to bot my forms and use them to verify email addresses somehow.
For example, if I put an ajax email checker on the registration form which goes off and asks the server if we have this email address on file already, I envisage someone might trivially throw email addresses at it and take note of the ones which return true/false, then go off and use that information for their own evil purposes.
Another example, for the forgot password routine, rather than a non-committal 'We may or may not have that email address on file' it is nice to tell the genuine user that we really did find their email on file and sent them their password. But again I worry about bad people submitting lots of email addresses and using the +/- response for their own purposes.
Third example, the way the login form reacts to bad passwords or unknown email addresses also can throw off hints as to whether the email address is a known and active user, or not.
Is this something I should actually worry about? Or am I just making life hard for my users and myself?
Yes you should be concerned, even if you have a few emails in comparison to FB the security of your users is your responsibility. Don't let laxadasical attitudes deter you from seeking the best security you can find for your site and users.
Do you think you're going to have a significant proportion of the world's email addresses in your system? If not, then I don't think this is a concern.
Facebook might need to worry about this, not you. You will only have a tiny insignificant fraction of the world's email addresses, so using your db to check addresses will be futile.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
As per this question I asked previously on Google App Engine, if I have access to all the information in a standard email, not just the From, To, Subject, Body fields, but also all the headers and MIME information, how can I verify that two incoming emails with the same From address are actually from the same sender.
What I've considered thus far:
Check the IP address of the email's sending server
Check the DNS records of the email's sending server
Verify the sending agent of the email (i.e. web interface, Outlook, Thunderbird, etc)
Check the reply-to field
Etc.
I realize this is a complicated question (I'm sure companies like Posterous have spent tons of time on this problem). I'm just looking for a few criteria to get started preliminarily. Thanks!
Update:
The answers so far are really helping, but just to help them out, the context of my project is that I would be receiving tons and tons of email as a web app from my users. They would use their email as the primary way of inputting data into my system. This I why I made the Posterous analogy. The use case is very similar.
You're right that all of the headers together, and 'known good' email to compare to can help identify likely spoofed emails.
What you're developing would probably be at best a heuristic rather than an algorithm.
I'd consider weighting the fields by time-of-day and how close to 'known good' emails' time-of-day ...
Also, if the 'known good' emails are structured differently than the suspect; i.e. Inline images, html, shortened url's, etc.
Why not run the emails through spamassassin or some such filter that will attach a bayes score. You can then just read that score. It will save you reinventing the wheel.
You could bayes score the email against a database of all previous emails from the individual.
There is also looking up the Sender Permitted Framework and DomainKeys, which SpamAssassin can do for you.
Probably not practical but something that would work:
When an incoming mail arrives, have a "reply to sender" function and simply ask if they sent it. This could be in the form of a confirmation link that is automatically generated or something.
But since I don't know the specifics of the project this may not be practical... like if you had to do this multiple times for each user, no one would put up with it.
Just to compliment my brothers posting earlier:
Not knowing the context under which you want to analyse this, and being very general I would suggest your first port of call is SPF or DomainKeys in order to limit the possibility of email coming from a rogue source being accepted. I would also recommend using only one SMTP server with SSL security. I do this and travelling worldwide I have rarely been in a situation I couldn't send mail and in those cases the only thing that did work was webmail (no safe local SMTP).
Additionally to that: if you are verifying mail is really coming from yourself then you could also use PGP tools to sign your mail upon sending and then filter any mail that didn't have a valid signature. Enigmail in Thunderbird is a good source of automatic signing and there are plugins for Outlook as well.
After that if you really want to do a more forensic job on an email then you could use a Spam Bayes to score the email against a database of previous emails. You would build up a database of tokens around the non-unique data (excluding entries such as "To:") and then score the email for the probability that it is like the previous emails. In theory you should score very highly for any mail.
Obviously I don't know your situation, but I think that there are many techniques but sometimes it is easier to go to the root of the issue than try and fix it down the line.
Update
Based on the context supplied:
I would consider using "Address Extensions" this is where your user can send mail to an address which contains a reference using the email address: emailname+extension#domain.com
GMail and many other servers support delivery of email with a +extension# through to the correct emailname#domain.com without hi-jinx. You could get the user to deliver mail with a unique ID as the extension and that way you would know it had come from them and they would feel more special. Obviously someone could steal their unique code by sniffing their outgoing or your incoming mail but that is always possible and if someone can do that they can probably inject mail as well.
If you really just want to go down the analysis route then I would suggest just using the reverse of a SpamAssassin per-user Bayes match. Where you compare every mail to a database of mails from a sender (instead of the traditional matching of mails 'to' an account). Remembering that once your database is polluted with a false positive you will have to remove the false positive or risk the integrity of the matching for that sender.
Maybe look into using Sender Policy Framework. It might not be exactly what you are looking for but it might help.
Briefly, the design intent of the SPF record is to allow a receiving MTA (Message Transfer Agent) to interrogate the Name Server of the domain which appears in the email (the sender) and determine if the originating IP of the mail (the source) is authorized to send mail for the sender's domain.
Ripped from wikipedia:
Sender Policy Framework (SPF), as
defined in RFC 4408, is an e-mail
validation system designed to prevent
e-mail spam by addressing a common
vulnerability, source address
spoofing. SPF allows e-mail
administrators the ability to specify
which Internet hosts are allowed to
send e-mail claiming to originate from
that domain by creating a specific DNS
SPF record in the public DNS record.
Mail exchangers then use the DNS
record to verify the sender's identity
against the list published by the
e-mail administrator.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have my domain's email set up with Google Apps, and I am interested in sending automated emails (when users register, for example) with the From and/or Reply-To field being "no-reply#example.com". I have a few questions pertaining to how this is done:
Should I actually set up a user in Google Apps named "no-reply"?
If not setting up a "no-reply" user, should I log in with a real address (e.g.: "support#example.com") and send the email as being from "no-reply#example.com" instead? Or should I simply use the Reply-To email header?
If it's necessary to use the Reply-To header, is there a way to block the true From address (i.e.: the username I used to log into Google's SMTP server)?
Yes, you should setup a separate noreply address on your email server.
There are excellent reasons why you should set up a no-reply email address.
Why is it important to have a no-reply on bulk emails?
Many of the recipients of the email will try to hit 'reply' and they will have a multitude of reasons for doing so. Often, it is not sensible to have all of these going to a single representative at your company. Furthermore, many emails from bulk lists will be bounced back. You don't want to have to sift through these in order to find legitimate questions from your mail outs.
The best way to respond to questions rather than replying to bulk emails, is to have the recipients direct their questions to appropriate response emails either through their usual contact or via your company website.
What if recipients DO hit the reply button?
The email originator for the bulks should not just silently swallow the replies. Many companies do this and as a result, legitimate replies are ignored without any indication to your client or potential client and they, feeling neglected, go elsewhere for business.
The originating email account should be set up with an auto-responder explaining that the email was not processed and suggest alternative ways of contacting your company.
In gmail this can be done by setting up a Vacation responder with no last day. You can find the Vacation responder feature under the General tab of the account settings.
Avoid having extra accounts by setting up no-reply as a group that restricts users from outside your domain sending to it.
Unless you can think of a really good reason for it, I would suggest that you send your emails from support# rather than no-reply#.
The whole reason for a support# email address is to receive comments and feedback from your userbase, and if you're sending them emails why bother making it hard for them? If they can just reply to the email you'll receive way more feedback that way.
I suggest you set up a "Nickname" alias ( Manage Domain > Users > edit user > Add Nickname ). Then create a filter that sends any reply to that nickname straight to trash or spam.
Just set up a "no-reply" account. It won't hurt anything, people will still try to send stuff to it, and it will serve your purpose.
As for the latter two questions, it depends.
If you're sending these e-mails as a part of an automated script (i.e. forum registration) just use the "no-reply" accounts credentials. Log in periodically to make sure you aren't getting legit delivery errors (as opposed to the jokers that use fake e-mail addresses) or other odd behaviour.
If you're not sending these e-mails as a part of an automated script, it depends. If you also manage a support address (support#example.com, staff#example.com, etc.) you may want to send on behalf of, and use the reply-to. But this part is a little more subjective, and really depends on your setup.
I don't know if this will help or not, but IIRC, with gmail you can do something like
name+something_else_here#domain.com
Then, set up a filter so that emails with that "something_else_here" part go past the inbox to a label.
Does that help?
I think creating a user named no-reply is a bad approach. An alias or a restricted group is a much neater and functional solution IMHO. Also, google apps cost is based on user number.
A cool way to handle this would be using the vacation setting in GMail to send an automated response back on the no-reply email address. The vacation reminder would then remind users that this is an unmonitored email address.
I think the right thing to do is setup a filter that sorts your mailer-daemon messages into a special folder (Or trash if you so desire.) Or, like other comment have suggested, use a separate mail address.
noreply is good to indicate to people that this isn't an address you check, but it's not really the solution to dealing with bounce mail. In fact it's more likely your mail will end up in spam filters because your attempt at sender obfuscation will just look like spam to the receiving host.
You should create a noreply user. But use it as a spam mail (when registering unknown sites) and a mail for testing.