Re: [IETF] DMARC methods in mailman

Viktor Dukhovni <> Tue, 27 December 2016 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1498129AD7 for <>; Tue, 27 Dec 2016 11:02:29 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p1UC2t-rbjMc for <>; Tue, 27 Dec 2016 11:02:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C497129AD5 for <>; Tue, 27 Dec 2016 11:02:28 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3D6E0282D54 for <>; Tue, 27 Dec 2016 19:02:27 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [IETF] DMARC methods in mailman
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Tue, 27 Dec 2016 14:02:26 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <20161227013401.11378.qmail@ary.lan> <03e401d25fe5$5f32a5f0$1d97f1d0$> <> <000201d26070$248a9030$6d9fb090$> <>
To: IETF general list <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: IETF general list <>
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Dec 2016 19:02:30 -0000

> On Dec 27, 2016, at 1:46 PM, Dave Crocker <> wrote:
> Worse, Viktor's line of logic presumes the modified From field somehow gets the message past filters better, and that is just plain wrong.

I was not suggesting any modification of the message From: line.  Rather
I was applauding the fact that Outlook (for one) presents a more detailed
view of the message headers than is common practice.  In particular, it
augments the displayed origin information with Sender context when present.

If "Sender + From" are displayed as in Outlook, then it becomes reasonable
to authenticate Sender when present, and not apply authentication policy
to "From", since the message is not in fact *from* the author.  It is from
the sender, (purportedly) on behalf of the author.

It is rather implausible that phishers will want to present their messages
this way (on behalf of), most users don't receive such email, and it will
stand out as unexpected.  And users who still believe such messages to be
legitimately *from* the purported author and fall victim to scams will fall
for a myriad other misdirections.

Breaking legitimate use-cases (lists) in order to fail to "solve phishing"
is counterproductive in my view.  Yahoo's DMARC cost reduction would also
be equally effective if they displayed "on behalf of" given "Sender:"
as in Outlook, and authenticated the Sender domain instead.  This would do
no damage to mailing lists.