Re:x3 SPF for Perl Monks domains (no no no)

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.

Comment on Re:x3 SPF for Perl Monks domains (no no no)

Replies are listed 'Best First'.
Re: Re:x3 SPF for Perl Monks domains (no no no) by Juerd (Abbot) on May 15, 2004 at 14:36 UTC
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? Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }	[reply] [d/l]
Re:x5 SPF for Perl Monks domains (no no no) by grinder (Bishop) on May 15, 2004 at 21:03 UTC
It is not bogus. Yes it is :) No, it's not. It is. 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. It is permitted in the current standard. Certainly, the standard was written at a time when spam and viruses were not a problem, but until it is amended, it is the standard and people are allowed to do that. That is not to say that I don't run my own correlation checks on the sender domain of the envelope. For instance, apart from a small number of whitelisted local ISPs, the only host that are permitted to send me yahoo.com email must have a domain name that also resolves to a Yahoo! server. Ebay [et al] should use their own envelope from. Why? If the email is undeliverable then they would have to do something about it, but it's not their problem. It's the problem of the person who sent the message initially. The return path mechanism works admirably well for this purpose. The problem now is that the envelope from is unreliable So forget about it. Deal with it another way. Stop fretting about what you're being sent and start paying attention to who is sending it. Don't add a DNS wart that breaks the existing standard in an attempt to fix it. This has never been a problem with real letters, so why does it have to be a problem with email? Atoms versus electrons. E-mail is not like real letters. The mail analogy breaks down if you push it far enough. 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. Really? I don't think you understand what I'm saying. You let hosts with dynamic IP addresses connect directly to your server? Any old ppp, dialup or dhcp connection? And this accounts for 10% of your email? No wonder you're looking to fix a problem, but I think you're focussing on the wrong aspect. Deal with the client, and then you won't have to worry about the sender. 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? No, that's not what I am saying. I quite agree that any technique that proposes a method of diminishing the amount of spam, viruses or anti-virus warning messages I receive is worth considering. In the case of SPF, I looked at it and found it wanting. While the benefits appear interesting, the fact that it breaks the existing standard makes it next to worthless. If it can be reworked so as not to break forwarding, then I'll be all in favour of it, but until then indeed it should not exist.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Re:x3 SPF for Perl Monks domains (no no no) by ehdonhon (Curate) on May 21, 2004 at 06:22 UTC
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]