Subject: [ietf-dkim] DKIM slashdotted

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 11 Feb 2008 21:54:16 +0100

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

---

From: Tony Hansen <[email-masked]>
Date: Mon, 11 Feb 2008 17:55:57 -0600

Thanks for the comments, Frank. More below.

	Tony Hansen
	[email-masked]

Frank Ellermann wrote:
> ... Reading the last DKIM overview I-D I think that the

The 4406-4408 references were added as a set of examples where IP 
addresses and content were used for determining identity.

> admittedly I got that wrong for some years... :-(

We considered some variations on this theme, and still came back to what 
you see.

> the "DKIM" history, not only the RFC 4870 "DK" part.

Thanks for reminding us of the additional refs.

> 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
	[email-masked]

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Feb 2008 00:52:55 +0100

Tony Hansen wrote:

> Timing is king; we'd rather not have this section at all,
> but expect it to go out the door before email-arch does.

For an informative reference an I-D could be good enough.
You have a reference to the Authentication-Results I-D.

Checking that email-arch is at "PubReq" I found that you
know all about its state... :-)  The auth-header I-D is 
not at "PubReq", I have only bookmarked but not yet read
the new auth-header-11.  But "overview" has a reference
to "auth-header", and "auth-header" to "email-arch", and
so you are anyway in one boat wrt timing.

 Frank

---

From: Jon Callas <[email-masked]>
Date: Mon, 11 Feb 2008 16:06:12 -0800

> of an email.  Is that still necessarily the case ?

I'm not sure I know what that means.

	Jon

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Feb 2008 16:35:06 -0800

It means that applying PGP results in a body that is modified.  Note the 
Begin/End...

d/

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 2.6.3
> Charset: US-ASCII
> 
> wj8DBQFHsOL1sTedWZOD3gYRAqO3AJ0cORFo3Q2HA7168BfySqTkAmK2aQCfY0Pm
> MeMy7U0LdBfx1ap3jq2L30Y=
> =TVcX
> -----END PGP SIGNATURE-----

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net