The idea behind Sender Policy Framework (SPF) is to eliminate the possibility for spammers to send messages which appear to come from a given company or entity, even though nobody at that entity sent it.
SMTP allows for this kind of impersonation because, by itself, nothing in SMTP ever checks to see that you are who you say you are in the FROM line. Remember that SMTP has been around longer than most system administrators and was built in a time when everyone on the internet knew everyone else by first name. "Trust" was never a design principle for the internet, and we've been dealing with the fallout ever since. The bottom line is that, as far as SMTP goes, you are who you say you are because you say so. If only it were that easy in real life.
Enter the Sender Policy Framework. SPF is implemented by both senders (as a DNS entry, saying "mail from me is going to come from the following addresses only"), and receivers (by checking the IP address of the sender connecting to your system against the list of valid addresses for the domain they say they are at). Simple.
The problem is this - if you don't implement SPF properly at both ends, it ends up causing more problems than it solves. Confused system administrators are likely to get this wrong, and are likely to be even more confused when you explain to them why they got it wrong and how to fix it. It's happening more and more often, and it's a pain.
The bane of a mail administrator's existence is the false positive - that is, a message which is legitimate, but that got blocked or bounced erroneously by the cocktail of email protection mechanisms they employ.
If as a receiver, you are not properly evaluating SPF for incoming messages, you are creating a problem for your users and the people trying to communicate with them by creating false positives in droves.
Worse yet, if your default action when you think there's an SPF issue is to bounce the message, you eliminate any chance that a human being can spot the problem and bring it to your attention.
Such is the case with tons of Barracuda anti-spam appliance users, who are responsible for a rash of "550 Rejecting for Sender Policy Framework" replies reaching support desks around the world.
A proper implementation of SPF will evaluate the IP address of the connecting system against the list of allowed IP addresses for that sender's domain based on their DNS record for SPF. No more, no less. In the case of the Barracuda, their devices are erroneously evaluating not just the IP address of the connecting system, but the IP addresses of every hop along the way. It is as if they inherently assume that even if the connecting system is in the SPF list, it is an open relay and is being abused by a spammer.
We've seen screenshots of Barracuda administrative consoles, and for messages they blocked as false positives due to "Sender Policy Framework", the details reveal that an IP address of a server involved early in the relay was NOT in the SPF record for that domain - even though the server establishing the connection to the endpoint WAS in the SPF record for that domain. If you use a smarthost configuration, whereby your public-facing mail server always relays to a service "in the cloud" for anti-virus scanning, etc, you are very likely having this problem or will soon. Postini is a good example of this type of setup, but there are others.
So both sides are using SPF, and both think that problems with SPF "violations" are the other one's fault. How do you tell who is right? Well, if you've already validated your record against an SPF query tool, a good source of arbitration is for a sender to send a message to Port25's SPF check service. They'll send you a return message with full details about whether your message complies with SPF properly and if they'd have delivered it. Ours, for example, does comply with SPF properly. And largely, we have no issues, but lately we've seen a rise in bounced messages due to reported SPF problems, and in actual fact, they have all (every single one) come from Barracuda appliance owners.
Plainly, if you are so dim witted as to put a Barracuda anti-spam appliance in place, little if any of this is making any sense. And that's the problem. What you're trying to do is admirable - cut down on spam. What you're really doing isn't - you're blocking legitimate email because you don't understand how this stuff works. Stop it. If you have a Barracuda, turn off SPF checking. It's broken, and you're eating up a lot of our time chasing issues that aren't in our sphere of influence. If you are unwilling to turn it off, see if you can adjust the default behavior for SPF violations to be something other than BOUNCE. Amateurs.
3 comments:
haha, im a couple years late but you to trust any blogger that we demean a group by saying "Plainly, if you are so dim witted as to put a Barracuda anti-spam appliance in place, little if any of this is making any sense.". Well played sir.
You mean "false negatives", not false positives. False positives are spam that is regarded as ham, legitimate email.
Astrin, actually you may have that exactly backwards. False positive most commonly refers to a legitimate message mis-characterized as SPAM. See the following as proof if you will: http://technet.microsoft.com/en-us/library/jj200769%28v=exchg.150%29.aspx
The point of the post was that these false positives are highly problematic, and lack of understanding of SPF often a culprit.
Post a Comment