SPF is bogus, stop spreading the idea that it will resolve the spam problem.
It is not bogus. It is also not a way to fix the spam problem. It is, however, a good technique to stop joe-jobs. It has already proven itself: it doesn't add a lot of system load, but it does lower the amount of spoofed messages.
Unless Perl Monks now sells viagra, the messages I've been getting are clearly not from perlmonks.org. Note that SpamAssassin does pick these messages up and does flag them as spam. But that is a lot of system load, and in total still a lot of bandwidth. A single DNS lookup can in the earliest stage filter out a lot of forged addresses.
There is no benefit in implementing SPF for your zone, except receiving less bounces for messages you never sent. The pleasure would be others'. In this case, mostly mine.
| [reply] |
It is not bogus.
Yes it is :)
It is bogus because it breaks the SMTP delivery protocol and there is no simple way to fix the breakage it introduces. It is almost, but not quite, as bad as rejecting MAIL FROM <>.
It is, however, a good technique to stop joe-jobs
Uh huh, and you have received joe-jobs that are not spam?
SPF sets out to solve the wrong problem. It is an attempt at validating the sender domain, but the whole idea is futile. There are legitimate reasons for other hosts in other domains to send email on behalf of the sender domain. There exists mailing list software for lists that subscribe to the Reply To Sender school of thought (as opposed to Reply To List) that will use the sender address in the MAIL FROM.
A number of prominent web sites, not the least of which is Ebay, but also includes any number of birthday card, e-postcard, street map sites will let a visitor send messages using their personal address to you (whether this is a good idea is another question -- but these services exist). In these cases the MAIL FROM will be the domain of the person sending the message, not the domain of the web site.
The only thing the MAIL FROM does is to offer a return path for signalling errors in event of delivery failure. Furthermore, SPF only offers a partial remedy to joe-jobs, because while a spammer might get the message envelope SPF-compliant, they can still set up a joe-job in the message body, by setting a From: spamcollector_perlmonks@juerd.nl or Reply-To: header (hope you don't mind me using that address as an example).
There is nothing you can do with the sender domain apart from rejecting domains you know you don't want, like cyberspeedmarketing.com and sexyadultpages.biz. It is not for nothing that DNSBLs are much more popular than RHSBLs.
So if we are to forget about the sender domain as a method of stopping spam, what's left?
The client domain, the domain of the server that is connecting to your server. Takes its IP, reverse resolve it, and if the resulting domain is not in your good books, then reject the message with a 554 error code.
You should be very careful from whom you accept mail. If you don't accept mail from proxies, zombies and trojans, residential broadband, American university dormitories and other sundry spamhavens your spam load drops to close to zero. The additional delta of spam that SPF also stops then becomes vanishingly small. At that point, the cost/benefit ratio of implementing it approaches infinity.
You know, if we were all really serious about stopping spam, all that would need to be done would be to take RFC 2821 and s/should/must/g and republish it.
| [reply] |
It is not bogus.
Yes it is :)
No, it's not.
Uh huh, and you have received joe-jobs that are not spam?
Yes, but that is not the point. Most joe-jobbed messages are indeed spam. And SPF can fix that. SPF cannot solve the spam problem altogether, but it can (when used) make sure spammers can't get away by using YOUR e-mailaddress.
SPF sets out to solve the wrong problem.
There is no "right problem" or "wrong problem". There is one problem that consists of many smaller problems. The big problem is spam, the smaller problems are those of open relays, joe-jobs, spamming viruses, etcetera. The battle against spam is one on many fronts, and SPF is on only one of them. That doesn't mean that what SPF does is wrong or that it solves the wrong problem.
There are legitimate reasons for other hosts in other domains to send email on behalf of the sender domain.
When the owner of the domain agrees, they can add the other hosts to the list. I don't want other people to send mail on my behalf without permission.
A number of prominent web sites, not the least of which is Ebay, but also includes any number of birthday card, e-postcard, street map sites will let a visitor send messages using their personal address to you (whether this is a good idea is another question -- but these services exist).
Ebay should never send email on my behalf. Birthday card sites, e-card sites, street map sites, tell-a-friend systems, etcetera, should never send email on my behalf.
They can and should use their own envelope from. If they have to, they can put the email address they say it's from in the From: header. But for the envelope, they should use their own address.
they can still set up a joe-job in the message body, by setting a From: spamcollector_perlmonks@juerd.nl or Reply-To: header
Put the envelope from in the headers and that is no longer a problem. The envelope from is already in my logs, so I can verify it whenever I want. The problem now is that the envelope from is unreliable without SPF.
Headers should not be trusted. I can send mail To: spamcollector_perlmonks@juerd.nl and have it delivered to your mailbox. Likewise, I can make it look like you sent it. This has never been a problem with real letters, so why does it have to be a problem with email? As long as the *envelope* has the correct information, things are okay.
That said, I note that I do check the From: header with SPF, even though SPF was not made or meant for that. I use it in combination with SpamAssassin with a score of 1.0, which is by itself not by far enough to flag the message as spam.
If you don't accept mail from proxies, zombies and trojans, residential broadband, American university dormitories and other sundry spamhavens your spam load drops to close to zero.
Yes, and it would also block out at least 10% of the legitimate mail I receive. No, thanks.
What I think you're really trying to say is that because SPF doesn't solve the entire spamming problem, it should not exist and is not worth any trouble. Is that your opinion?
| [reply]
[d/l] |
If you don't accept mail from proxies, zombies and trojans, residential broadband, American university dormitories and other sundry spamhavens your spam load drops to close to zero.
You reminded me of this.
Seriously though, it seems like you spend a lot of time arguing based on assumptions which haven't been proven. If you think it breaks SMTP and have an argument that has not already been answered here already, it would be interesting to hear how you think it is broken. I'm sure the owners of the 14,000 domains that are presently using spf would be greatful to find out that there's a problem with their email that they didn't know about.
The argument about Ebay and birtday cards, etc.. seems to be without merit, because its simply not true. As the publisher of the SPF records for my domains, I can easily allow any location I want to send email from my domain. I can just as easily disallow any location as well.
A day will come when people will start assigning higher and higher spam scores to email originating from locations without SPF, and the eventually some ISPs will just start bouncing that mail completely. When that point comes, it will be harder and harder for ISPs to pump out spam meanwhile crying "it's not us.. we're being joe-jobbed". That is the point where the envelope headers absolutely will become useful, and SPF will become one useful tool in spam prevention.
| [reply] |