Right, we’re not really talking about actual users. We have a legacy Sendmail-based on-prem mail routing infrastructure that we need to retire/replace. It’s a pretty permissive anonymous relay for devices, services, apps, scripts etc. on our network to submit mail through. We’d like to shut down (or at least restrict) the anonymous relay and move the majority of uses to authenticated submission.

For operational support reasons it would have been convenient if the replacement solution could have been Exchange Server, but if the requirement to submit authenticated mail via on-prem servers is an on-prem mailbox, that’s a non-starter. We’re nervous about using Exchange Online directly due to Microsoft’s ongoing threats to deprecate basic auth for SMTP, and to be honest I’m not that keen on enabling basic SMTP auth for service accounts in Exchange Online – we don’t need these accounts to be able to submit from the Internet, so exposing that seems like an unnecessary risk.

I have already built a containerized Postfix deployment that will do exactly what we want, I just wanted to be sure that there wasn’t a way to achieve that same goal natively in Exchange. It seems that there isn’t, so thanks for helping to confirm.

We have a hybrid deployment with all our mailbox in Exchange Online and it doesn’t seem to be possible for any of user to send via our on-prem Ex2019 servers with authentication. We can authenticate on port 587 but then get the “550 5.7.60 SMTP; Client does not have permissions to send as this sender” error.

Do you know if it is possible to set it up so that Exchange Online mailbox users can send mail via authenticated SMTP using the on-prem 2019 servers?

Hi Edem,
You are correct, if you don’t put anything in front of your Exchange server then everybody can connect to your Exchange servers and do all kinds of things you don’t want them to do. Of course there will be legitimate mailservers connecting to your server, but this is most likely less than 5%. The other connections are malicious servers. If you want to create a honeypot and see what’s going on then it’s great fun to do. But in real world you should always locate some sort of device or cloud service in front of your Exchange server(s).

Hi Jaap, great articel! So to iterate over your comment. In a scenario where we have a security appliance, say Proofpoint in front of the Exchange server that filters malicious, unwanted messages before they are deliver to the Exchange server (and the appliance is the only Internet facing device that CAN actually connect to the Exchange server), then the anonymous access on the Default Frontend receive connector is not a real issue. However, if the Exchange online is not behind a security appliance, nor it is secured with a firewall (it is open to the whole Internet), then this is a problem, as virtually anyone could deliver all sorts of messages to recipients on that Exchange server, including, malicious mail, phishing, etc. correct ! Thanks !

Hi René,
You are correct, everybody on the internal network can connect to the Exchange server on port 25 and drop SMTP messages to be delivered to local mailboxes. That’s the default behaviour of the default Frontend Connector.
If memory serves me well this was not the case with Exchange 2007, where anynomous SMTP was only open on the Edge Transport Server, and not on the Receive Connector on the Hub Transport Server. But due to complaints, this was quickly changed.
But to be honest, I have never been at a client where we had to change this default behavior (I am not saying there aren’t any customer that want to, but I haven’t seen them). But if you want to do this, you must do something with the permissions, but be aware you are not killing SMTP communication between Exchange servers (although that’s not anonymous of course).
Thanks, Jaap

We have to custom connectors, Internal- and External Relay where we would like to have the traffic of official registered IPs (devices, applications and so on).
But with the behavior of the Default Frontend Connector nobody must register his IP for sending emails to internal mailboxes.
Thank you and best regrade,
René

This depends a bit on the complete picture. If you have an appliance for message hygiene, the MX record points there and everybody can drop messages there. The appliance forwards to the Default Frontend Connector and that’s it.
Externally, nobody can access the Exchange server directly, so nobody can misuse your connector.
But all internal users can still access the Exchange server, but that’s what Exchange is used for. All users must be able to contact the server, and yes, this also means that they can use port 25 to drop message for internal recipients. On the other hand, these same users can do this using Outlook.
The only thing you must be careful about is that the Exchange server is not directly accessible from the Internet.
Does this help?
Thanks, Jaap