Questions 1, 2, and 4 as they relate to the text I suggested are still open - and I don't believe the text that was pulled into -09 is correct until these questions are answered.
On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank <s...@sethblank.com> wrote: > There have been substantial comments both on and off list about section > 5.1.1. I've suggested new language for all of 5.1, below, to remove > normative modification of 7601, and address several other issues. There are > questions for the WG below the suggested text. > > =============== > > Replace 5.1 with: > > The ARC-Authentication-Results (AAR) header field is semantically and > syntactically identical to the Authentication-Results header defined in > [RFC7601#2.2] as authres-header (A-R), except that the first element > “Authentication-Results:” in authres-header is replaced with > arc-authres-prefix as follows: > > arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] > arc-info > > arc-info = %x69 “=” arc-hop *([CFWS] “;” [CFWS] propspec) [CFWS] “;” > > arc-hop = 1*2DIGIT ; 1-50 > > The purpose of this header field is to transmit the results of any > authentication done on the message upstream to participating ADMDs > validating and continuing the chain. > > The AAR MUST contain all A-R results from within the participating ADMD, > regardless of how many A-R headers are on the message. > > =============== > > 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. > > =============== > > 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 > > 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. > > 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. > > 4) Have the ptype-properties been defined properly, and will these AAR > ptype-properties need an IANA registry? > > 5) Finally, the ams[n] and as[n] entities were dropped, as these values > are guaranteed to be on the final message if an ARC chain passes, so > there's no need to encode them separately. > > Seth >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
