This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problems with new M365 Mailflow

I have created a Support ticket for this but thought I would post here also.

I've been testing M365 Mailflow in Sophos Email and I have the following problems:

  1. Sophos in mailflow mode is not detecting Gtube test spam
    Is this a known issue? I am sending the string and it is happily sending through to my M365 mailbox. going straight through Sophos..
    How can I test the functionality of M365 Mailflow?

  2. IP address of sender is indicating the M365 IP address

    With M365 mailflow the delivery "IP Address" indicated in the "Message History" is the M365 IP address - not the IP address of the original sender?
    Even worse is an admin can click on "add to blocklist" which presumably will start blocking that M365 IP address which could be catastrophic?
    I can see from the headers that Sophos records the Original sender in the header:
    This should be displayed as the "IP address" on the main Message History screen

  3. Smart banners are showing trusted when address is not on allow list

    The Smart banner conditions for showing as trusted are:
    "email sender is in the allowed list and passed DMARC"
    I've tested newly setup accounts from gmail etc .. the addresses are not on the global or any user allow lists in my sub-estate.
    The emails do pass DMARC but both conditions must be TRUE .. unless that has changed?
    I suspect this is because Sophos Email is naturally trusting the M365 IP addresses in the M365 Mailflow mode

  4. Eicar is sort of working BUT M365 picks up first

    The Eicar test virus is picked up by M365 first and quarantined there - after releasing it is picked up by Sophos Email.
    Makes sense, and not necessarily a problem, but is that explained to customers in a KB anywhere?
    Many viruses under default M365 settings will be centrally quarantined and Sophos Email will be unaware -- having this not communicated to Sophos Email may mean problems troubleshooting email delivery.

This thread was automatically locked due to age.
  • I just sent the test email from Gtube through MFR and Sophos quarantined it as spam. Be interested in know what is different in yours vs my configuration?

  • The way I’m sending gtube means I can’t send the full mime test email available on gtube site but I can simply have the gtube string in the body of the email. Sophos should detect that. 

    I’ve been doing some other tests with recent (one day old ish)  phishtank URLs — interesting here in that M365 was central quarantining the emails as spam — Sophos didn’t get a look in.  So this has the same issues as the eicar test.

  • Hello Alex,

    Thank you for your inputs and feedback.

    1 This is not expected and we need to investigate. As you mentioned, you have taken it up with Sophos Support and I believe we will have the resolution soon.

    2 This is a known issue and a fix is underway

    3 This is not expected and we need to investigate. As you mentioned, you have taken it up with Sophos Support and I believe we will have the resolution soon.

    4 This is expected. Emails containing high confidence malware and phish are stopped at M365 before they make it to Sophos Mailflow. We are looking at options of making such emails easy to manage.

  • Thanks good answers and faster than Sophos Support 8) - still no response on support ticket ..

  • Ok I think I have resolved the gtube issue  - with fresh eyes,

    Still something that Sophos/Customers will need to be aware of potentially.

    The domain I brought over to mailflow was a secondary alias domain not the root domain that my users mailboxes were listed as. 

    After I removed the alias and created a specific mailbox/user for the domain that was running mailflow - Gtube spam protection AND the issue with Smart Banners appear to be resolved.

    This sounds like a license issue - Sophos email being the only Sophos central product that disables protection on non-licenced users - I have plenty of licenses but possibly how mailflow looks to ensure to apply protection on specifically the domain or a subset of users in a domain and how that interacts with the mailbox level licensing.

    This might be a common way that Mailflow may be deployed though. Where a secondary domain is targeted at least initially where the other primary domains are not .. will this cause the same interactions in those cases.

    Ill do some more testing but the problems I have appear resolved.

    Good to know that IP address is a known issue and a fix is underway - thanks for your answers