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 <[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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
