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.

In reply to Re:x3 SPF for Perl Monks domains (no no no) by grinder
in thread SPF for Perl Monks domains by Juerd

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.