The message quoted below deserves discussion, which didn't take place on the IETF list where it was originally posted: https://mailarchive.ietf.org/arch/msg/ietf/0sFUeCumvE8ij6Y92H9CvLKSTJY
Since ARC adoption, that discussion belongs to this WG list. So I reply here. On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote: > On 8/13/2016 8:10 AM, John R Levine wrote: >> More to the point, ARC lets lists keep working they way they're supposed >> to. > > I participate in the informal group that created ARC. I am hoping ARC > will be helpful. > > But we need to be cautious with our expectations. First, it isn't > operational yet, so we don't even know whether it will do what we want > it to. Worse, we don't know how much that will help. > > That's not a claim that it won't work or won't be useful, but it is > playing amidst some Internet-scale, multi-stage dynamics that can get > complicated. > > By way of example: With DKIM, trust assessment is of the entity doing > the signing, typically the originating service. With ARC, that > assessment still must be made, but it must be coupled with an assessment > of the first ARC-signing entity. > > Maybe that's not a big deal. But I think that combinatorial trust > assessments are new and therefore might be challenging. That challenge can only be accepted by mailbox providers who are large enough to maintain a statistically meaningful perspective of global Internet mailing. Smallish MTAs will likely have to take recourse to dnswl.org, possibly after some more attempts at creating protocol-specific white lists. Formal criteria to establish when valid ARC fields can inhibit DMARC's policy would seem to be better suited for protocol specifications. I proposed ARC-0, [0] but there may be better methods than that. [0] Proposal to adopt ARC documents into the WG (toward phase 2 milestone), 11 May 2016: http://mailarchive.ietf.org/arch/msg/dmarc/RXpz36Rs_aXvhlt9Tkpi89LJmrI > And that's not counting the question of whether an ARC signature will > survive better than a DKIM signature... (The design is intended to have > better survival, but again, it hasn't been tested in the field.) SMTP currently warns that, in some unspecified cases, "more caution and conservatism should be applied when considering whether or not to perform fixes and how." Some implementations[1] look for DKIM signatures and refrain to fix if any is found. Rather than just adding ARC's fields to the list of header fields whose presence should prevent fixing, it might be more stable to standardize a generic method to signal that caution and conservatism should be applied --unless we think ARC is the final, ultimate message signing technique, that is. [1] For one, parameter NOADDRREWRITE, as documented in: http://www.courier-mta.org/submit.html Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
