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, vger.kernel.org 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@xxxxxxxxxxxxx>
To: linux-mtd@xxxxxxxxxxxxxxxxxxx
CC: tytso@xxxxxxx, dedekind1@xxxxxxxxx, ebiggers@xxxxxxxxxx,
mhalcrow@xxxxxxxxxx, adrian.hunter@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, hch@xxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, jaegeuk@xxxxxxxxxx,
dengler@xxxxxxxxxxxxx, sbabic@xxxxxxx, wd@xxxxxxx,
richard@xxxxxx, David Gstir <david@xxxxxxxxxxxxx>
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
linux-ext4@xxxxxxxxxxxxxxx or ietf@xxxxxxxx. :-)
[1] https://www.kernel.org/pub/software/scm/git/docs/git-am.html
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 <david@xxxxxxxxxxxxx>
AuthorDate: Tue Dec 6 23:53:57 2016 +0100
Commit: Theodore Ts'o <tytso@xxxxxxx>
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 foo@xxxxxxxxxx addresses
have reported *not* having DMARC problems when using mailing lists at
vger.kernel.org, despite the fact that google.com 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 vger.kernel.org (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 foo@xxxxxxxxxx via a vger.kernel.org mailing
list, is apparently still reaching torvalds@xxxxxxxxx, even though
google.com has a p=reject policy, and even though gmail.com 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
vger.kernel.org mailing list might get accepted by a recipient at
gmail.com, it might not be accepted by a recipient at yahoo.com ---
and that bounce might cause the yahoo.com recipient to get
automatically unsubscribed from the mailing list.
But that's probably fine, because no there are very few developers
using yahoo.com (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.
Cheers,
- Ted