Novel Method for Universal Email Authentication

MKaplan writes "Most spam is sent using spoofed domains. Email authentication schemes such as SPF attempt to foil spoofing by having domain administrators publish a list of their approved outgoing mail servers. SPF is sharply limited by incomplete domain participation and failure to authenticate forwarded email. A paper describes a novel method to rapidly generate a near-perfect global SPF database independent of the participation of domain administrators. A single email from an unauthenticated domain is bounced and then resent — this previously unauthenticated domain and the server listed in the return path of the resent bounce are entered into a globally accessible database. All future emails sent from this domain via this server will be authenticated after checking this new database. Mechanisms to authenticate forwarded email and to nullify subversion of this anti-spam system are also described."

Comments

That's already implemented with Spamcop

[no-body]

Mail servers are authenticated by Spamcop and forward spam automatically to Spamcop which adds it to their database. When using reject_rbl_client bl.spamcop.net SPAM is blocked.
Works like a charm!

That's the problem.

[khasim]

He does not CLEARLY explain what he is intending.

I believe he means denying at SMTP time, so the sender will try again after X minutes.

Which is kind of like greylisting. The FIRST problem is that the spammers have adapted to this and retry.

The SECOND problem with this is he's saying:

Unique sub-addresses are dispatched in the 'From' field with routine outgoing email. RIAuser@domain.com may send RIAuser^85nxsm@domain.com to one individual and RIAuser^n4sw5z@domain.com to another individual.

Huh? So this is also about SENDING email?

Now if you could bounce the message, it would just go back to the original IP, so I don't see why that would help either though.

And it doesn't address the issue of "fast flux" where the domains are "legit" in that they exist and point to the IP address of the sending machine ... for a few minutes.

So he's talking about "bouncing" messages ... installing new software ... and altering the "From:" addresses on stuff YOU send ...

No fucking way is this going to work.

Participation in SPF

[Anonymous Coward]

"SPF is sharply limited by incomplete domain participation"

That's not a big problem. 99% of non-participating domains fit in default SPF record "a/24 mx/24 ptr -all", we use it in qmail for few years. Together with Spamassassin it results in 99,8% antispam accuracy (warning: one big exception is yahoo.com, you should use domainkeys or add ptr:yahoo.com to default spf rule)

Re:Still barking up the wrong f'ing tree...

[SCHecklerX]

I dunno. I've been pretty spam-free for the past several years using mimedefang, milter-greylist, and spamassassin.

The key is to reject the obvious nonsense before invoking your cpu-intensive analysis. I reject on the order of 90+% of everything that my mail server sees (even more at the last place I worked where they were using the same system). False positives on my home mail server are near 0. The ones that are mistakenly flagged, are simply flagged as spam, so I still see them, they weren't rejected or discarded. More at work got through, but that is because we have to be more conservative due to not having a good way to do bayesian filtering for individuals (I left before I had the time to run that project with the internal mail admins).

1. Implement Greylisting. Spammers don't retry
2. Reject if sending server is in zen.spamhaus.org or list.dsbl.org
3. Reject if helo is not a FQDN or IP Address
4. Reject if envelope sender claims to be an address from your domain (obviously our real users get through)
5. Reject if helo claims to be your own mail server
6. Reject if helo is an ip address from RFC1918 (again, short circuit on your own routing)

Then call spamassassin on anything that is left (SA will increase/decreas scores based again on RBLs that we don't outright reject, SPF records, etc):

1. use sa-update daily both with standard spamassassin rule updates, and, more importantly, the stuff at saupdates.openprotect.com
2. if you are able, create a way to easily train your bayes on false positives and stuff that wasn't rated high enough. I do this with specific courier IMAP folders that get checked once an hour
3. Tune your sa rules to taste. I had to decrease some things (lots of friends use yahoo mail), and increase others (Stock image spam. Ugh).