On Tue, Sep 5, 2017 at 3:34 PM, Seth Blank <s...@sethblank.com> wrote:
> 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 > more so than a dmarc failure would? > - 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). > 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. > 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. > 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
