Re: DMARC: perspectives from a listadmin of large open-source lists

"Robin H. Johnson" <> Tue, 08 April 2014 05:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 962DF1A012C for <>; Mon, 7 Apr 2014 22:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.311
X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xsWY8fMzSuds for <>; Mon, 7 Apr 2014 22:38:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D62DA1A012F for <>; Mon, 7 Apr 2014 22:38:00 -0700 (PDT)
Received: from (localhost []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19A3B33FF98 for <>; Tue, 8 Apr 2014 05:37:55 +0000 (UTC)
Received: (qmail 15095 invoked by uid 10000); 8 Apr 2014 05:37:52 -0000
Date: Tue, 8 Apr 2014 05:37:52 +0000
From: "Robin H. Johnson" <>
To: John R Levine <>
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
Message-ID: <>
References: <> <alpine.BSF.2.00.1404072357400.73388@joyce.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IfZ+tgy+ooJOsAAy"
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.00.1404072357400.73388@joyce.lan>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Tue, 08 Apr 2014 08:55:21 -0700
Cc: IETF general list <>, "Robin H. Johnson" <>,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Apr 2014 05:38:05 -0000

On Tue, Apr 08, 2014 at 12:21:46AM -0400, John R Levine wrote:
> You would have to track which forwarders are well behaved and add
> valid X-O-A-R headers, but if you can do that, you can skip the header
> analysis and just whitelist the mail from the well behaved forwarders.

The XOAR proposal does specify:
| The X-Original-Authentication-Results header is only useful if the
| forwarder is trusted.  The forwarder is free to modify the headers and
| body of the message however it wishes and can generate new signatures
| over arbitrary X-Original-Authentication-Results headers.  Thus, the
| user SHOULD only trust X-Original-Authentication-Results if the message
| was delivered by known good forwarders, and forwarders SHOULD NOT
| propagate X-Original-Authentication-Results unless the previous
| forwarder is known to be good.
| For the purposes of this memo, a message was delivered through trusted
| forwarder if:
| - The DKIM signature passes
| - The DKIM domain is a trusted forwarder

I think the original scenario you described could be implemented by bad
players as follows:
- set up a mailman instance with DMARC support, that forges the XOAR
- Ensure that the mailman outgoing mail passes SPF+DKIM for the domain
  in question.

> Note that there are also well behaved things that don't pass DMARC and 
> don't have any original authentication results to report, with the usual 
> examples being mail-an-article at the NY Times and Wall Street Journal.
Those uses shouldn't be considered valid, and NYTimes has already moved
away from that, at least as of my test 5 minutes ago.
| RCPT TO:<>
| ...
| From: robbat2 <>
| Sender:
| To:
| ...

> > The problem described WILL vanish when all mailing list apps implement
> > DMARC, but until then, it's really broken.
> Mailing list apps can't "implement DMARC" other than by getting rid of 
> every feature that makes lists more functional than simple forwarders. 
> Given that we haven't done so for any of the previous FUSSPs that didn't 
> contemplate mailing lists, because those features are useful to our users, 
> it seems unlikely we'll do so now.
By implement DMARC, I meant implement XOAR headers; VERP is too useful
to running lists to get rid of. Non-VERP bounce messages are still too
generic, even in this modern day.

Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     :
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85