Sender authentication part 15: How SenderID interprets SPF records

In my last post, we were introduced to the new SPF record syntax that is specifically designed for SenderID.  The question now is how does SenderID treat SPF records that were originally designed to be used with SPF?

SenderID allows the spam filter to check SPF records on the envelope sender or the PRA, but SPF records are only designed to be used on the envelope sender.  If a system using SenderID encounters an SPF record, the behaviour is dependent on the implementation of SenderID.

Section 3.4 of RFC 4406 says the following:

In order to provide compatibility for these domains, Sender ID implementations SHOULD interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom,pra" , provided no record starting with "spf2.0" exists.

In other words, if you have a Sender ID implementation that checks the envelope sender (ie, just like SPF), this will function exactly like regular SPF.  If you have a Sender ID implementation that checks the PRA, use the SPF record to check the PRA.  Thus, the recommended behaviour of your SenderID implementation is that existing SPF records should protect either the MAIL FROM or PRA.

The RFC goes on to say the following:

Administrators who have already published "v=spf1" records SHOULD review these records to determine whether they are also valid for use with PRA checks. If the information in a "v=spf1" record is not correct for a PRA check, administrators SHOULD publish either an "spf2.0/pra" record with correct information or an "spf2.0/pra ?all" record indicating that the result of a PRA check is explicitly inconclusive.

The reason this warning is given is because it's possible that the behaviour of the envelope sender could be different than PRA.  Because SPF was designed to be used to protect the MAIL FROM, it is not necessarily true that the PRA will behave the same way.  As the warning above says, to prevent any confusion, domain administrators should explicitly publish SenderID records that do not explicitly say one way or the other whether or not the PRA is protected (ie, return Neutral).

The folks at OpenSPF are much more blunt.  Before I go on, I just have to say that there is a definite touch of arrogance in their commentary on SenderID, but I digress...

If you have published an v=spf1 policy to protect the use of your domain in the MAIL FROM and HELO addresses, Sender ID implementations that apply your policy to PRA (per RFC 4406) will reject your mail if you use your domain in the "From" (or generally PRA) header field while sending from (MAIL FROM) another system.

Informal surveys have shown that in roughly 80% of e-mail surveyed, MAIL FROM and PRA are the same. However about 20% may be wrongly rejected or flagged by Sender ID implementations.

You might be wondering why anyone would would use different a MAIL FROM from their PRA (ie, different domain in the envelope sender from the From: address).  The answer is that it happens all the time.  The most common occurence of this are newsletters.  An emailer, such as bigfootinteractive.com, might be contracted to send out emails for a Home Depot newsletter.  The envelope sender might be newsletters @ bigfootinteractive.com but the From: address, the one that appears in your email client that Home Depot wants to show up to their subscribers, says info @ homedepot.com.  The SPF check will pass because the IP sending the email is authorized to send mail for constantcontact.com, but if the PRA turns out to be homedepot.com (and 80% of the time, it is the domain in the From: address), then this will return a Hard Fail.  If the SenderID implementation checks the PRA, it will reject the mail (or at the very least increase the spam score).  This type of situation is not at all unusual.  Bulk emailers have historically been very slow to adopt good email practices, and this example is common in real life.  SenderID also has some issues with email forwarders, such as mail forwarded through a university alumni account.

In my next post, I will discuss a little bit more about some of the mitigations that are possible to deal with some of the above issues.