Re: Realistic responses to DMARC

Theodore Ts'o <> Sun, 18 December 2016 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BF16129530 for <>; Sat, 17 Dec 2016 22:59:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wv6SKxIwatYK for <>; Sat, 17 Dec 2016 22:59:37 -0800 (PST)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C933E129457 for <>; Sat, 17 Dec 2016 22:59:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=D1v6HNCwY2xutzZYDIBzRtv6+0fxqZhUGxsjBmzmLmU=; b=jFn11G6/uE0zRgYG+gG0Yd3K2LItQXe5D/+aABtsMz20+r/V1txaVZLLdnaxKbutMh2ku+TItTBU+mojeLwG7bRdIj/ENrXryye+vJEaC7zYuG3icDE/BflJYOAfxrbx9+VXy9nsNEdhQv7/iwXG6+auTuFciAtJ22kpCk1+QRE=;
Received: from root ( by with local-esmtp (Exim 4.84_2) (envelope-from <>) id 1cIVRX-0000jU-UC; Sun, 18 Dec 2016 06:59:35 +0000
Received: by (Postfix, from userid 15806) id 208B0C003E4; Sun, 18 Dec 2016 01:59:05 -0500 (EST)
Date: Sun, 18 Dec 2016 01:59:05 -0500
From: Theodore Ts'o <>
To: John R Levine <>
Subject: Re: Realistic responses to DMARC
Message-ID: <>
References: <9AD6AAD6812D3B9F8379226B@PSB> <20161218022823.8779.qmail@ary.lan> <> <alpine.OSX.2.11.1612180101460.14297@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.OSX.2.11.1612180101460.14297@ary.qy>
User-Agent: NeoMutt/20161126 (1.7.1)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Cc: IETF general list <>
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: Sun, 18 Dec 2016 06:59:41 -0000

On Sun, Dec 18, 2016 at 01:04:14AM -0500, John R Levine wrote:
> Yes, those are the only choices at this point.
> > I can think of one major open source project (namely, the Linux
> > kernel) which has refused to do either.
> I'm reasonably sure you're mistaken here.  Don't they rewrite From: headers?

Nope, doesn't rewrite from headers.  An example of a
recent e-mail I received from the linux-fsdevel maliing list:

    Date: Tue, 6 Dec 2016 23:53:57 +0100
    From: David Gstir <>
  , David Gstir <>
    Subject: [PATCH v2 5/6] fscrypt: Delay bounce page pool allocation until needed
    X-Mailer: git-send-email 2.10.1
The fact that the from field is not rewritten is *IMPORTANT* because
rewriting the from field would break the "git am" command[1], since it
uses the From: field to fill in the git commit's from field, and it
would be sad if all of the git commits had an authorship of or  :-)


This is what allows the above mail headers to result in a git commit
which looks like this when applied using "git am":

commit f32d7ac20a5864483c1f96e4970daa083e18bfd1
Author:     David Gstir <>
AuthorDate: Tue Dec 6 23:53:57 2016 +0100
Commit:     Theodore Ts'o <>
CommitDate: Sun Dec 11 16:33:11 2016 -0500

    fscrypt: Delay bounce page pool allocation until needed


I will note that at least some people with addresses
have reported *not* having DMARC problems when using mailing lists at, despite the fact that has a dmarc p=REJECT
policy.  I can only guess (from external observation; I haven't looked
at any of the gmail anti-spam algorithms, nor do I have any interest
in looking at them) that even a DMARC p=reject is probably only
resulting in a very high spam score, but using either machine learning
or a manual setting, mail from (with perhaps certain
text features from the body of the e-mail very clearly not offering
the sale of pharmaceuticals or making money fast) is given a
sufficiently high score to offset the p=reject score.  And so
apparently mail sent from via a mailing
list, is apparently still reaching, even though has a p=reject policy, and even though purports
to honor the DMARC spec.

Which brings up something interesting/important about DMARC --- what's
important is not just the DMARC policy of the sender's domain, but
also how the recipient domain is handling the DMARC policy.  It's
pretty clear that some recipient domains are not following the DMARC
specification strictly with respect to rejecting p=reject e-mail addresses.
So while mail sent by a sender who's domain has a p=reject via a mailing list might get accepted by a recipient at, it might not be accepted by a recipient at ---
and that bounce might cause the recipient to get
automatically unsubscribed from the mailing list.

But that's probably fine, because no there are very few developers
using (and probably up to a billion fewer now :-).  And so
as we can see, even honoring DMARC policies can cause mailing list
participants pain; it's not just sending from p=reject domains that
cause pain in terms of possibly unreceived e-mail (and possibly
bumping people in the first category off the list due to
auto-unsubscription policies).

Therefore, a developer-friendly mail service MUST NOT have a p=reject
or p=quarantee DMARC policy, and MUST also ignore DMARC policies on
the receiving end.  Fortunately, these mail services do exist, even if
they aren't the big, free consumer ones.


					- Ted