Improve classification of "internal senders" in malware scanning
I like that I can enable "Notify administrator about undelivered messages from internal senders" in the malware policy.
I don't like that the malware detection engine has no idea if a sender is actually internal. It does simple domain-matching, which means that if someone is sending out malware and spoofing the sender address to pretend that it's from us, then I get notifications for days. Can't it at least do an SPF check?
We hope to have this one addressed within the next month or two.
Zac Jennings commented
The notifications aren't even as good as finding spoofed senders from our domains. It looks like they do string matching of almost any mailbox against any string in the email. This takes what could be a great quick-response tool and turns it into haystack where people have to find the needle.
So for instance, in the following example very similar to one pulled out of my logs, the string "joe.smith" matches the name of one of our mailboxes:
Subject: 12332739483714 Your Electricity Invoice 279$
Time received: 10/5/2016 5:07:25 PM
Message ID: <firstname.lastname@example.org>
Thorir Baldursson commented
Just had the same issue, we want to see notifications if legitimate "internal senders" are being blocked for malware. Not spoofs. Working as designed; well then it is poorly designed.
Please base the detection of internal senders on SPF rather than the senders from address so this notification actually does what it says.
Paul Garbett commented
We have the same issue, raised with MS Premier support who advised currently this is working as designed. The NDR backscatter setting doesn't stop this as the emails are not classed as backscatter as they are notifications which are configurable.
As we can't put our spoofing transport rule before malware in the order of scanning, the only other options MS advised were to implement DKIM and dmarc, but I've seen mixed results on forums from implementing this so am holding fire for the moment.
Drew Lanclos commented
I worked around it sort-of by changing the notification alert from "delete all" to "delete attachment and replace with text file", with a custom string inserted. Then I set up mail flow rules looking for that attachment with that string, and based on whether or not an SPF-Pass was included, I'd either expunge the email entirely or I'd redirect it to the quarantine-handling group.
The malware filter applies to all messages regardless of legitimate recipient addresses or not. If administrator notifications are turned on then a notification is delivered to the administrator even if the recipient of the deleted message does not exist. Would be useful to have the filter not generate notifications about messages if the recipient does not exist.