I just read through the sender-auth-header-17 draft, and have a few comments, at the last minute (which I apologize for). I have gone through the details with Murray over the phone, so I'll describe them in general terms: Header field ordering In various places in the document, it talks about the need to insert the Authentication-Results header field at the top, in order to give an MUA using it an idea of "how far away" it was applied. It doesn't work to say "this needs to be handled as a trace header field" because that can't be done retroactively; you can't be sure that some MTA isn't going to twiddle the order. You definitely can't depend upon it from a security standpoint.
From talking with Murray, it sounds as though the intent is that the
ordering is primarily to help the MUA to find the most relevant header field quickly. This is fine with me, then. Murray has some wording changes that should make that more clear. Authentication identifiers I wasn't clear on whether the authentication identifiers are the hostnames themselves, or some identifier representing the administrative domain to which they apply. Apparently the intent is the latter, which I support. That helps domains add additional verifying MTAs without having to tell the entire user base that there's a new one. We (Cisco) currently have 18 or so verifying MTAs; who knows when we'll be adding more. DKIM results I'm a little concerned about "too much information" coming from the A-R header field...we want to encourage everyone to treat messages with broken signatures as if those signatures didn't exist, neither more or less favorably than without a signature. Returning different "fail" and "neutral" results might tend to encourage people to do the opposite. I'm a little sensitive about this because I have just been working with two different domains that were rejecting messages with broken DKIM signatures, and am trying to counsel them to do otherwise. I'm also a little uneasy with the "policy" result, especially with the last paragraph of 2.4.1 examples of making third-party signatures unacceptable. Again, "unacceptable" probably should be treated the same as "not present" -- otherwise some of the nascent uses we have envisioned (like mailing lists signing messages) will be torpedoed. Iprev It seems a little strange to me to introduce a new authentication method in the auth-results draft. If we need this, I think it should be in a separate draft/RFC. Auth-results is about representing the results of authentication, not how to authenticate. Header field removal I suggested additional text cautioning about (sec 5 paragraph 2) removing all auth-results header fields. I can picture that some users might want to trust Authentication-Results from specific domains (I might trust ietf.org, for example) especially if it was signed as described in section 8.1 #1. Security considerations 8.3 sounds like more information on the 8.1 Forged Headers item, and isn't a separate "consideration". 8.5 sounds like more of an SPF item than an Auth-Results item, except that it might still apply here if Iprev stays in the draft. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html