‘Last Exchange Server’ Scenario Feedback

while the already mentioned issues with SMTP relay (we have WinServer default SMTP (deprectated) in place), and software/hardware not capable to use TLS(1.2) etc apply for us as well, we use mailboxes on-prem for our Admin-Accounts.

While yes, we know an Admin should not have a mailbox etc... We were unable to figure out a 'good' solution. Any solution has its drawbacks of any sort and you go in circles and won't find an exit.

So we are using a regular non-permission account for the 'B*S* stuff' and 'elevated accounts' for the 'Admin stuff'. Both on-prem AD and synced up to EntraID. The Admin accounts are also used for the admin stuff in M365 of all sorts. with that - basically everything in M365/Azure sends a mail... but to your admin account. Due to the sync, you can not tell your admin account to use the same email address as your regular account as well as not set your admin mail address as alias to your regular account. you get a conflict. Having shared mailboxes (or even licenced ones) in EXO for admins - not good practice and i think in the long run you get in trouble. Having admin accounts for on-prem and online stuff separated... extremely clunky. Having the admin account being a mail-user -> sync conflict again.

So our solution here is to use on-prem mailboxes for the admins and let the mails forward to the regular account. We found this the least intrusive and best compromise.

My wish to MS: let us somehow define the same emailaddress for the admin accounts (maybe an attribute in AD on the admin account for a fallback-mailaddress or something like that, that then is used in the M365/Azure world to send mails to, so they would appear in the regular mailbox).

Other than that - any idea to solve that kind of 'hen-egg problem' is welcome. I know, if you have a standlone online admin account, you simply fill the mailfield with your mail address and it works without running into a conflict (at least it was in the past). why - no idea.

As already mentioned, SMTP Gateway to Exchange Online is one issue, especially in smaller environments. Not every SMTP client (printers etc.) is ready for TLS1.2, so these customers need not to replace that systems as soon they are uninstalling the last exchange server. (I know you should replace them, but customers do not recognize and some don't want to hear it).  Another point is, in systems with only one admin, nobody understands why and how you should manage AD attributes. There are no PowerShell skills available and these admins hardly can handle the Exchange GUI / Exchange Online GUI. A lot of things can be done inside Exchange Online, so why not changing or adding SMTP Addresses.  I'm consultant for this, I know how to manage that but people who need to administer many different systems will probably not understand these (little) complex symbiosis of local AD and Exchange Online.  Thanks for your work and maybe there will be a smooth way to make this great E-Mail system a little handsome. 

Thanks for this great blog and your work Exchange Team. 

PeterForster You can make an "OnPremises" connector and change the configuration for how it identifies the traffic.

New-InboundConnector `
-CloudServicesMailEnabled $true`
-ConnectorType OnPremises`
-Enabled $true`
-Name "Inbound from Postfix On-Premises"`
-RequireTls $true`
-RestrictDomainsToCertificate $true`
-SenderDomains *.domain.com`
-TlsSenderCertificateName *.domain.com`
-TreatMessagesAsInternal $true

Something like that should do the trick.  It requires setting the certificate and restricting only traffic with the matching certificate and setting it for OnPremises and as CloudServicesMailEnabled.

I haven't run it in a while, but it worked the last time I checked it.

Back before cross-tenant migrations were possible, I used this same sort of thing to rewrite email addresses by sending traffic to Postfix, letting it rewrite, and then send it along to the appropriate tenant.

DustinDortch That is interesting that messages routed the way you mentioned will have the Auth-As Header as "Internal" as mentioned here: Demystifying and troubleshooting hybrid mail flow: when is a message internal? 

Fully unclear how this should work as the Header Firewall from Exchange comes here into place. This is not related to a TLS session for SMTP.

PeterForster That is so often the case.  In fact, the customer I first set this up for basically took away all of the options... all of them.  They were previous on Lotus Notes/Domino and we migrated them to Exchange Online.  The Domino servers were going to be kept around until all of the custom apps they ran were mitigated.  When that happened, they came back to us to ask for assistance with mail relay.  I suggested installing six (6) Exchange server (their applications send a lot of messages, many business critical and customer-facing).  They said that it was fine but insisted on using "Split Permissions"; I work with a lot of folks that have a ton of experience with Exchange and we even spoke with Microsoft... the consensus was, "run for the hills."  So, I proposed Linux with Postfix and they were reluctant.  As far as "enterprise grade" solutions, the options were really, Exchange, Linux with Postfix, or some appliances; they didn't like any of them, but with my Ansible role, I made it to where they could manage it all with a playbook.

In terms of marking it as internal, we rely on certificates to identify that valid traffic.  So, the connector can safely be marked as internal because only the servers with the valid certificates will match to that connector.

DustinDortch thanks for your idea. We thought about this too, but: Exchange did this all out of the box. Not every customer is Linux ready and having a very important function (for many customers SMTP relay is one the business critial functions) on a system they cannot manage is not an option for them.

We have customers still running two Exchange servers based on the relay requirement.

But how did you set the correct headers there? The option to mark the inbound connector as "internal" is not one we would like to use as regardless what system will later send with that public IP is marked as internal. This is the security issue we see here.

I think the most significant feature that is lost is Email Address Policies.  This is crucial for larger environments to ensure that addresses are set according to a standard and appropriately remediated when a conflict arises.  If there is a service that could be run, or a well-designed PowerShell script that accounts for the same considerations (perhaps even relies on the actual Email Address Policy data stored in Active Directory for its rules), that would be awesome.  Maybe that has been addressed in some other way that I have missed, though.

PeterForster You can stand up another platform for mail relay and have it treated as "internal" mail, still.  It takes some effort, but I have done this for customers with Postfix (I even built an Ansible role to make it easy).  Use certificates and authenticate the traffic that way.

Simply put, the SMTP relay question remains unresolved. I am aware that we can directly route apps and devices to Exchange Online, but this involves a significant effort. Moreover, many devices lack internet access. The direct relay on port 587 necessitates open firewall ports, and ideally, a static IP address should be configured on the outbound NAT.

While this approach might work for fewer than 10 devices, many of our customers have a much larger number of devices. Consequently, they often choose to keep the last Exchange server operational. Unfortunately, the current options for correctly authenticating emails as ‘Internal’ within the Auth-Headers pose too many security risks.

Thanks for the feedback form: Done!