[Spambayes] RE: Yahoo's "domain keys" and spam

Seth Goodman nobody at spamcop.net
Fri Dec 12 16:56:24 EST 2003

[Ryan Malayter]
> I'm merely suggesting that the SB project get out in front of the issue.
> I will try adapt the necessary crypto code into Python myself as soon as
> it is available in other open-source projects. (I'm guessing the code
> will be in C, and go to the Qmail, sendmail, etc. projects).

IMHO, this code belongs in the MTA's, not in SpamBayes.  The usefulness of
the approach is that an MTA can reject, at the SMTP level, any message whose
encrypted signature does not decrypt with the public key.  There will be a
period where some MTA's don't support this feature, and one could argue that
some MTA's will never implement it.  My take on this, FWIW, is that unless
Yahoo fails to implement it, it's a done deal and all MTA's will pretty much
have to support it.  If it proves useful at rejecting spam, which appears
likely, I also can't see ISP's deciding to not enable the feature in their

During the period when few MTA's have this feature, this capability would
add some value to SpamBayes.  If I understand it right, you need to do a DNS
lookup to access the PKI key to do the decryption.  Both the DNS lookup and
the decryption calculation are very costly in terms of time per message, but
it may still be worth it.  That's your call.

If it does succeed in reliably authenticating senders and is not easily
abused (I don't know enough about DNS and PKI to comment), it is not
unlikely that Yahoo or some other major ISP will ultimately decide to reject
any mail that doesn't carry the authentication header.  At that point, the
relevant IETF technical committee will probably vote to elevate the RFC from
experimental to a draft standard and then a standard.

Of course, I neither run a large mail system nor an ISP, so I could be dead

Seth Goodman

  Humans:   off-list replies to sethg [at] GoodmanAssociates [dot] com

  Spambots: disregard the above

More information about the Spambayes mailing list