[arc-discuss] Question for draft-andersen-arc-00.txt -- ARC-Authentication-Results placement

Roland Turner 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 
> clarify?
>
> 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 
ARC-Authentication-Results.

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.

Related thoughts:

  * 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.

- Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dmarc.org/pipermail/arc-discuss/attachments/20151112/a758746b/attachment.html>


More information about the arc-discuss mailing list