Sender Policy Framework

How web-generated e-mailers can avoid looking like forgers

What is a web-generated e-mailer?

Web-generated e-mailers provide a service that allows users to send e-mail to someone else on the user's behalf. A key point is that the user's e-mail address is unrelated to the domain of the site providing the service. Examples include: sites that send news articles to friends; forms for recommending web sites to friends; and electronic greeting card sites.

By contrast, webmail sites like Hotmail or Yahoo Mail are not "web-generated" e-mailers in this sense, because their users' e-mail addresses typically use the webmail site's own domain name. For example, let's say Mary Dinkleplotz has an e-mail address of <mdinkleplotz@hotmail.com>. If she sends an e-mail from the Hotmail site, that's ordinary mail, not "web-generated" mail in the sense we're talking about. However, if she sends mail using some kind of form on the SomeOtherDomain.com website, that's web-generated e-mail.

Why might you be mistaken for a forger?

SPF provides a list of servers that are authorized to send e-mail from listed domains. However, since web-generated e-mail sites are not part of the normal sending network for domains, they don't get listed in domain owners' SPF records. This can lead to web-generated e-mail looking suspicious.

You can avoid this problem by setting up e-mail headers correctly. The example below first shows the wrong way to do it; and then how two major web sites set up their e-mail headers the right way, to eliminate potential problems related to SPF.

How can you avoid this problem?

You'll need to change one or two things.

evite.com and egreetings.com show you how.

SPF is an extension to SMTP that helps preventing e-mail sender forgery. Systems which send mail on behalf of other people may need to make a few small changes to their mail systems to comply. These instructions are intended for services like eBay, Amazon, greeting card sites, and any other "third-party" systems that generate e-mail on behalf of other people.

evite.com and egreetings.com send web-generated e-mail: when users interact with the web site, e-mail goes out on their behalf. This is fine and good. But under SPF, mail from those services can look like a forgery — unless certain precautions are taken. evite.com and egreetings.com have already made the necessary changes. They set a good example for others to follow.

This can look like a forgery:
MAIL FROM: mdinkleplotz@hotmail.com ... From: "Mary Dinkleplotz" <mdinkleplotz@hotmail.com> Subject: Mary Dinkleplotz has sent you a greeting card!	(In this example, "hotmail.com" is used to represent any user supplied address.) Messages that use the user's address, but come from your mail servers are considered suspicious by SPF. To solve this problem, change the MAIL FROM address...
This is better:
MAIL FROM: service@egreetings.com ... Sender: service@egreetings.com From: "Mary Dinkleplotz" <mdinkleplotz@hotmail.com> Subject: Mary Dinkleplotz has sent you a greeting card!	egreetings.com does it this way: Choose a general address in your domain (service@egreetings.com). Change the "MAIL FROM" to that address. Add a "Sender" header to show to recipient who sent the message. "Sender" is a standard field; see RFC 2822.
This works too:
MAIL FROM: info@evite.com ... From: "Mary Dinkleplotz" <info@evite.com> Reply-To: "Mary Dinkleplotz" <mdinkleplotz@hotmail.com> Subject: Mary Dinkleplotz has sent you an invite!	evite.com does it this way: Choose a general address in your domain (info@evite.com). Change the "MAIL FROM" to that address. Change the "From" header to that address. Add a "Reply-To" header that contains your user's e-mail address.

Either way is fine. They both work just as well from an SPF perspective. The key component is to ensure that the SMTP "MAIL FROM" address is from your domain. After that, adding "Sender:" or "Reply-To:" headers is good etiquette and help direct replies to the proper address.

What is the Mail From and why don't I see it in my mail

Mail From is one of the commands used between two mail servers when email is exchanged. It includes the address to which bounces should be sent. It is also sometimes referred to as the envelope sender because it's not included in the body of the email message. When email is delivered, it the Mail From address is written into the message as the "Return-path".

Code

Sample PHP code that shows one way to do this has been contributed by Daniel of edenpics.com, a site that has updated their service to support SPF.

Note that the general address will receive bounce messages for mail that didn't go through. This is the desired behaviour. You can just discard mail to that address, or you can set up more complex bounce processing to tell the user their mail didn't go through.

Bottom line

The important thing is this: What's to stop a user from going to your website and claiming his e-mail address is <president@whitehouse.gov>? Very little. If that user uses your service to send mail to a hundred recipients, and if ten of those addresses bounce, the least you can do is to keep the bounces from actually going to <president@whitehouse.gov>. The above instructions solve that problem.