Re: [dmarc-discuss] ARC adoption
Roland Turner via dmarc-discuss: 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. Hello all, thanks for your responses. to repeat with my words: ARC is an offer to Intermediaries which does even not require to change any semantics. And for that reason there is chance for adoption. hope I understood it correct ... Andreas ___ 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)
Re: [dmarc-discuss] ARC adoption
+ dm...@ietf.org because Roland's responses should be considered/captured there too. Additional comment bottom-posted. On 6/29/16 12:09 AM, Roland Turner via dmarc-discuss wrote: 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 Well put, Roland. I was so concerned with addressing the frequently asked question of "why will people upgrade" that I overlooked other considerations in my earlier response. --S. ___ 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)
Re: [dmarc-discuss] ARC adoption
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)
