Shal wrote: > Although I think ARC is a step forward, I think it still leaves list > managers with a bit of a conundrum, at least in the near and moderate > term: at what point does it make sense for the list service to invest > the effort in implementing ARC processing?
There are multiple answers: - The earliest adopters are likely to be the large forwarders who are creating problems for large receivers, in many cases these are the same organisations. These people are presumably already talking to each other. (Jmail's postmaster notices that 30% of his probably-OK DMARC forwarding failures are passing through KMail; Jmail's postmaster contacts Kmail's postmaster...) - Another group of likely early adopters are list operators who decided that DMARC just wasn't their problem and therefore pushed their Yahoo! users to move to Gmail. As this strategy is about to stop working abruptly, at least some of these list operators are likely to have reason to explore ARC signing. - Forwarders who are large enough to be monitoring deliverability can trivially determine whether their ARC-signing is being successfully validated and/or when receivers trust them enough to accept messages despite failing DMARC. There may be other groups that I've missed, but everybody else should probably keep their workarounds in place until the experiment has progressed to the point where the large receivers are publicly announcing that the water is fine. This is separate from the question of when to start ARC signing, that's probably worth doing sooner rather than later in order to shake out any bugs. > The conundrum I foresee is that the service can't know which receiving domains > have implemented ARC processing - and so can't know whether ARC processing > will > be effective at getting their messages delivered, that is, effective as > compared > to taking ownership. I don't know anything about groups.io, but: - Authentication-Results: headers are likely to show ARC results fairly promptly in receivers that implement it, meaning that it will be apparent whether or not signatures are validating. - Hopefully groups.io is already monitoring deliverability. If not, then they should probably keep their workarounds in place for the foreseeable future. > Now it is also true that the service can't know which receiving domains > implement > DMARC processing, except by way of public announcements or user complaints of > non-delivery. This is not entirely correct. DMARC aggregate reports and Authentication-Results: headers both make clear whether (a) a receiver is implementing DMARC and (b) validation is succeeding. Receivers who are doing neither of these things should be treated pessimistically (treated as not implementing DMARC if you are a Domain Owner, or as implementing DMARC if you're a DKIM-breaking forwarder). In ARC's case, Authentication-Results: headers will pretty quickly make clear which [large] receivers are implementing ARC and whether signatures are validating. Deliverability monitoring will be required to determine whether trust is being extended. > So I think ARC is a solution for list managers only if its adoption rate > approaches > 100% among mail receivers who implement DMARC processing. It's not a binary question, adoption happens in phases (e.g. the early adopters identified above will tend to go first) and even within an adopter happens in steps (implement ARC signing first, drop DMARC workarounds for test lists and monitor the results, etc.). No-one should be looking at ARC as plug-and-play, any more than they should at DMARC as plug-and-play. - Roland _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
