Re: [IETF] DMARC methods in mailman

[Philip Homburg <[e-mail]>]

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?