SPF, joe jobs, and phishing [LWN.net]

SPF, joe jobs, and phishing

Posted Jun 15, 2006 17:12 UTC (Thu) by rfunk (subscriber, #4054)
In reply to: SPF on vger by job
Parent article: SPF on vger

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.

(Log in to post comments)

SPF, joe jobs, and phishing

Posted Jun 15, 2006 19:32 UTC (Thu) by dlang (✭ supporter ✭, #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).