I bet that spoofed email came from a residential dialup. If my stats are representative of anything, it's most likely to have come from, in order of frequency:

1. comcast.net
2. ameritech.net
3. pacbell.net
4. attbi.com
5. swbell.net
6. rr.com
7. optonline.net
8. charter.com
9. shawcable.net
10. dsl-verizon.net

Refusing email from dialups (but accepting from the official MTA of the ISP) results in a dramatic reduction in spam.

There are other ways of reducing spam from within the existing RFC-2821 framework. Adding yet another DNS hack is never going to succeed. For instance, in an ideal world, one would only accept connections from a host whose IP address has matching forward and reverse DNS resolutions. And the HELO/EHLO string would exactly match one of those resolutions.

This is easy for a competent sysadmin to set up (although it is depressing beyond belief to observe how many domains don't get these simple basics right). Spammers do so many stupid random things with the message envelope that just correlating the HELO with the resolved client name would blow them out of the water.

And if they did start doing the right thing (in the RFC sense of the term) it would be trivial to identify them and hence blacklist them.

SPF is bogus, stop spreading the idea that it will resolve the spam problem.

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.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

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.

All it takes is one. I don't know what spammer I've ever ticked off but I've received joe-job bounces for my personal domain. Or unfortuately these days, one person with a Wintendo email client with a perlmonks email in their address book.

And yes, it breaks forwarding. But there's a proposal for working around that, and with the potential for stopping spam it's worth a minimal breakage.

I use mail forwarding, and I don't have a problem with Spam. Mind you, I don't know how many emails my server deletes as spam, but it can't be that many, it will display a message about "NN new messages on servers" and fetch around that many messages.

Still, when your proposal for fixing mail forwarding becomes an established standard, let's discuss the possibility again. Alternately, refuse all mail from perlmonks ... how many messages do you receive from there, anyway?

--
TTTATCGGTCGTTATATAGATGTTTGCA

SPF is evil. It totally breaks mail forwarding.

It doesn't have to: just add the right hosts or even entire IP ranges to the string. Besides that, even if it would break mail forwarding, that would still not be a problem for a domain that is never used to send mail (I don't know if the Perl Monks domains are used for sending mail).

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

It doesn't have to: just add the right hosts or even entire IP ranges to the string.

That doesn't ensure that mail forwarding is not broken - The issue with mail forwarding is based upon the source address of the machine sending the mail through to a SPF-aware mail server. If mail is forwarded from the original recipient address to a secondary SPF-aware mail server, the mail will be marked as illegitimate because the source address of the mail message, as seen by the receiving mail server, is that of the primary mail server. In order to prevent this, all mail servers must incorporate the Sender Rewriting Scheme (http://spf.pobox.com/srs.html) for forwarding mail when forwarding mail to SPF-aware mail servers.

 

perl -le "print unpack'N', pack'B32', '00000000000000000000001011010110'"

While we're at it, let's also incorporate Caller ID, DMP and RMX ... And heck, why not also add the Perl Monks domains to Bonded Sender in order to ensure the delivery of mail from these domains ... And use S/MIME signatures for outgoing mail too so that we know that the mail hasn't been modified ... Or better yet, require everyone to obtain a PGP key so that these mail messages can additionally be encrypted ...

Any protocol or revision to SMTP that necessitates the rewriting of mail content in order to implement mail forwarding is evil - The Sender Rewriting Scheme is a poor attempt to fix a broken implementation.

please implement SPF

I ain't so sure of SPF. I have to agree with grinder on this one and figure it to be one of those "looks great on paper but sucks in the real world" deals.

Personally for myself I'd have to totally re-engineer how I do email right now. I have a deal going with my hosting provider where they provide me an MX to my cable modem attached machine at home. When I send mail out now I have to deal with folks that won't accept mail from my machine because its IP address is in the Comcast space. Ironically enough one of them is AOL! Yet I'm a legitimate user of email not a spammer but I am being "punished" along with the bad apples. So I

Change my provider(s)? There aren't any alternatives to broadband access in my area other than maybe getting a T1 at around US$800 a month. More that I can afford.

I think there are better ways of stopping spam that don't include breaking what works.

My only substantive contribution to this thread is to agree that breaking or significantly modifying the SMTP protocol to thwart spam is going to be a very painful and tedious process. An an alternative, I read about an interesting proposal on graylisting that uses what SMTP can already do to discourage spammers. In short, it attempts to make it more costly (in terms of time and computer sophistication) for spammers to send spam, so hopefully you would discourage some useful percentage of potential spammers. The determined spammers who worked around graylisting would make themselves more vulnerable to other anti-spam methods. Although it's not an airtight anti-spam system, it seems to me like it's more gain for less pain than a complete protocal rewrite.

Oh, and the implementation of greylisting described in the paper is written in Perl. :)