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