Andreas Schulze wrote: > 2) > a general point I'm still unsure about: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage say in 2.) > >> "If the mailing list implemented ARC, ..." > > ARC *require* the list operator (Intermediary) to install new or update > existing - right?
No. ARC seeks to construct a situation in which forwarders and receivers will each gain incremental benefit if they choose to implement; it neither requires nor assumes implementation by any particular participant. > But the list operators fail over the last years to do so. Why should I expect > they will do now? List operators typically cite two compelling reasons for not making changes to support pre-ARC schemes: 1) the assumption that they're being asked to expend resources to solve someone else's problems; and 2) even if resource constraints are ignored, each of the proposed changes imposes harmful dilemmas (each option, including do nothing, is harmful). ARC directly addresses (2). Unlike the measures for interoperating with earlier schemes, adding an ARC-* header set does not in any way impede or alter the traditional operation of mailing lists. Consequently: if list operators perceive benefit in implementing ARC, then they're free to do so without having to incur additional operational problems, in particular without changing user experience. (1) is not a big problem; for a list operator who doesn't have a problem that ARC addresses there is no reason for them to implement ARC, and it doesn't matter to anyone else if they don't. - 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)
