[arc-discuss] Question for draft-andersen-arc-00.txt -- ARC-Authentication-Results placement
roland at rolandturner.com
Wed Nov 11 16:21:12 PST 2015
On 11/11/2015 11:50 PM, James Baldwin via arc-discuss wrote:
> I've found a confusing section in the draft. Can I get some help to
> Section /5.1.3 ARC-Authentication-Results/ states "The header field
> can appear only once in a single message." and the examples in the
> appendix support this statement. However, the following section /5.2
> Constructing the ARC-Seal Header Set/ states "3. The
> ARC-Authentication-Results header MUST be the last item in the list."
I feel that this is a bug/misfeature in the draft and that the sensible
fix is to specify that the ARC-Seal Header Set always include
A rationale for only recording it with the first ARC seal is that once
the DKIM-signed fields of the message are modified, all of the results
are going to be "fail" so the 2nd and subsequent instances are adding no
information. I'd suggest that it's possible, even likely that this
assumption will fail in two important, potentially common cases:
1. For simplicity of implementation, some operators may decide to
ARC-Seal every message each time they add a Received: header (or at
least do so more often than at each DKIM break). This potentially
means (a) adding an ARC-Authentication-Results header before the
first DKIM break and therefore none after, eliminating much of the
visibility that ARC is intended to provide and (b) the sole
ARC-Authentication-Results headers being added by a forwarder that
the end receiver doesn't know enough about to trust, again
eliminating much of ARC's intended benefit.
2. A forwarder changes the domain of the RFC5322.From address but
doesn't strip the existing ARC-* headers. In this case there would
be no ARC-Authentication-Results headers relating to the
RFC5322.From address as seen by the receiver.
If the proposed fix was the addition of more mechanism and more
complexity then there might be reason for pause, but in this case the
proposed fix is a reduction in complexity: just include
ARC-Authentication-Results in every ARC-Seal Header Set, delete any text
that explains when not to.
* My argument above opens with a strawman: there may well have been
(an)other rationale(s) for the first-time-only rule, in which case
I've not addressed the relevant argument(s). It would be worth
understanding what the drafters intended.
* I've argued previously that there is benefit in ARC even if there
are DKIM breaks happening at forwarders who don't ARC sign but
where, say, the ADMDs before and after the DKIM break do ARC sign,
as it allows receivers to perform much of the same sort of analysis
and decision-making. ARC-Authentication-Results at each step would
appear to strengthen this.
* It might appear that the ARC-Message-Signature makes this redundant
and that the first-time-only ARC-Authentication-Results is simply
about mapping a message's transition from authenticate-by-DKIM to
authenticate-by-ARC. Both of the cases listed above would appear to
break this, although I'm having difficulty at this moment convincing
myself either way.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the arc-discuss