[ietf-dkim] draft-ietf-dkim-overview-08 (was: DKIM slashdotted)
Tony Hansen
tony at att.com
Mon Feb 11 15:55:57 PST 2008
Thanks for the comments, Frank. More below.
Tony Hansen
tony at att.com
Frank Ellermann wrote:
> ... 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).
The 4406-4408 references were added as a set of examples where IP
addresses and content were used for determining identity.
> 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... :-(
We considered some variations on this theme, and still came back to what
you see.
> 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.
Thanks for reminding us of the additional refs.
> 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).
Timing is king; we'd rather not have this section at all, but expect it
to go out the door before email-arch does. And yes, the two docs are
meant to be compatible.
Tony Hansen
tony at att.com
More information about the ietf-dkim
mailing list