And again from the right address, sigh. Brandon
On Fri, Dec 1, 2017 at 2:10 PM Brandon Long <bl...@google.com> wrote: > > > > On Thu, Nov 30, 2017 at 11:38 PM Murray S. Kucherawy <superu...@gmail.com> > wrote: > >> On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank <s...@sethblank.com> 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) >> > > agreed on ip instead of id. > > Why "header.ds" and not "header.d" and "header.s"? (why combine them?) >> > > agreed on not combining things like this, sure string.split is easy and > all, but let's use the parsing/etc we already have. > > Brandon > > 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. >> > +1 to 7601bis on Kurt's terms. > >> =============== >>> >>> 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 <br...@fastmailteam.com> >>> 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 >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
