Re: [Mailman-Developers] MM3 DMARC mitigations
On 10/31/2016 03:08 PM, Eric Searcy wrote:
Adding Mailman-Developers to the recipients.
As I noted in the original thread, this would not be difficult to add, but it won't be in the initial implementation of DMARC mitigations for MM 3 (see <https://gitlab.com/mailman/mailman/merge_requests/215> for more on that).
However, I've just become aware that Microsoft has implemented another "feature". So far, the info I have is this is limited to their "hosted mail services", but it may well spread. What they are doing is looking at incoming mail for signs of spoofing/phishing and if found, they place a prominent notice
This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>
in the message. The issue for us is that 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].
How long will it be before this spreads to all Microsoft email services <sigh>?
[1] I first became aware of this via the thread at <http://lists.mailscanner.info/pipermail/mailscanner/2016-November/104001.htm...>. There it was the poster who saw the warning in his copy of the list message and mistakenly thought it was a rejection of his post to the list. The reply at <http://lists.mailscanner.info/pipermail/mailscanner/2016-November/104017.htm...> has interesting info.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
At 11:06 AM 11/5/2016, Mark Sapiro wrote:
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.
Dave
Removing known MM-DEV subscribers, the CC list is getting long.
David Andrews writes:
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.
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.
On Nov 06, 2016, at 05:39 PM, Stephen J. Turnbull wrote:
With some verbiage massaging perhaps, I am supportive of a "hammer" option such as this. Maybe we can't enable it by default, but I don't think it's unreasonable for site/list admins to be able to be more proactive in their rejection of such messages. It will probably make no difference, but if we can inform users as to the real culprits in this mess, they can either complain to their ISPs or vote with their feet and find a new provider. That won't happen if they continue to blame the list software or site.
(If we're serious about this, we should likely have a locked down wiki page with more detail, linked to from the default p=reject rejection message.)
Cheers, -Barry
On 11/07/2016 06:05 PM, Barry Warsaw wrote:
It's in MM 2.1 and it's in my dmarc branch MR <https://gitlab.com/mailman/mailman/merge_requests/215>. The list has dmarc_moderation_action with possible values none, munge_from, wrap_message, reject or discard.
The default reason is not what Steve proposes. The default is in mailman/rules/dmarc.py per
reason = (mlist.dmarc_moderation_notice or
_('You are not allowed to post to this mailing '
'list From: a domain which publishes a DMARC '
'policy of reject or quarantine, and your message'
' has been automatically rejected. If you think '
'that your messages are being rejected in error, '
'contact the mailing list owner at ${listowner}.'))
msgdata['moderation_reasons'] = [wrap(reason)]As it is, the list can supply its own reason. The default could of course be changed or made a configuration setting.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Barry Warsaw writes:
Well, I'll be happy to create the patch just to make the statement, but honestly, I doubt we can convince anybody who actually believes that list software created this mess to believe otherwise. Unlike telephone numbers, email addresses are not portable, so the incentives against moving (which weaken the effectiveness of complaints) are really strong, too.
Agreed. Maybe I'll sprint on this at PyConCA. :-)
The sad thing is the DMARC protocol is actually really well-designed for two purposes: allowing mailbox providers to get information about mal-use of their domain names, and allowing organizations that conduct business transactions via direct email to prevent spoofing. It doesn't address the problem of spoofed indirect mail (like mailing list posts) because that's just a really hard problem because there's no known good way to inform users about the trustworthiness of individual messages. (I'd like to blame it on the popular MUAs, but I'm afraid the problem is deeper than that.)
Steve
At 11:06 AM 11/5/2016, Mark Sapiro wrote:
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.
Dave
Removing known MM-DEV subscribers, the CC list is getting long.
David Andrews writes:
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.
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.
On Nov 06, 2016, at 05:39 PM, Stephen J. Turnbull wrote:
With some verbiage massaging perhaps, I am supportive of a "hammer" option such as this. Maybe we can't enable it by default, but I don't think it's unreasonable for site/list admins to be able to be more proactive in their rejection of such messages. It will probably make no difference, but if we can inform users as to the real culprits in this mess, they can either complain to their ISPs or vote with their feet and find a new provider. That won't happen if they continue to blame the list software or site.
(If we're serious about this, we should likely have a locked down wiki page with more detail, linked to from the default p=reject rejection message.)
Cheers, -Barry
On 11/07/2016 06:05 PM, Barry Warsaw wrote:
It's in MM 2.1 and it's in my dmarc branch MR <https://gitlab.com/mailman/mailman/merge_requests/215>. The list has dmarc_moderation_action with possible values none, munge_from, wrap_message, reject or discard.
The default reason is not what Steve proposes. The default is in mailman/rules/dmarc.py per
reason = (mlist.dmarc_moderation_notice or
_('You are not allowed to post to this mailing '
'list From: a domain which publishes a DMARC '
'policy of reject or quarantine, and your message'
' has been automatically rejected. If you think '
'that your messages are being rejected in error, '
'contact the mailing list owner at ${listowner}.'))
msgdata['moderation_reasons'] = [wrap(reason)]As it is, the list can supply its own reason. The default could of course be changed or made a configuration setting.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Barry Warsaw writes:
Well, I'll be happy to create the patch just to make the statement, but honestly, I doubt we can convince anybody who actually believes that list software created this mess to believe otherwise. Unlike telephone numbers, email addresses are not portable, so the incentives against moving (which weaken the effectiveness of complaints) are really strong, too.
Agreed. Maybe I'll sprint on this at PyConCA. :-)
The sad thing is the DMARC protocol is actually really well-designed for two purposes: allowing mailbox providers to get information about mal-use of their domain names, and allowing organizations that conduct business transactions via direct email to prevent spoofing. It doesn't address the problem of spoofed indirect mail (like mailing list posts) because that's just a really hard problem because there's no known good way to inform users about the trustworthiness of individual messages. (I'd like to blame it on the popular MUAs, but I'm afraid the problem is deeper than that.)
Steve
participants (4)
-
Barry Warsaw -
David Andrews -
Mark Sapiro -
Stephen J. Turnbull