Initial thoughts.

[Seth Goodman]

A few more thoughts here.  If we take the proposal that I just made,
used the option for an SRS hash with a sender callback from the far end,
used a CRC32 instead of sender_sig2, we have just removed any
requirement for public key crypto at the receiving end, which is a huge
savings in CPU cycles (unless you've got dedicated hardware).  The
sender callback from the far end, which I suppose would be to the MX for
the sending domain, has one distinct advantage that other anti-spam
folks have been suggesting for a while:  add a cost to _sending_ email,
not to receiving it.  In any case, this is very lightweight at the
receiving end:  DNS tests on the SMTP-sender, one sender callback to the
return address domain and a CRC32 calculation.

The only downside here is that nothing stops a spammy sender from just
saying ACK to any sender callback from his domain without doing the hash
verification.  He opens _himself_ up to forgery and joe-jobs, but he
probably doesn't care, so I suppose we shouldn't either.  If he says the
mail came from him and it didn't, then it's _his_ problem.  Perhaps not
as airtight as the public key method, but pretty good.

--

Seth Goodman