Re: [IETF] DMARC methods in mailman

Philip Homburg <> Mon, 26 December 2016 12:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72D671294D1 for <>; Mon, 26 Dec 2016 04:34:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cz9ymImr9Qos for <>; Mon, 26 Dec 2016 04:34:06 -0800 (PST)
Received: from ( [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by (Postfix) with ESMTP id 68661127076 for <>; Mon, 26 Dec 2016 04:34:04 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (Smail #91) id m1cLUTY-0000HWC; Mon, 26 Dec 2016 13:34:00 +0100
Message-Id: <>
To: IETF general list <>
Subject: Re: [IETF] DMARC methods in mailman
From: Philip Homburg <>
In-reply-to: Your message of "Sun, 25 Dec 2016 13:05:59 -0500 ." <>
Date: Mon, 26 Dec 2016 13:33:58 +0100
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Dec 2016 12:34:08 -0000

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

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?