RE: DMARC methods in mailman

"Christian Huitema" <> Fri, 23 December 2016 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A72C129582 for <>; Fri, 23 Dec 2016 14:17:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cOfjA1Z65-GJ for <>; Fri, 23 Dec 2016 14:17:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF0DE129591 for <>; Fri, 23 Dec 2016 14:17:49 -0800 (PST)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <>) id 1cKY9r-0004EL-E2 for; Fri, 23 Dec 2016 23:17:47 +0100
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1cKY9K-0007dZ-1i for; Fri, 23 Dec 2016 17:17:45 -0500
Received: (qmail 1078 invoked from network); 23 Dec 2016 22:17:13 -0000
Received: from unknown (HELO icebox) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 23 Dec 2016 22:17:13 -0000
From: "Christian Huitema" <>
To: "'Theodore Ts'o'" <>, "'Philip Homburg'" <>
References: <> <> <> <>
In-Reply-To: <>
Date: Fri, 23 Dec 2016 14:17:04 -0800
Message-ID: <001801d25d6a$4c267130$e4735390$>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJTUFwgm8CGp/ms3arndlGX5mSTQgKi6rsvAdD1m0oCjAWbm5/cMTZg
Content-Language: en-us
Subject: RE: DMARC methods in mailman
Authentication-Results:; auth=pass smtp.auth=
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.22)
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoLmG6b2EoUfbzOsBJzq/m/RcOb18WfxGyg6Om6u4YYm1KHQUPiuIbBZCOu DsIO1zs5hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qhQRCdMNhge1Unb77YyuZq5wxC2h6Cspc5fnLUJegyIWRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f3u07h1Ar0asfEVCjJZw/E01 aDvSI66S1J0VQ44N+76FbqAsde/tI5qyNqQcad7EjKmxVEE6gtF+B/lEIPzms74rHdmmurdkSlp8 bL7MuNSeJ6fVbIdD0RyyBL+RsQXLIsIclqURQOfTUwDe+Ri01fK//LgD8r/EmKnkLuRbKmSGYyUP r23raOD+k0BwTaZR7fY4ocfmWv3Fe9Iziczdq+A=
X-Recommended-Action: accept
Archived-At: <>
Cc:, 'S Moonesamy' <>
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: Fri, 23 Dec 2016 22:17:51 -0000

On Wednesday, December 21, 2016 7:12 AM, Theodore Ts'o wrote:

>On Wed, Dec 21, 2016 at 01:10:16PM +0100, Philip Homburg wrote:
>> ...
>> Or are you saying that at the moment 40% of the subscribers of IETF lists
>> or otherwise not receive mail from DMARC protected senders?
> It's much more likely that this is the percentage of subscribers that
> are sending from domains that are claiming a DMARC policy.  What's
> interesting is how few of these domains are actually *following* the
> DMARC specification in rejecting, unconditionally, e-mails which fail
> the DMARC checks.

I think that Ted is making a very strong point here. For the IETF mailing
list, the problem does not start when some company publishes a DMARC
"p=reject" policy. The problem occurs when some mail providers decides to
unconditionally bounce messages. These bounces are causing mail to be lost,
and subscribers to be disconnected from mailing list.

We have at least one big provider, Gmail, implementing a sane compromise:
reject the email if you do not have reasons to otherwise trust it. That is,
use some logic instead of bone headed unconditional behavior. From a user
point of view, that may mean having to fish specify that they "trust"quot;, maybe after fishing some messages out of the spam
folder. Not great, but much more light weight than most of the proposed
alternatives. So, in short, we have a solution with demonstrated working

Maybe the IETF should document this expected behavior as part of the mailing
list submission process. "If you want to participate in the IETF, your mail
provider should allow you to receive messages from the IETF."

-- Christian Huitema