Lynn Wheeler wrote: > recently published IETF RFC > > ... from my IETF RFC index > http://www.garlic.com/~lynn/rfcietff.htm > > 4686 I > Analysis of Threats Motivating DomainKeys Identified > Mail (DKIM), > Fenton J., 2006/09/26 (29pp) (.txt=70382) (Refs > 1939, 2821, 2822, 3501, 4033) (was > draft-ietf-dkim-threats-03.txt) > > from the introduction: > > The DomainKeys Identified Mail (DKIM) protocol is > being specified by the IETF DKIM Working Group. The > DKIM protocol defines a mechanism by which email > messages can be cryptographically signed, permitting a > signing domain to claim responsibility for the use of > a given email address. Message recipients can verify > the signature by querying the signer's domain directly > to retrieve the appropriate public key, and thereby > confirm that the message was attested to by a party in > possession of the private key for the signing domain. > This document addresses threats relative to two works > in progress by the DKIM Working Group, the DKIM > signature specification [DKIM-BASE] and DKIM Sender > Signing Practices [DKIM-SSP].
In order for this to actually be any use, the recipient needs to verify the signature and do something on the basis of that signature - presumably whitelist email that genuinely comes from well known domains. Unfortunately, the MTA cannot reliably do something - if it drops unsigned mail that is fairly disastrous, and the MUA cannot reliably check signatures, since the MTA is apt to mess the signatures up. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
