[Spambayes] RE: Yahoo's "domain keys" and spam
nobody at spamcop.net
Fri Dec 12 16:56:24 EST 2003
> 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
Humans: off-list replies to sethg [at] GoodmanAssociates [dot] com
Spambots: disregard the above
More information about the Spambayes