tl;dr I miswrote when I wrote that Hotmail is a problem sending
domain. It never was and currently is not. I was thinking of AOL
which was and is a problem.
The rest of this post explains why DMARC is a mostly good thing,
including a *very* high-level view of what it is good *for*.
Mark Sapiro writes:
> On 10/11/2017 03:31 AM, mailbox.org wrote:
> > Finally, I am understanding (hopefully correctly) that Yahoo and
> > Hotmail are the trouble makers.
I miswrote here. Hotmail doesn't publish a DMARC p=reject policy;
it's AOL that does. There are many other domains that do publish
p=reject but they also have internal policies against posting to
mailing lists. Yahoo! and AOL are the only posting addresses you're
likely to run into that cause problems.
> > And it especially makes trouble for the others (AOL and GMAIL)
> > Good reason to suggest at least my YAHOO and HOTMAIL users switch
> > to another provider. I found the free and secure provider
> > disroot that offers a large amount of space. Maybe I will
> > suggest that one.
I'm with Mark here. Unless you "own" your users in some way (most of
mine are my students, for example), it's way more trouble than it's
worth to ask people to change. They'll need to move archived mail,
for example. Also, AFAIK it's not possible to disable a Yahoo!
address unless you delete it. BUT IT MIGHT NOT STAY DELETED: Yahoo!
recycles unused addresses after a few months. It turns out that such
reused account names will have access to any resources that
authenticate using that Yahoo! address. So in practice users probably
should keep their Yahoo! accounts anyway, even if they don't use them.
DMARC itself is a good thing, and you should encourage users to use
email providers who participate in the protocol. Specifically, Gmail
has an excellent policy: if it believes that a message that violates a
sending provider's p=reject policy is a mailing list post, it will
"quarantine" the mail in the "spam" folder. This means that there are
no bounces for the *receiver* (which is why your subscribers were
getting disabled or unsubscribed), and the receiver can easily find
the mail at minor inconvenience (if they know to look, which is
something of a problem, of course). I don't know of other providers
with this policy but I expect it is in use at others and will probably
spread.
How is DMARC a good thing? DMARC does the following
(1) Provide a way for email providers to get reports about usage of
their mailboxes by third parties from recipients of such mail.
This helps them to learn about spam campaigns, especially
"spear-spamming" where the bad guys know your correspondents and send
you spam (or phishing) email that appears to be from an acquaintance.
The DMARC consortium claimed in late 2015 that over 80% of all email
was covered by DMARC reporting, so providers who have the skills to
take advantage of this data have extremely precise knowledge of usage.
(2) Provide a way to notify recipients that all mail from the
provider's domain is authenticated, and mail whose credentials do
not verify must be presumed to be malicious. This is the
"p=reject" policy that several of us have mentioned.
For (2) to make sense, the email provider should have a policy that
prohibits use of its mailboxes to post to mailing lists, and it must
not provide "on behalf of" services such as sending photographs or
newspaper articles using your address in From. This makes sense for
banks and other financial institutions, and use of DMARC "p=reject"
has pretty much eliminated phishing using mail with real bank
addresses in From.
This is how Yahoo! and AOL met trouble. Both leaked N x 100,000,000
contact lists to spammers, who used them for spear-spamming, much of
it phishing of various sorts. Turning on p=reject is said to have
reduced those spam campaigns from MILLIONS OF SPAMS PER MINUTE (!!) to
a trickle. The business argument for doing this despite collateral
damage to lists and various on-behalf-of businesses and their clients
is obvious, and given how dangerous spear-phishing is, there's even a
plausible ethical argument for it. (You can say "they shouldn't have
leaked", but they did -- now what?)
Note that there is a new protocol in the works called ARC which will
mitigate the problem for mailing lists as it's adopted. Unfortunately
it is no help for "on behalf of" services, but as a mailing list
developer and admin, I'll take it! Gmail and I think Yahoo! are
already using it experimentally, although I don't know how they
evaluate the "transitive trust" that is involved. (Ie, ARC involves
the mailing list testifying that they verified the credentials of the
poster.)
HTH
Steve
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
