Mail Relay (Default Authentication and New Connector Thoughts)

Question

Before posting I reviewed the associated links to see if something stood out. It possibly did, but here is the issue/questions we have.

Environment:
Exchange 2016 CU19

Requirement:
Leverage authenticated mail relay for applications and devices that can use it.

Understanding:
By default Exchange allows for you to send Authenticated relay via port 587 provided you meet the following two criteria.

1. AD user with an Exchange mailbox
2. The "From" field matches the AD email address used

ERROR:
Send-MailMessage : Mailbox unavailable. The server response was: 5.7.60 SMTP; Client does not have permissions to send as this sender

We keep receiving the above error if we try port 465 or 2525 as well. To test we used Powershell plugging in the following commands.

1. Launch Powershell as UserA
2. $creds = Get-Credentials
3. Username: domain.com\UserA
4. Password: password
5. Send-MailMessage -From UserA@keyman .com -To UserB@keyman .com -Subject TEST -SmtpServer mail.domain.com -Port 587 -Credential $creds
6. Same result when trying ports 2525 and 465

Leveraging this method is ideal as we do not need to manage IP addresses to lock it down per connector, but we have yet to get it to work. When trying to test with the application itself we ran into No compatible authentication mechanisms found and An error occurred while attempting to establish an SSL or TLS connection. I believe the second error here is caused by not associating a certificate to the default connectors that use port 465, 587, and 2525. Did not feel comfortable modifying the defaults so we opted to test with creating a new connector all together (details below)

-------------------------------------------------------------------------------------------------------------------------------------------------

Since we were unable to get the above working lets do what we did for Anonymous mail relay and setup a new Authenticated relay we can lock down via IPs.

