Removing known MM-DEV subscribers, the CC list is getting long. David Andrews writes: > At 11:06 AM 11/5/2016, Mark Sapiro wrote: > > >However, I've just become aware that Microsoft has implemented another > >"feature". [...] one of the tests is the To: and > >From: addresses are the same. That means that any message To: a list > >with DMARC mitigations applied will be sent From: the list and any > >recipients using these Microsoft services will see that warning in the > >list message[1].
The fact is, every time we work around the actual semantics of "p=reject" (described in the block quote below), the spammers can hide behind our usage, I expect they will, and those tricks will be given spam (or worse, phish) points. Maybe it's time to default to rejecting posts from p=reject domains, with the explanatory message: Your domain publishes a "p=reject" DMARC policy, which is a statement to recipients that they allow you to send only authenticated direct mail. This is a mailing list which re-sends your mail after processing, and therefore you are not allowed to post according to your email provider's policy. Please repost from an address which allows you to post to full service mailing lists. Note: A few large providers claim to permit posting to mailing lists, but publish "p=reject" anyway. They privately acknowledge doing so to protect users from spammers and phishers who have stolen millions of address books and other private information of users from them. Of course this could be conditional on the presence of a header OR a footer OR Subject-munging in the list config. I'm semi-serious, but more likely is a "pass-through" tactic: ie, no headers, footers, or Subject-munging on posts from "p=reject" sites. The point is that spammers can omit those things, but they can't emulate the valid authentication on posts from DMARC sites. Unfortunately, some lists do need to add disclaimers and the like, so can't use the pass-through approach. The only tactics that actually work in the sense that spammers can't use them are (1) ARC (but that requires cooperation from receiving hosts that is unlikely[1]), (2) "pass-through" operation, and (3) preemptive rejection/discard. > This message has started appearing on messages on a list I subscribe > to at work, the state of MN, and they use hosted office 365 etc., and > the messages are almost always from legitimate senders, so going to > be a problem. My condolences. Footnotes: [1] It needs to be *all* receiving hosts. Some of them will undoubtedly be sufficiently lacking in email expertise that they delegate these decisions to Office 365 etc. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9