Thank you Steve! Now I understand it is not all bad. Just the way that AOIL and YAHOO went about it (or something like that).
paul - - - - - - - - - - - - - - - - - - - - - - > On Oct 15, 2017, at 5:07, Stephen J. Turnbull > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > 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/paul%40tokyoprogressive.org ------------------------------------------------------ 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
