[Mimedefang] DomainKeys

[SM]

Hello,

>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?

http://antispam.yahoo.com/domainkeys

Quoting from the above url:

"Verifying: The public key from DNS is then used by the receiving mail 
system to verify that the signature was generated by the matching private 
key. This proves that the email was truly sent by, and with the permission 
of, the claimed sending From: domain and that its headers and content 
weren't altered during transfer."

>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.

You seem to be confusing DomainKeys with SPF.  DomainKeys is not designed 
for that purpose.  The BATV draft proposal offers a mechanism for 
validating the "enveloper sender".

>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.

The select in DNS only holds the public key.  Domainkeys provides a 
mechanism for the incoming MTA to verify the From: address if there is a 
"DomainKey-Signature:" header in the headers.  This can be used to prevent 
phishing attacks.  The road warrior can still send email from another 
ISP.  The difference is that verification at the recipient's mail server 
will fail.  The MUA, if it supports DomainKeys, may then flag the email as 
"untrusted".

>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.

The DomainKeys draft does not address this question yet.  The mailing list 
MTA could  use the List-Id header to sign the message and the recipient's 
mail server would verify on that header instead of the From: header.

>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.

The message is signed at the outgoing MTA and the signature is verified at 
the incoming MTA before any changes are made.

>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.

I don't follow what you are getting at here.

>Furthermore, DomainKeys is trivially defeated with a replay attack.
>Send yourself the spam through the signing server.  Now you have a signed
>spam that you can re-mail far and wide.  Of course, you can't mutate it,
>which might increase the effectiveness of DCC and the like, but it still
>means you can't *really* trust a properly-signed message.

The Received headers are also signed.  This prevents a replay attack.  BTW, 
DomainKeys is not an antispam solution.

Regards,
-sm