1. Created new connector called Authenticated
2. Security Mechanism:
   a. Transport Layer Security (TLS
   b. Basic Authentication
   c. Integrated Windows authentication
3. Permission groups:
   a. Exchange users
4. Scoped to specific IP over port 25

Same errors as above. Have been able to get a different error generated when trying to use the default method over TCP 587, 465, and 2525 related to certificated, but I did not want to add the certificate to the default connectors.

-------------------------------------------------------------------------------------------------------------------------------------------------

Question is can I leverage the default connectors to Authenticate clients? If so is the following command the only thing needed to get around the error we are seeing? Or is it possibly a better idea to use a new connector like in the example above to plugin the IPs needed etc? DHCP and VPN pools is why we were looking to default methods as maintaining the scoped IPs can become challenging as they are constantly changing.

Possible Fix:
Organization Wide:
Get-ReceiveConnector "Server\Authenticated" | Add-ADPermission -User "NT AUTHORITY\Authenticated Users" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

OR

Individual:
Get-ReceiveConnector "Server\Authenticated" | Add-ADPermission -User "UserA@keyman .com" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

What am I missing? Any assistance or guidance would be appreciated.

Thank you,

CWT

Answer 1

ZhengqiLou-MSFT,

Thank you for your reply/input. Here are the answers to your questions (hope they help).

1. We receive the 5.7.60 error when I or the Users launch Powershell under their Windows profile and run the Send-MailMessage commands from above. This was done mainly to try and test an Authenticated relay in PowerShell first to make sure the default Receive Connectors (RC) that leverage ports 587, 465, and 2525 worked as expected. Technically the PowerShell commands work great as long as you are an Exchange Organization Administrator. I tested and validated that as Org Admin - zero issues in PS. When I removed Org Admin the 5.7.60 error comes up 100% of the time.
2. The second test was done when we created the new Receive Connector (using the settings above) and chose port 25 (not default RCs configured for 587, 465,. & 2525) for the authenticated requests (provided we add the IP, Range, or Network). The results of this second test are the same as the first where we receive the 5.7.60 error.

Note: Both of the above tests were performed with PowerShell.

The main goal is to leverage a default connector that uses ports 465, 587, or 2525 OR the new Receive Connector configured with port 25 to allow an app/software to leverage authenticated mail relay for our Users. From within the app/software we plugged in the user credentials and did receive some additional errors (shown below).

Port 587 yielded the following error:
Source: Send SMTP Mail Message
Message: No compatible authentication mechanisms found
Exception Type: System.NotSupportedException

Thoughts: The Client Frontend SERVERNAME has TLS, Basic authentication (with offer basic only after starting TLS), and Integrated Windows. Is Enable domain security (mutual Auth TLS, Exchange Server authentication required?

Port 465 yielded the following error:
Message: An error occurred while attempting to establish an SSL or TLS connection
Several references to server is not trusted, local system missing root or intermediate cert, and expired/invalid cert

Thoughts:
The Exchange certificate we have for EWS services is trusted by the client (OWA validates that the certificate is good and that the client does trust it). This leaves the only other possibility as i see it meaning that the Exchange certificate is NOT associated to the Client Proxy SERVERNAME Receive Connector. To validate it is not I ran the following command.
Get-ReceiveConnector "SERVERNAME\Client Proxy SERVERNAME" | fl cert

My preference would be to leverage one of the default Receive Connectors if possible, but would rather not modify them. If modifying them whether that be adding another authentication radio box or certificate to the connector then its preferred to use the new connector created specifically for authenticated relay, but the new connector using port 25 is not working. When I telnet using the following command I get the error below when I ehlo.

Command:
telnet mail.domain.com 25

Error:
500 5.3.3 Unrecognized command 'XXXX'

Which is what I am trying to figure out now. My IP has been added to the scope of this connector and all radio boxes are checked for authentication except for Exchange Servers and External.

Thanks,

CWT

Answer 2

Hi @CWT ,

I got a few questions about your experiments:

1. How you met the error 5.7.60? With the cmdlets to send mails on EMS/PowerShell or when using telnet to test the relay. Basically this error is talking about a situation that you're using a different credential with the original message sender. Which means logon account ≠ sender account.
2. The second test you did, sending with a specific credential and a specific port, did it work? And what's the difference with test one.

If you want to allow authenticated SMTP clients, you should not add the permission ms-Exch-SMTP-Accept-Any-Sender, the clarification of this permission:
Allows SMTP clients or servers to bypass the sender address spoofing check that normally requires the sender's email address to be in an accepted domain that's configured for Exchange organization.

For your question, yes you could but it is a better idea to create a unique relay receive connector with some specific authentication methods and you could specify a range of IPs to satisfy the floating IP addresses.

Some articles may help: https://techgenix.com/mail-relay-exchange-server-2016/
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
About the permissions: Receive connector permissions

Best regards,
Lou

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 3

Good morning,

We have not been launching PowerShell via "Run as different user" (just opening it). To triple verify we did it two ways this am.

Verified IP was scoped for new authenticated relay (port 25)
Launched PS (as a different user)
$creds = Get-Credential
Provided AD creds DOMAIN\cwt
Send-MailMessage -From cwt@keyman .com -To cwt@keyman .com -Subject test -SmtpServer mail.domain.com -Port 25 -Credential $creds

Error:
Send-MailMessage : Mailbox unavailable. The server response was: 5.7.60 SMTP; Client does not have permissions to
send as this sender
At line:1 char:1

Performed the same test above by launching PS normally and the same error occurs
Performed the same test above by launching PS as an administrator and the same error occurs

The telnet test you reference is also receiving the same error from our previous post. I already checked with a guy who does all of our networking and nothing is running that could cause this.

Error
220 ********************************************************************************************
helo
500 5.3.3 Unrecognized command 'XXXX'

Thanks,

CWT

Answer 4

Hi @CWT ,

Good day!

For this error, I think it's because of the settings on Receive Connectors.
I did a test, if I disabled other Receive connectors and leave the one I created with the same settings as what you've made. I could meet this error when I wanna send from other user that's different with $creds.


The Relay receive connect is TLS, BA, Integrated Windows Auth enabled and only Exchange users enabled for permission groups. And the IP range is set to include the test server.
Other server will receive the error like this:

And for the Telnet part, I tested it with the steps of the document, and it could work without error.

This has a explanation in the document, after I added the anonymous users to the permission group of the Relay connector, it worked.

I have to apologize that I don't usually use telnet and I know only a bit of it, you can post the cmdlets you run on telnet here so we could better find the reason.

Best regards,
Lou