In Exchange 2010, we had 4 receive connectors to secure our SMTP traffic.
- Internet, allowed anonymous access, and in the remote IP ranges the IP's of MessageLabs where configured (so was only accessible from our smarthosts on the internet).
- AllowRelay, allowed anonymous relay access to the IP's configured in the Remote IP ranges. Those servers are allowed to relay, however they have to use an Custom SMTP domain which was not linked to the company SMTP domains to which Exchange is authoritative.
- NoRelay, Allowed anonymous SMTP access to the IP's configured in the Remote IP ranges. Those servers are allowed to send SMTP messages, but are not allowed to relay.
- Authenticated access, allowed SMTP access to authenticated users. In which the used sender's address was verified against the credentials provided. If the provided credentials had send-as permissions on teh provided from address, than the mail would be accepted.
We have a company policy that states that OUR Exchange SMTP domains may only be used when the e-mail originates within the Exchange organisation, or is accepted by authenticated access.
Everything worked as designed, however this does not seem the case in Exchange 2016.
We have configured similar receive front-end connectors in Exchange2016 to provide the same service. We have provided each receive connector with its dedicated IP, as we saw that SMTP traffic somethimes ended up on the wrong receieve connector. Which wasn't the case in Exchange 2010. Since we have defined each Front-end receive connector to it's dedicated IP, we see the traffic ariving at the correct receive connector. However authentication is somethimes failing, somethimes we see that authetication occured from a certain system and that the e-mail is accepted, While somethimes that same system is failing altough credentials and senders address are provided and correct and equal as before. When we test from various systems using powershell, we often see the same error:
Send-MailMessage : The SMTP server requires a secure connection or the client was not authenticated. The server respons
e was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM
Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.