Subject: [dmarc-ietf] ARC draft-08 spec section 9.4

From: Seth Blank <[email-masked]>
Date: Tue, 5 Sep 2017 15:34:18 -0700

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08#section-9.4

There was an earlier thread about the proper way to handle this (
https://mailarchive.ietf.org/arch/msg/dmarc/Mz3xIgdB_OuBUqt9OlaZ9_feUpI).

I want to suggest a different direction:

    Section 9.4 should be removed in its entirety.

Returning a 421 tempfail is a bad idea for several operational and security
reasons:
- it can create generate backscatter
- one could craft a legitimately ARC signed message and then pull DNS
records resulting in a 421 ddos ping-ponging amongst intermediaries

But more importantly, because of the nature of how ARC works and mail
servers function, there is no way to handle temporary failures cleanly,
especially because (as per the thread I linked to) sometimes delivering a
message with arc=fail is better than tossing it back (for instance, when
dmarc still passes on final receipt, and you'd otherwise by impeding a
legitimate message).

If anything, section 9.4 should state that all temporary failures are
permanent ARC failures. Messages in this situation MUST be capped with
cv=fail and passed along upstream. Stamping the A-R prior to sealing with
arc=tempfail could be quite valuable to upstream receivers, but doesn't
change the fact that the chain is dead.

Seth

---

From: Brandon Long <[email-masked]>
Date: Tue, 5 Sep 2017 16:20:12 -0700

On Tue, Sep 5, 2017 at 3:34 PM, Seth Blank <[email-masked]> wrote:

> Returning a 421 tempfail is a bad idea for several operational and
> security reasons:

more so than a dmarc failure would?

> dmarc still passes on final receipt, and you'd otherwise by impeding a

I think arc=tempfail is a valid input to the DMARC decision, and I think
it's a good idea for DMARC to upgrade a REJECT to a temp failure based on
temp failure of any inputs.

As a datapoint, we've upgraded 1.3% of REJECTs in the past week to temp
failures, which "fixes" more DMARC false positives than we expect ARC to do
(mostly because of the incremental benefit of ARC over our current XOAR
scheme).

I'm unclear if there is any benefit for this being in the ARC spec,
however.  It would appear to be a useful addition to the DMARC spec or
useful in a BCP for either.

> change the fact that the chain is dead.

I pointed this out before, but this is potentially another case where
participating in the chain is worse than non-participation.

If the status of a hop's arc verification is tempfail, not participating
means if you are a non-modifying hop, the next hop may be able to verify
the chain.  Capping the chain as a failure prevents that.

Yes, yes, a DNS failure for one hop is likely to be a failure at the next
hop as well, since the hops are temporally similar, and although I say
there's always another hop, statistically, we're already talking about the
second hop here, and the number goes down quickly from there.

Brandon