[Mimedefang] sendmail spf milter plugin for sendmail 8.13.0

[Jeff Rife]

On 17 Aug 2004 at 18:24, Lucas Albers wrote:

> http://www.sendmail.net/dk-milter/
> "
> As part of our broad-reaching effort to spur the testing and eventual
> broad adoption of sender-based email authentication to address fraud and
> spam in email, Sendmail, Inc. is releasing an open source implementation
> of the DomainKeys by Yahoo! specification for testing on the Internet.
> "

Oh, yuck.  Sorry for the long rant, but...

Basically, the description memo says it takes the actual domain in the 
"From:" header, looks up a public key from the DNS server for that 
domain, and then uses that public key along with the signature in the 
"DomainKey-Signature:" header to see if the message is OK.  Anybody see 
the problem with this?

If the receiving server doesn't reject, but instead bounces, the bounce 
goes to the *envelope sender* (per the RFC).  Thus, if a bad guy 
doesn't like a domain, they just have to put a bogus envelope sender 
from that domain, a bad "DomainKey-Signature:" header/"From:" header 
combo, and then send the e-mail to someplace that checks DomainKeys but 
bounces instead of rejecting.

Second, if a server gets an e-mail with a "From:" address of 
"somebody at example.tld" and example.tld says (in DNS) "our e-mail must 
be signed", do you reject?  The problem this creates is the same one 
that SPF creates...road warriors must send all e-mail through their 
"home server".  There are a lot of big ISPs that *never* want to make 
this sort of functionality available.

Next, let's talk about mailing lists.  All messages in this list seem 
to have a "From:" header that isn't a roaringpenguin.com address.  Now, 
if there were already a "DomainKey-Signature:" header, the rp.com 
server shouldn't add one or modify the existing one because they can't 
sign for "example.tld".  But, the nice footer at the bottom of the e-
mail can't be added, since that would screw up the signature.  And, so 
would "Received:" headers (or *any* tampering with the headers) since 
"the default signature is an RSA signed SHA1 digest of the email 
headers and content".  This *requires* that my signing MTA talk 
directly to the final endpoint "checking" MTA.

Their description of the workaround for "Received:" headers basically 
means that you either trust that somebody else did the check correctly 
or that you must jump through some hoops to do the check yourself.  
There's also the issue of making it impossible for a mail server to 
translate 7-bit to 8-bit or vice versa.

Their "solution" (that won't work at all) for e-mail lists: "A final 
possibility is that MLMs may not need to participate in DomainKeys as 
recipients have other means of sufficiently recognizing legitimate MLM 
traffic, such as List-ID: headers".  Well, gee, even if they don't 
"participate", if the e-mail comes from a "participant", and ends up at 
a "participant", end users may never get a say in whether to reject the 
e-mail or not.

Last (and this is really the one I hate), they also have hooks for a CA 
system that means you would now have to pay money each year to have 
your e-mail "certified".  Sure, it wouldn't start out that way, but 
*some* large site would start refusing e-mail unless the public key had 
a CA-cert chain to somebody *they* trust.


--
Jeff Rife        | "Because he was human; because he had goodness; 
SPAM bait:       |  because he was moral they called him insane. 
AskDOJ at usdoj.gov |  Delusions of grandeur; visions of splendor; 
spam at ftc.gov     |  A manic-depressive, he walks in the rain." 
                 |         -- Rush, "Cinderella Man"