Anti-spam SMTP mods

[Dustin Decker]

> How 'bout this:
> 
> Why not just have all mail servers setup with their own GPG keys, listed
> on some public GPG servers, (in a way like the root DNS servers,
> redundant and self propagating) and have them all sign the header
> portion of an email upon sending out.  When the receiving SMTP server
> downloads the email, it also downloads the GPG key from a keyserver if
> available (or use a cached one, much like cached DNS records, giving you
> the option to cache them or not, and a certain timeout period), to check
> the headers are actually from the sending server, unforged and
> unmodified?  If not, it rejects the email outright, and sends it to
> /dev/null...

While I doubt very seriously GPG is what Mr. Gates has in mind, I get the
impression (not having examined any of the technical aspects or merit of
what he has so far presented) that he is looking toward this sort of thing.
That is to say, I think he's looking to propose a method of server to server
authentication via the use of a "stamp" (he's using the US Post Office
analogy to dumb things down), which I expect could only be accomplished in
the method you describe.

The problem, of course, with any solution he offers is that it will likely
require the use of Microsoft Exchange Server or something equally expensive,
overbearing, and worthless.

> If root GPG servers are unavailable, the email will be held in queue
> until the GPG servers are able to be checked positively if an SMTP host
> has a good key, or even a key at all.  Then, even if spammers DDOS'd the
> root GPG servers, instead of allowing a flood of spam to get through,
> none would get through, until the DDOS attack subsided, and the email
> servers were able to access the keyservers.

I would have to interject that any method of DDoS'ing the authentication
mechanisms should be avoided at all costs from the beginning of such an
implementation.  Spammers unfortunately still appear to be enjoying the
benefits of revenue, and will do whatever it takes to safeguard their access
to the system.  In the absence of access, they'll certainly have no problem
with trying to cripple the system, and plenty of script-kiddie's will come
to their aid.

Perhaps something which mimics DNS as you described would be better - along
the lines maybe of caching keys for a specified TTL or what have you?  This
could theoretically allow the system to survive DDoS, provided the admin
folks near the root servers could mitigate the issue within the TTL.

> Mailing lists could require you to upload your public key to it's
> private stash upon subscription and compare it to your to-be-posted
> email to prevent email spoofing to post to the list...maybe that's a bit
> overboard...

Overboard perhaps, but it would sure take care of the whole "I can't post
from _anywhere_ other than my previously specified address" problems and
what have you.  In fact, I would suggest something like this for mailing
lists right now, independent of all other factors.  (This of course presumes
we'll all be aware of successful key management strategies.  Given the
propensity of system administrators to _still_ lose jobs over failed backup
strategies, I don't know how effective this will really be.)

> There's probably some bugs in my thought, as it's late, and probably as
> many cons as pros - one being *everyone* would have to participate -
> otherwise we'd probably be using this type of spam protection right
> now...Just a thought...would be great if we could get all the MTA's to
> standardize on it and start using it.

Again, you have an excellent grasp of the situation.  This is the problem
with any solution - if it's not standardized, wide open, and widely adopted
in a relatively short period of time, any solution will be doomed.

Good thread - how much further can we take it?

Dustin Decker