In your letter dated Sun, 25 Dec 2016 13:05:59 -0500 you wrote: >More importantly, recipients don't always know whether they need anti-DMARC >armour or not, and are neither responsible for nor consulted on potential >changes in the receiving domain's policies. Therefore, per-recipient policy >is unlikely to work well. > >If message (subject and/or body) modification is a hard requirement, then >it seems that for now anti-DMARC measures are needed in the "From:" header. >FWIW, my view is that forgoing message modification is better than From >mangling. If we are to assume that suscribers to technical mailing lists like the IETF are stupid enough to pick mail providers that drop mail based on non-standard mail extension like DMARC, without being aware that they did so, them I'm also fine with a knob that by default mangles the >From header as long as I can turn it off for myself. Breaking mailing list for everybody just because as small group is stupid enough to use mailing breaking mail-extensions is extremely bad. Note I don't care if your employer uses DMARC, use a personal account then. I don't care if your free e-mail comes with idiotic filtering, subscribe to the lists from a sensible mail account then. In any case, just because there is a small group of people that are set on using non-standard extenisons, or to ignorant or lazy to avoid them, that's not a reason to break mailing lists for everybody. >The need for email origin authentication to specify that "Sender" preempts >"From" has been well understood for a long time before there there was DMARC. >If there is to be a non-broken replacement, it must correct this design error >and place the "burden" of dealing with that on any MUAs that fail to display >Sender (as e.g. from <sender> on behalf of <author>). You are saying that the IETF has any infuence over a specification that came in through the independent stream editor?