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
_______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
