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?