Subject: [ietf-dkim] New Issue: Appendix A in "overview"

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 13 Mar 2008 14:30:06 +0100

While I'm not exactly a fan of all details in "email-arch",
I really do not like to reinvent the wheel, especially if
that could result in inconsistencies.  Appendix A is better
covered in the "email-arch" memo, so why not reference it ?

I'd understand "timing problem", but then the overview has
the same problem with its "sender-auth-header" reference.

The last round of "email-arch" reviews arrived at editorial
nits in the security and I18N considerations, it's at least
as near to (some value of) ready as "sender-auth-header".

 Frank

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 14 Mar 2008 12:50:14 +0100

> the same problem with its "sender-auth-header" reference.

Screw that, the last sender-auth-header-13 still has its own
"email-arch" reference, therefore using "email-arch" also in
"overview" can't be a timing issue.

Unrelated, I just reviewed sender-auth-header-13, could the
DKIM experts here please also check it, especially section
2.4.1 ?  AFAIK some wannabe-DKIM results in 2.4.1 are wrong:

There is no "policy" result in DKIM, or if it makes sense it
could be also used elesewhere.   There is no "fail" and no
"neutral" in DKIM, both are by definition the same as "none"
(unsigned).

The draft also covers Domainkeys, please check if all as it
should be for DKIM vs. Domainkeys.  Are "policy", "neutral",
and "fail" in section 2.4.1 results needed for Domainkeys ?  

 Frank