[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