SPF: yes, ma'am [LWN.net]

SPF: yes, ma'am

Posted Jun 15, 2006 10:11 UTC (Thu) by zmi (subscriber, #4829)
Parent article: SPF on vger

SPF is great in helping identify if an incoming e-mail is forged or not.
Imagine a server connects to yours saying "I send mail from
Bill.Gates@microsoft.com to your x@y.z user". Until now, you had to
deliver those, trusting ALL servers on the bad-bad Internet. With SPF, you
can look @microsoft.com if it allows that specific server to send mail
from microsoft.com, and if not, you can just drop the connection.

This way, lots of forged e-mails are prevented, resulting in fewer
problems (here on our servers, YMMV). I've had the problem once that
somebody sent in my name a bad e-mail to our customers - but since SPF
that problem is gone.

The "only" downside is e-mail forwarding. I've had some itches, and it's
not really nice. SRS is too complicated. But until somebody gives me a
better/easier/nicer way to prevent forged e-mails, SPF is my protection of
choice. I'd recommend you turn on checks to SPF on your mailserver, and
see lots of forgeries being dropped.

mfg zmi

(Log in to post comments)

SPF: yes, ma'am

Posted Jun 15, 2006 11:50 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Given the spam/ham ratio nowadays, *any* filter even a random filter will drop spam/forgeries.

The question is not if it's capable of dropping bad messages, but if it can reasonably distingish spam from ham.

So far the evidence in SPF doesn't.

SPF: it's NOT AT ALL about SPAMfiltering...

Posted Jun 15, 2006 16:42 UTC (Thu) by zmi (subscriber, #4829) [Link]

People keep believing that SPF is to filter SPAM. That's not the target.
SPF can *only* say if an e-mail is forged or not.

If you setup in SPF that from lwn.net only host 1.1.1.1 is allowed to
send, and some server checks SPF and gets a mail from lwn.net from host
2.2.2.2, then it can discard it as forged. That's it.

The fact that SPAM very often sends with forged addresses is just a side
effect. There are other tools for SPAM.

SPF: yes, ma'am

Posted Jun 15, 2006 16:53 UTC (Thu) by iabervon (subscriber, #722) [Link]

It's not surprising that it can't distinguish spam from ham, because it wasn't designed to distinguish spam from ham, contains no support for doing that, and the specification states that it does not do that. It is intended exclusively to distinguish forgeries, and spam is relatively rarely forged. It isn't intended to provide any benefit to the recipient; it's intended to benefit the innocent third party whose address the forger is using.

Of course, it's too soon to use it; the rest of the email system is still such that legitimate operations are standardly done by essentially forging email. At present, there is no standardized and reliable mechanism for a desktop MUA to submit email to the system in a way that authenticates the sender (as controlling the reception of email to the address). And there's the mess with transparent forwarding. (I think SMTP is essentially just a big mess, like a lot of its contemporary protocols, which were done before people had a good understanding of how to design application-layer network protocols effectively.)