Bumping this, too. All items below are still open. On Fri, Oct 6, 2017 at 8:27 PM, Seth Blank <s...@sethblank.com> wrote:
> 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
