Thanks for the comments, Frank. More below.
Tony Hansen
tony(_at_)att(_dot_)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(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html