Event banner
Event details
102 Comments
- How would EXO handle a case where an unpatched/vulnerable on-premises server is sending mail to a non-Microsoft gateway first and then that gateway forwards on to EXO? I've worked with with many organizations that have things like Barracuda and mimecast like this. I suppose many (if not all) the smtp headers are preserved, but the EHLO handshake and such would not identify as an Exchange Server. Will EXO be able to report on this scenario?
- The enforcement system targets only the connecting server. So, if it's not an Exchange Server, Exchange Online will not report on the server.
- How will MS verify that mail is truly coming from an unpatched server? i mean, if its only looking at some SMTP headers or something the same could be spoofed (for good or bad) quite easily. My concern is that some on-premises server becomes compromised (even a fully patched server) and then purposely floods O365 with bogus messages that look like its from an unpatched server in order to cause all mail to be blocked. sort of like DDoS. Similarly, what about a bad actor that simply starts sending mail to a O365 entity with purposely created bad info? Could a bad actor force mail to be blocked to that entity in any way?
- We do use information in the SMTP headers, but we also correlate it for server ownership attribution. That's one of the reasons we are starting with a specific scope of Exchange 2007 servers that send email to Exchange Online using an inbound connector type of OnPremises. This allows us to identify the customer who runs the Exchange Server and notify them both via Message Center and through the new reports in EAC, well before any throttling or blocking takes place. Right now, the focus is on removing persistently vulnerable servers from the ecosystem. Should a bad actor compromise a server and try to spoof the headers to look like an unpatched server, that would not trigger throttling or blocking right away. It takes 30 days after the server is detected for throttling to kick in, which then increases over the next 30 days. An admin monitoring the system would notice queues building and SMTP errors in their logs. When blocking begins, senders start receiving NDRs which state why the message is being blocked. The real concern is the bad actor that compromises a server and then sends a few key messages that can cause mayhem. That's what we are trying to prevent.
- Sounds good to me. I like it, btw.
It often seems that features implemented in M365 eventually show up in the on-premises version. Will this behavior end up sneaking in to Ex2019 or Ex2025? If so, PLEASE don't sneak it in. Admins, architects, and implementers need to know up front if on-premises versions of Exchange will receive this same feature.
- Like I said, we don't just throttle or block right away. We notify you through Message Center posts. Then, we give you 30 days of reporting only in EAC. In the event of throttling or blocking, e admin and/or end user will be notified of the reason their email was rejected, e.g.: 450 4.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online throttled for 5 mins/hr. For more information see https://aka.ms/BlockUnsafeExchange. 550 5.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online blocked for 10 mins/hr. For more information see https://aka.ms/BlockUnsafeExchange. I get that not everyone has money to move, but that does not give them the right to put their recipients at risk by running a persistently vulnerable Exchange Server. This behavior is a system built into Exchange Online. The transport enforcement system will not be put into Exchange Server, but it will be used for all versions of Exchange Server, including Exchange Server 2016, Exchange Server 2019, and the next version of Exchange Server that ships in 2025. That said, we are looking into ways we can leverage things like the Outlook infobar and the Exchange admin center in the next version of Exchange Server to notify an admin/user that their Exchange Server is out of date. For the record, we don't "sneak things" into our product. Our customers require transparency, and we are very open about the code changes we make in Exchange.
Is there in future any intelligent solution to use ip less DAG without any third party load balancer on premise? because DNS round robin is not a solution for fail over. Specially for SMTP relays it is not acceptable. Or is the answer in that case clear, use IP based DAG?
- If I'm not mistaken, Microsoft already provides a software load balancer service that you can install on a windows server. https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-load-balancing
- Keen to hear some updates & timelines on your next version of on-premise Exchange server which moves to 'Modern Lifecycle Policy'
- We've said in our Roadmap announcement (https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-roadmap-update/ba-p/3421389) that the next version of Exchange Server will be released in H2 of 2025. Our plans have not changed. As we also said then, we will provide more details on naming, features, requirements, and pricing in the first half of 2024.
- Thanks, yes already seen this, hence the ref to MLP, was keen to know if you had an update, as that article was dated Jun 22, cheers
- Will there be information provided for non-Exchange gateways? Will EXO also block non-Microsoft transports like barracuda, mimecast, postini, etc. that do mail hygiene, DLP, or other work? Any anticipated side effects for such things, possibly if any of these try to emulate an Exchange server? What about NLBs? What impact or side effects could those experience as a result?
- Right now we are focused on specific versions of Exchange Server in specific configurations. We are always looking for ways to improve the security of our cloud and to help our on-premises customers stay protected. We are initially focusing on email servers we can readily identify as being persistently vulnerable, but we will block all potentially malicious mail flow that we can.
- What kind of timeframe is there for rolling this out to include blocking Exchange Server 2013 (hitting EOL on April 11th, 2023; a month before the AMA)?
- How quickly will out-of-date but patchable versions be added (Exchange Server 2016, Exchange Server 2019)? You say 90 days starting from the point of detection - will that have any exceptions/exemptions? (Say, if an earlier CU gets detected as a new Exchange Server; or a massive security issue is identified.)
- Will there be any kind of notification system added to future Exchange updates?
Perhaps pushed out using the Exchange Emergency Mitigation Service; when newer CUs and SUs become available.
Then admins hitting one of several interfaces:
-ECP (Exchange Control Panel) through the Alerts space
-Exchange Management Shell (Exchange PowerShell) on session launch/connection, like the host details.
To get an additional method of notification that their servers are out of date and need patching/maintenance, with a link to the Exchange Blog and/or Docs?
1. Exchange 2007 starts in a few weeks with reporting, then moves to throttling 30 days later, and then blocking 30 days after that.
2. Exchange 2016 and Exchange 2019 customers in scope will receive their Message Center post on Jan 24th. As remediation for these servers is different from Exchange 2013 and earlier (which cannot be patched), when throttling and blocking begin depends on server remediation. It's possible an admin could remediate their server(s) during the reporting only period and never experience throttling or blocking. What our "minimum compliant build" for servers that can be patched will vary due to the nature of the updates, things we detect, learn about, etc., things in the wild, etc...basically lots of things will be considered here.
3. We are looking at creating a new experience in the Exchange Server EAC that can provide visibility for admins about servers in their environment that need their attention. We have also started rolling out a new Software Update dashboard in the Microsoft 365 admin center for hybrid customers that shows the detected Exchange Servers in their environment, including which ones need updates., etc. This is in addition to the blog post, Health Checker, the new reporting coming with the transport enforcement system, the SMTP logs, and any NDRs created as a result of blocking.
- What kind of timeframe is there for rolling this out to include blocking Exchange Server 2013 (hitting EOL on April 11th, 2023; a month before the AMA)?
- Is it still expected for their to be an Exchange 2025 on-prem release?
- Is it safe to say this AMA won't be covering the new policy that prevents new 365 tenants from creating inbound on-prem connectors? This change is really creating issues for companies that rely on that integrated mailflow for adding signatures, enforcing email security (Tessian, Abnormal, Egress, Trustifi, Avanan, etc). We've been trying to get our connectors turned on for nearly a month. This is not acceptable for a paying customer.
- You are correct; that's not the subject of this AMA. But please contact me offline at schnoll@microsoft.com and I will do my best to help get this resolved for you.
