On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank <[email protected]> wrote:
> Replace 5.1.1 with: > > 5.1.1. ptypes and properties for arc-info > > Certain information pertinent to ascertaining message disposition can be > lost in transit when messages are handled by intermediaries. For example, > failing DKIM signatures are sometimes removed by MTAs, and most DKIM > signature on messages modified by intermediaries will fail. Therefore, a > passing DKIM-Signature from the first ARC signer is likely to have been > removed by final receipt of the message. > > The AAR, and in particular the ptype-properties stamped in arc-info, > provide a mechanism for this information to survive transit. > > The ptypes and properties defined in this section SHOULD be stamped in the > AAR: > > * smtp.client_id - The connecting client IP address from which the message > is received; > * header.ds - The domain/selector pair for each dkim signature on the > message (header.ds=example.com,selector) > * arc.closest_fail - The hop number of the most recent AMS that fails to > validate, or 0 if all hops pass. > Why "client_id" instead of "client-ip"? (it's an IP address, not some opaque identifier) Why "header.ds" and not "header.d" and "header.s"? (why combine them?) Why "arc.closest_fail" and not "arc.closest-fail"? (use a hyphen, to be consistent with other entries already in the registry) Unless someone wants to point me at the part of the spec that says otherwise, the IP address is utterly orthogonal to anything ARC is doing. I'd rather not shoe-horn it in here, even if DMARC operators might want it. Rather, we should do a separate document (outside this WG if needed) that registers a header field for this, since there's been something like X-Original-IP in public use for years anyway, and then just require that it be signed or something. Or if we really want it in A-R, register it accordingly, independent of ARC. But if we want to do that last thing, I'd like to have some sort of discussion on the record for changing the scope of A-R, which is really what we're talking about here. As I've said before, A-R's original purpose was to collect data about authentication work done at the ingress MTA that might be of interest to users or filters. We've specifically kept things like IP addresses unregistered on the basis that your average human won't know whether to trust one string of octets over another, and there's a treatise in the appendix of RFC7601 and all of its predecessors that lays out why. But that's the logic we applied eight years ago when RFC5451 was written. If in the intervening time we've decided we want to repurpose it to carry arbitrary stuff that might be of benefit to filters and concede that users aren't the likely primary consumers as we intended, then we should probably do up an RFC7601bis that says so, and renovate the prose and registries accordingly. I'll put the editing work in, but there has to be recorded consensus to back that move. =============== > > Open questions: > > 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601. > Unfortunately, authres-header was defined in a way that makes this > difficult. Is there a better way to say that the AAR inherits the A-R > payload, and if anything modifies the definition of authres-header in 7601, > the AAR also needs to inherit this change? > > To be super specific, this is the current authres-header ABNF from 7601: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > > Optimally, there would be: > > authres-payload = [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > > And then we could have: > > arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info > authres-payload > That seems reasonable to me. 2) The optimal way to transmit DKIM selector information is in the DKIM A-R > methodspec as header.s. If we want to prevent a normative modification of > 7601, I've proposed "header.ds" which will accomplish the same thing. > Why the merge? 3) In the ARC-Seal megathread, there was an aside about knowing the last > hop which validated: > > On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <[email protected]> > wrote: > > That seems like it would be enough to fix that objection. An additional > "first AMS failure" header at each hop would give you a list of who > actually modified the message. > > arc.closest_fail has been defined to accomplish this. > I'm not sure I like a hop number in here, which harkens back to Received counts. I'd rather say it's an instance number, or better yet the sealing domain name. 4) Have the ptype-properties been defined properly, and will these AAR > ptype-properties need an IANA registry? > If we decide we want AAR separate from of AR, then we also need to decide if AAR uses the AR registry (in which case all of this has to get mushed in with regular A-R stuff, but flagged "ARC use only" or something (ick), or we'll need our own registry (ugh). -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
