Sender authentication part 17: Hazards of SenderID and SPF

Both SenderID and SPF have their critics.  I'd like to touch on two potential problems with them: the first is the issue of email forwarding.

There's no official standard on how email is to be forwarded (in terms of rewriting the headers).  Suppose that Mail Server A sends the message and everything complies with SenderID or SPF - the envelope sender is correct, the domain has its SPF or SenderID records set up correctly, and so forth.  The message goes through some internal routing, but then is subsequently forwarded by another outside mail server (perhaps an open relay) with no change to the email headers.  Or, consider the case of receiving mail at one mail host on your network which then relays it to a central mail server. 

What happens?

Well, since the last hop of the message router is the transmitting IP that the receiving email server receives the message from, it only makes logical sense that to use the envelope sender / PRA and that IP in doing an SPF or SenderID check.  Since nothing was rewritten in the message headers, this will fail a sender authentication.

The creators of SPF actually admit that this is a problem and suggest whitelisting the IP as a possible workaround:

Checking SPF On Forwarded Mail

Mail forwarding is set up by the receiver and so for forwarded mail, the border mail server should be checked rather than the the forwarder's mail server [sic]... Authorized forwarders should be whitelisted against SPF checks to avoid this problem.

Note: OpenSPF needs to clean up their grammar.

I'm not a big fan of this workaround.  Whether it's your own internal mail servers routing the mail (SPF is designed to be used at the border of your network) or some other forwarder somewhere, my experience with whitelisting is that you'll be forever whitelisting IPs.  Just when you think you've found one forwarder, another one pops up.  I can't tell you how times I've fixed a false positive caused by spam regex rules thinking I've fixed all of our broken rules only to see another broken rule pop up.  The fact of the matter is that there are lots of mail forwarders out there and chances are you'll never find them all.

While SenderID has the theoretical advantage of checking the Sender headers or Resent-(From|Sender) headers and could (in theory) look through the other email headers trying to extract the original sending IP and matching the PRA, I think this is a lot of trouble as well because it would have to figure out which IP in the headers was the original one and also detect which headers are fake and which are not.

So, how can mail servers get around this problem?

As a spam analyst who has processed over one hundred thousand false positives, I've long since learned that even though an anti-spam technique is supposed to be 100% designed to hit spam, it almost always hits legitimate messages that the designer of the technique hadn't considered.  The technique is good at stopping spam but inevitably proves to be overly sensitive. 

In the case of SPF and SenderID, this email forwarding is a legitimate problem.  My own preferred technique is to tweak the recommended implementation.  Whereas SPF and SenderID say you should reject mail that fails an authentication test, I prefer to score it aggressively.  For example, if we have a spamminess scale based upon probability that runs from 1 to 10, with 1 being non-spam and 10 being spam, assume that if a message scores higher than 5.0, it is considered spam.  The recommendations for SPF and SenderID say to reject mail based upon a test failure, so their probability grades would be 10.0.  Thus, combined with other elements in the mail that knock down its spamminess, it's unlikely to get it under the spam threshold.  My way of doing it would be to score an authentication failure at 6.0, enough to get the message over the spam threshold, but not so far above it that non-spammy elements couldn't bring it back down.

In my experience, most spam contains elements that mark it somewhat spammy anyways, while non-spam contains elements that make it non-spammy.  A message with an authentication failure will often times have other elements that will keep it over the spam threshold, while a non-spam message with a failure will usually (75% of the time) be able to be pulled under the threshold.  Of course, there are times when spam will get pulled under (false negatives) and non-spam gets pushed over (false positives), but in my experience, it is generally better to error on the side of reduced false positives.