SPF on vger [LWN.net]

SPF on vger

Posted Jun 15, 2006 12:51 UTC (Thu) by job (subscriber, #670)
Parent article: SPF on vger

SPF is a bad idea, with a terrible implementation. I can not understand
why anybody would want it. It accomplishes nothing since users care about
mail headers, not smtp headers. It breaks forwarding. It is impossible to
implement for all domains who actually use their TXT records for
something. And it requires most of the world to participate in their
scheme before they it's effective doing nothing.

All this to combat joe-jobs, which aren't a problem to anyone. Spam is
the problem. Which got many SPF proponents to start lying and talk about
it as a spam solution. That was dishonest. I know you want to see your
pet project adopted around the world, but sorry, it is a braindead idea.

But don't take my word for it, read what Allman, Bernstein, Venema and
all the other e-mail luminaries who actually know this stuff wrote. No
one thought it was a good idea, and with very good reasons too.

(Log in to post comments)

SPF on vger

Posted Jun 15, 2006 13:34 UTC (Thu) by cate (subscriber, #1359) [Link]

As the open relay. It took a lot of time to close the mail servers, but now I think all major mail servers will reject the mail from open relays.

SPF on vger

Posted Jun 15, 2006 14:04 UTC (Thu) by pizza (subscriber, #46) [Link]

First, don't use the term 'spam', as it's so ambiguious ("unwanted e-mail") as to have no real meaning. Please use a more specific term; you want to deal with trojans or phishing mails differently than the latest Victoria's Secret catalog.

Oddly enough, the former two tend to rely heavily on forged SMTP envelopes, which is precisely what SPF is intended to deal with, and it accomplishes that fairly well. Does it break certian practices? Well, yes. But what its detractors fail to understand is that this is a trade-off that many, many willingly make, especially when it is their reputation and/or money on the line.

Don't forget that these problems exist because of the deficencies of the original SMTP (and yes, DNS) systems.

"Requiring most of the world to participate" is actually a feature of the Internet -- the network is dumb; the end-points are smart. But it also makes change very hard to implement.

As such, the disruption from replacing the whole schebang will be far greater, even though everyone agrees that it's what really needs to be done. And that will certianly break many things that work now.

Incidentally, is there an "official" use for TXT records? "Arbitrary Binary Data up to 255 characters" sounds like there isn't, and a domain owner choosing to use that "arbitrary data" for purposes of reducing forged mail being sent under their domain certianly sounds like an appropriate use.

Using DNS TXT records is a cool idea because it doesn't require any new infrastructure, unlike, for example, using PGP signatures, which works well on an individual basis but otherwise scales terribly due to the necessity of establishing trust anonymously.

SPAM == Unsolicited bulk email. It's simple

Posted Jun 15, 2006 14:26 UTC (Thu) by dwheeler (subscriber, #1216) [Link]

I completely disagree. Spam has a simple and clear meaning: "Unsolicited bulk email"; it's sometimes called "UBE" instead. "Bulk" perhaps is a little ambiguous, but if you're sending out more than 1000 copies of an email, and the receivers didn't request it (e.g., by joining a mailing list), you are a spammer sending spam.

Some spam has trojans, or other nasty stuff. It's a good idea to protect against other kinds of malicious email. But usually the malicious email is ALSO spam. If we could get rid of spam, we'd greatly reduce any other kind of problem as well on email.

SPF on vger

Posted Jun 22, 2006 15:54 UTC (Thu) by forthy (guest, #1525) [Link]

I agree that SPF is not a good idea, but I support it (not just lip service), for two purposes:

it gets me rid of all those "security updates from Microsoft" before my virus checker gets to see them (since microsoft.com has a SPF record).
it adds up to the pain for using SMTP that it might help to overthrow it - especially when it is adopted.

I view SPF not as a solution to a specific problem, but as a nail on the coffin of SMTP, and I'm ready to adopt the next nail if I can find one.

SPF, joe jobs, and phishing

Posted Jun 15, 2006 17:12 UTC (Thu) by rfunk (subscriber, #4054) [Link]

I agree that SPF is a bad idea, or at least one that demonstrates
insufficient understanding of the way SMTP is used in the real world.

However, i can tell you from firsthand experience that joe jobs are a
real problem, and I can certainly understand why the victims of them
would be tempted to use anything that claims to be a solution. Not only
are joe jobs a problem due to blowback bounces, but also because they
harm the reputation of the victim domain, leading the domain to land on
private blacklists with no recourse for getting off.

Of course, anyone tempted to publish an SPF record as a solution to joe
jobs needs to realize that it's only a solution to the extent that people
check the SPF records, and considering the type of blowback I've been
seeing, many places are still doing little or no spam filtering in the
first place, let alone checking something as questionable as SPF.

It's also worth noting that forged mail is not limited to phishing
attempts; I consider phishing to be a separate problem.

SPF, joe jobs, and phishing

Posted Jun 15, 2006 18:13 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

There are much better solutions to the problem of bounces to joe-jobs. Solutions which don't require wholesale changes to the way that email works.

SPF, joe jobs, and phishing

Posted Jun 15, 2006 19:32 UTC (Thu) by dlang (subscriber, #313) [Link]

like what?

SPF, joe jobs, and phishing

Posted Jun 15, 2006 21:32 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

You didn't actually read the why not SPF page linked above, did you?

In particuar, I was thinking of BATV. Not only does it instantly stop the bounces to mail you didn't actually send, but it also allows others to detect fake mail. Try faking MAIL FROM:<dwmw2@infradead.org> to any site which bothers with sender verification callouts to avoid mail from invalid addresses (like sourceforge, amongst many others).

550-Verification failed for <dwmw2@infradead.org>
550-Called:   2001:4bd0:203e::1
550-Sent:     RCPT TO:<dwmw2@infradead.org>
550-Response: 550-This address never sends messages directly, and should not accept bounces.
550-550-Please see http://www.infradead.org/rpr.html or contact
550-550 postmaster@infradead.org for further information.
550 Sender verify failed

SPF, joe jobs, and phishing

Posted Jun 22, 2006 23:51 UTC (Thu) by kitterma (subscriber, #4448) [Link]

How many of those solutions are accessible to someone who doesn't run their own dedicated mail server?

SPF, joe jobs, and phishing

Posted Jun 15, 2006 19:35 UTC (Thu) by rfunk (subscriber, #4054) [Link]

Note that I mentioned bounces being only part of the problem with
joe-jobs.

SPF, joe jobs, and phishing

Posted Jun 22, 2006 23:48 UTC (Thu) by kitterma (subscriber, #4448) [Link]

None of which are implementable by someone who isn't running their own mail server and using custom software. With SPF, with all it's flaws, any domain owner that can publish a TXT record in their DNS can gain some protection.

SPF checking may be relatively rare, but in my experience it is enough that within a month of publishing a -all SPF record, bounce messages due to forged sending using my domains ended. There is enough SPF checking going on to provide deterrence.

SPF is a horrible idea in theory. In practice, unless your user base sends to peope who do a lot of forwarding, it works pretty well for many domains. Eventually, it will be obsolete because something better will come along. In the meantime, it does the job for me and lots of others.

SPF and vger

Posted Jun 23, 2006 3:24 UTC (Fri) by SDGathman (guest, #38604) [Link]

SPF is not for everyone - that is why it is optional. However, it is a good fit for vger. The forwarding problems are caused by incorrect *checking* of SPF (neglecting to compile or check a list of non-SRS forwarders), and doesn't affect publishers unless the receiver is *really* braindead and, for example, checks SPF from behind their MX (a common first time user error).

The proposed vger application involves publishing an SPF record. The only potential forwarding issue for publishers is web greeting card type sites that don't use their own domain for the return path. This is not a problem for vger.

I have been publishing and checking SPF in production for 2 years. Most of the complaints from anti-SPF people are based on misunderstandings. For instance, the "forwarding problem" is a "doctor it hurts when I do this" problem. If you have no idea who you get forwarded mail from (even though you set them all up), then don't check SPF. Problem solved.

SRS is actually not a good solution to handle forwarders. Simply listing the forwarders is much cleaner. Listing them is easier if the forwarders publish SPF - cause then you know their IPs automatically. SRS is useful as a BATV alternative that also handles relaying.

The roaming sender problem is elegantly solved using SMTP AUTH - which has been widely available for at least 10 years.

If you publish CSV, you might as well publish SPF for your HELO names and pick up SPF checkers as well (caveat, only if HELO name is distinct from MFROM domain - an SPF namespace collision wart).