Hi, for some myths and legends about DKIM check out <http://slashdot.org/article.pl?sid=08/02/11/148209>
Reading the last DKIM overview I-D I think that the section starting with "historically" should start with something else if it talks about RFC 4408 and 4406. RFC 4407 is a fine summary of a key aspect in RFC 2822, but not directly related to IP-based decisions (apart from PRA uses in RFC 4406, where IPs enter the picture). In a "prior work" section about IP based decisions the ASRG DNSBL draft could be also referenced. For really historical "prior art" I'd expect a note about RFC 4870 (some comments on slashdot are very far off the track wrt Domainkeys). If the "Date:" shown in an RFC 4870 example is a real DK example, then Domainkeys is older than SenderID, for what's it worth (IMO the age is irrelevant - ignoring the needs of patent trolls). Section 3.2.2 says that OpenPGP modifies the body of an email. Is that still necessarily the case ? 4.4: | Typically, verification will be done by an agent | in the Administrative Management Domain (ADMD) of | the message recipient. As recipient of mails to mailboxes in various ADMDs I doubt that this is "untypical". One disadvantage of the term ADMD is that it is too fine grained for many "typical" scenarios. Section 5 uses "relaying or delivering ADMD", that is better for cases where this job is done by only one ADMD (no third parties with their own ADMDs involved). The "ADMD" problems could be eliminated by adopting the terms MON and MRN, sometimes fuzzier is better. Identifying MSA and MON is fine. But for a similar attempt wrt MDA and MRN the SMTP folks hit me hard with their Bat books: Where you write "MDA" it is the "final delivery MTA" as noted in RFC 2821, not some "local mail" MDA behind SMTP. Please check the MDA definition with Eric (or in the Bat book), admittedly I got that wrong for some years... :-( 5.6: | the authoring organization's outbound service and | the receiving organization's inbound service, Talking about ADMDs the more interesting cases are services (plural), one service is straight forward. | A Mediator, such as a mailing list, often can | re-post a message without breaking the DKIM | signature. In theory it *can* do that always, but the problem is that it might be often not the case in practice. The overview document should mention such issues - at the moment it sounds more like a commercial for DKIM and reputation services than a potential RFC. The OpenPGP 2440bis draft is now RFC 4880. RFC 4870 is listed, but not referenced in the text. Curious folks are likely also interested in the "IM" part of the "DKIM" history, not only the RFC 4870 "DK" part. When you use email-arch terms "mediator" and "ADMD" just reference the corresponding I-D. If there are slight differences between A.1 and email-arch ADMDs you got me (= I didn't check it). Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
