Hi, I've been invited by Murray Kucherawy and Franck Martin to
participate in these discussions, so let me introduce my affiliation
briefly. I've been operating GNU Mailman lists since 1999, an
occasional contributor for about 10 years, and a GSoC Mentor for
Mailman since 2012. I have somewhat ambiguous authorization to speak
for the developers (ie, a rolling consensus of the Mailman Steering
Committee[1]).
Tim Draegen writes:
> John, you are very difficult to communicate with, maybe because
> you're easily insulted, even when there is no insult. I too have
> been in correspondence with mailing list developers,
Which ones? GNU Mailman is now here. Besides me, John is a reliable
source of summaries of past Mailman list discussions in what I've read
of his posting here.
I'm sure in the following I'll be going over a lot of ground that's
been covered before, but since you think it's controversial enough to
address, I hope I'll be forgiven for a certain degree of redundancy.
> and also developers behind businesses that rely on email,
That's insufficiently precise. To my mind, there are two kinds (at
least) of businesses that rely on provision of mailboxes (other use
cases follow).
(1) Corporate use case: mailboxes are provided for the convenience of
organizational representatives communicating directly with agents
outside the organization.
(2) Mail service provider (ESP) use case: mailboxes are provided to
customers for personal use of customers.
I have no problem with "p=reject" in the corporate use case because I
don't believe it causes significant burdens on users or unreliablity
of delivery. I believe that John has the same assessment, and it is a
weak consensus in the Mailman community AFAICT. Our issue is with
"p=reject" as used by large ESPs like Yahoo! and AOL, especially since
it seems to be associated with severe security problems, either at
those services or on the users' own machines. (Evidently this is a
consensus here as well, I'm just making Mailman's understanding clear.)
Does DMARC actually impose significant burdens on the "corporate use
case", contrary to my belief?
Of course there are other use cases of "businesses that rely on
email". I understand the "mailing list as user forum" case, and I
believe Mailman has already implemented a sufficiently broad set of
measures for business use in this use case. The tradeoffs aren't
pleasant, but that's a cost of doing business with Yahoo! and AOL
users. A business has the usual set of options (pay the costs, find
less costly customers, use alternative forum technology, etc). I
don't see a real problem here.
There's also the "on behalf of" content provision use case. Others
describe a good remedy in this thread, but I would like to point out
that such providers may publish "p=reject" to good effect, as an
instance of the "corporate use case".
But my knowledge of "business use" is quite limited. Are there other
"business activities relying on email" such that DMARC imposes
burdens? Are those burdens specific to "p=reject", or more general?
(If this is all well-known, please point me to a reference where I can
book up without disturbing the Councils of the Wise.)
> and also a slew of decision makers... and they're all trying to
> understand how they can fix things without going backwards.
IMO, they're wasting their time.
Email service *must* deteriorate in the presence of users who send
messages from "p=reject" domains, unless those domains are draconian
in enforcing direct transmission to final destinations that observe
"p=reject" (see Franck Martin's post later in the thread, and the
following subthread on "legitmate use of 'p=reject'" that follows).
Unfortunately, these domains are proposing that third parties adjust
to their (unilaterally imposed) policy, rather than modifying those
policies or restricting their users to safe email usage. But the "let
third parties adjust" solution is a pretty dismal option. There are
just too many MXes and MTAs and services that are DMARC-incompatible.
It's going to take years, maybe a decade, to modify both the software
and the installations.
We really can't expect help from Yahoo! and AOL. You talk about
money, well, Mailman doesn't care about money, it's a volunteer
project. The effort in development required is actually tiny, less
than 100 new/changed SLOC in Python for any given mitigation available
in Mailman (probably about 200 N/CSLOC for all of them together).
Maybe we'll take their money, but the effort to actually accept and
use the money in a basically pure volunteer organization may make it a
net zero.
The help we need is in explaining to our users that they cannot
maintain past configurations and allow posting from "p=reject" domains
at the same time. For many of our users, they get a MLM as a part of
a hosting package and the only solution they can implement themselves
is to refuse posts from those domains. Where's the money to
compensate those list operators for lost subscribers or the costs of
switching hosting services? Where's the money to encourage hosting
providers to upgrade their MLM installations? Where's the money to
compensate operators for the emotional and social damage done by
Yahoo! users who throw fits privately and publicly over lost posts?
Yahoo!'s offer of support for developers is a pure FUD PR stunt, as
far as GNU Mailman concerned.
The question is, to paraphrase John, how best to defend our users
(subscribers as well as list operators) from the unilateral behavior
of corporations desperate to mitigate their own problems. The rest of
us *will* go backwards. The question is how do we minimize the
retreat, and in which backward direction to go. Mailman, at least,
offers list operators (precisely, those who can install the most
recent versions) several options, so they can choose the one they
dislike least.
> Figuring out how to make email slightly less capable of harming
> people is a big deal.
Yahoo!'s use of "p=reject" reminds us that there is little we can do
to make email as such less harmful. The DMARC consortium can revise
their protocol, which I remind you was a purely private agreement at
the time of Yahoo!'s action, at any time. For example, they could
decide that the presence of strings resembling their mailboxes
anywhere in a From: field is subject to DMARC identity alignment.
That would cause the same set of problems for several of the less
unpalatable mitigations developed so far.
The only way to completely prevent future disruptions is to ostracize
"p=reject" domains. That's a technical assessment, not a
recommendation! Obviously, businesses and most discussion list
operators will find that "solution" completely unacceptable.
> > They know as much about e-mail as anyone, they've been tearing
> > their hair out trying to figure out how to deal with the problems
> > that the two mail providers have created, they've implemented and
> > tested all sorts of workarounds including several not on that web
> > page, and they agree that they all stink.
Slight correction: all are more or less aromatic in most Mailman use
cases, and for some use cases all stink like rotting fish.
One of the big problems for Mailman is that on many discussion lists
there is strong resistance to changing things like the Subject tag
(many people use it auto-folder filtering and the like) and the footer
(I believe for some businesses it's the best solution to requirements
to make it easy to unsubscribe which is more or less legally required
AFAIK). Users often resist From: corrupting modifications that do not
put the Author Domain in the display name, but this of course goes a
long way to defeating identifier alignment requirements and reenabling
phishing and spam (not necessarily via mailing lists, but also via
crooks imitating the header format in direct mail shots).
I accept that this may not be a "big" problem from the point of view
of this group, that's just Mailman's point of view.
> Tell the people you're communicating with to post their finding to
> either this list or the dmarc-discuss list. There is no reason why
> their findings should be frustrating -- others are meeting the
> challenge,
Nice pep talk, but please, save it for the board room. If you want to
present specific solutions, I'd love to hear about them (even if they
don't apply directly to mailing list management).
> and others still would likely benefit from their learnings.
Watch this space!
Footnotes:
[1] The ultimate authorities for GNU Mailman are Barry Warsaw
(project lead) and Mark Sapiro (release engineer and lead for the
stable version). I've been pretty good at channeling them in the
past, but I have no formal authority.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
