Automatic replies from an Out of Office assistant or from an configured rule to any "noreply" emails should can be blocked.

There should be a possibility in the Email Gateway Settings or Policies to configure variables of possible Emails like "no-reply", "noreply", "do-not-reply", etc. that if the recipient replies to such an email, this automatically gets blocked on the "outgoing" path.

For auditing, this block should be listed in the "Logs & Reports - Message" List, that the admin sees "From User XY an Email to "noreply@XYZ.TLD" got blocked and deleted.

The sender should not get any information that this happen because if the reply was done by the OoO assistant or a rule, this would "spam" the mailbox of the user.

Ill put this feature against Email Gateway as that is where is sorely needed but this feature should be for all Sophos Central components.

Part of the power of Sophos Central should be centrally across all security product reacting to a security event and taking action to resolve it.

Currently there is no "Block URL" feature in Email Gateway - There is an URL Allow list but no block feature. This is sorely needed.
One of the main benefits of using Time of Click is to immediately react to issues not only on future emails but existing emails in users mailboxes. Yet there is a reliance on Sophos Labs to have information on Malicious URLs which often they do not...

If a URL is indicated in a phishing email that slipped through, a company admin, using a URL Blocklist, can IMMEDIATELY react to this and block the URL for all existing emails that have that URL and emails received in the future. The company is immediately protected from a Email persepective.

Sophos can use this list as a sample submission of sorts also to validate and potentially block that URL for all Sophos customers.

--

Additionally there should be a means of blocking IOCs - Domains, URLs, IPs, Hashs - across all products in Sophos Central. -- Global Block List

URL on the Company Global Blocklist would mean --

• Block URL in Web Control for Endpoints and Servers and Mobile (this is possible using the web tag system BUT ridiculously convoluted)


• Block URL in connected XG Firewall


• Block URL at the device level for Sophos Wireless users.


• Block URL in Email Gateway for ToC emails also


• Quarantine email that is specified in the new Search and Destroy feature.

That is ridiculously powerful and massive missing potential from Sophos Central.

I just learned through a support case (where a spoofed malicious email was allowed through, bypassing DMARC checks despite having an inbound DMARC verification rule) that the only time an inbound DMARC verification rule is even TRIGGERED is when DMARC actually "fails" (because the domain's various records for SPF and DKIM don't have the proper servers allowed)..

Unfortunately, I also learned that, when the sending domain does not actually HAVE a DMARC record to check, such a "failure" is technically not possible... because 'DMARC record does not exist' DOES NOT EQUAL a "fail", and there is no "does not exist" scenario that is currently allowed for regardless of the action ("honour txt record", "quarantine", or "reject") chosen for the rule.

What this means is that a spammer has the ability to send all the spoofed email they want from (and potentially to!) your OWN domain without your inbound DMARC rule doing anything to stop it.

This is NOT due to a misconfiguration of YOUR OWN records for DMARC. It is a failure of the sending domain's LACK of a DMARC (or SPF/DKIM records, as appropriate). (Furthermore, and similarly, though, I was also educated by Support that the SAME THING would be true if the SPF record didn't exist, or if there were NO DKIM records either (the message would just skip DMARC checks and be allowed through).

Currently we are technically using the email appliances - however, my understanding is that this is how the feature works in Sophos Central as well, so, I'm submitting this now in hopes it will be fixed, in advance of our possible transition to that service from the appliances.

The solution I'm suggesting is to have an option to treat a "non exist" as a "failure" so that DMARC verification can actually be triggered. Maybe there can just be options to override the handling of when the DMARC, SPF, or DKIM records do not exist... we could just pick 'quarantine'?

There should be a option to override SPF Softfails for specific sender domains so that they are treated by Sophos Central Email as a hard fail instead.

An example of this, is it's quite common for receive spam emails from @gmail.com addresses from IP addresses not on Gmail's SPF record. Due to Gmail using softfail instead of hardfail in SPF, the emails are not marked as phishing/spoofed or quaratined by Sophos.

A similar feature should be available for DMARC on a per sender domain basis (instead of how it is currently, where it's applied to all senders). You currently have this as a global option. Gmail is another example of where this would be effective, as they set their fail action to 'none' instead of 'quarantine' or 'reject'