Search
Close this search box.

Authenticated SMTP relaying in Exchange 2013

Recently I designed and implemented a large Office 365 environment, part of it was a Hybrid Exchange 2013 server that should also serve as a central SMTP relay server to 365 and the rest of the world.
Since we didn’t want to control a huge list of authorized IP addresses and of course adding complete IP subnets is a bad idea, we chose to use SMTP authentication as our main solution for supporting Mail relaying.

Every office location was assigned a separate account only for this purpose and the credentials were handed out to the IT admin.
In the past I’ve done this quite often where we configured these accounts as authorized users in Exchange on the receive connector.

But when I configured Exchange 2013 I noticed that the server responded differently from what I expected.
When I added the permissions to the Default Frontend receive connector I could start the process of submitting a message, but once I submitted the data portion of the message I got a reply telling me the user was not authorized to send.
The exact error was: 550 5.7.1 Client does not have permissions to send as this sender


At first I slapped my head because I knew the frontend receive connector should only proxy towards the backend connectors, there all the processing should take place.
All the documentation and even my MCM training taught me that the frontend and backend connectors are tied to each other.
Meaning the “Default Frontend” receive connector would forward towards the “Default” receive connector, and the “Client Frontend” receive connector would forward to the “Client Proxy” receive connector.

So I added the correct permissions for the relay accounts to the “Default Frontend” receive connector, but this didn’t resolve the issue of receiving the 5.7.1 error message.
After quite some researching I found out that instead of what I knew of the Receive connectors, these connections were forwarded from the “Default Frontend” receive connector towards the “Client Proxy” receive connector.
Since I also noticed quite some posts on the World Wide Web, were people had the same assumptions and couldn’t find a solution I put this blog post together.

So here I outlined the steps required to configure authenticated SMTP relaying in Exchange 2013.

Let’s start with the Pre-requirements:

A mailbox enabled account, in my example “testkay”
A group which contains all relay accounts, in my example “Relay Accounts”

So first we will start off with adding the right permissions to the receive connectors.
To allow relaying at the “Default Frontend” receive connector we need the submit to server right assigned to our group “Relay Accounts” no other permissions are required yet.

The following PowerShell Command will set this right for our group.

Get - ReceiveConnector "default frontend*" |
    Add - ADPermission - User "contoso\relay accounts" - ExtendedRights ms -
        Exch - SMTP - Submit

For the “Client Proxy” receive connector we need to hand out the actual relay permissions, in our case we allowed the accounts to send from any address to any address but this might be different, see the list below for what each permission gives you.

  • ms-Exch-SMTP-Submit – allow to submit messages (required permission)
  • ms-Exch-SMTP-Accept-Any-Recipient – allow messages to be sent to email addresses unknown to the local server (known as relaying)
  • ms-Exch-SMTP-Accept-Any-Sender – allow sending as any email address that is unknown to the local organization
  • ms-Exch-SMTP-Accept-Authoritative-Domain-Sender – allow sending as any email address that is constructed with the authoritative domain (in our environment contoso.com)
  • ms-Exch-Accept-Headers-Routing – to keep all routing headers in the email, not required but can be nice for troubleshooting.

We picked the all of the above options and set the permissions with the next PowerShell command.

Get - ReceiveConnector "client proxy*" |
    Add - ADPermission - User "contoso\relay accounts" - ExtendedRights ms -
        Exch - SMTP - Submit,
    ms - Exch - SMTP - Accept - Any - Recipient,
    ms - Exch - SMTP - Accept - Any - Sender,
    ms - Exch - SMTP - Accept - Authoritative - Domain - Sender,
    ms - Exch - Accept - Headers - Routing

Ok so we configured the correct permissions now, and that should be enough to allow authenticated relaying of email messages, but reality is that not all devices on our network support NTLM authentication and our TLS encryption.
For our environment it was an acceptable risk to allow basic authentication, and especially for testing purposes this can be helpful as well.

To allow basic authentication we needed to alter the “default frontend” security settings from basic authentication only after offering TLS to allow basic authentication always.
This change can be made using the following PowerShell command

Get - ReceiveConnector "default frontend*" |
    Set - ReceiveConnector - AuthMechanism Tls,
    Integrated, BasicAuth, ExchangeServer

You can notice if basic authentication without TLS is enable when you start a Telnet session and execute the EHLO command, you will receive a response that should list the command “AUTH LOGIN” or “AUTH NTLM LOGIN”

To test from telnet if you can relay you need to encode your username and password to Base64, google will give you several translators to perform this.

Here is some additional info to troubleshoot the relaying process.
I use Telnet to test the connection, using the following lines to test the submission of an email with Basic authentication

telnet Exchange2013 25

    ehlo

        auth login

            dGVzdGtheUBjb250b3NvLmNvbQ ==

    zxvbvmbcnvbcmbxm =

    mail from : bla @contoso
                    .com

                        rcpt to : pietje.puk @hoi
                    .com

                                      data

                                          test

                    .

Since I needed to do some further troubleshooting I also set the ProtocolLoggingLevel for the “Default FrontEnd” receive Connector, “Intra Organizational Send Connectors”, “Default” and “Client Proxy” receive connectors to verbose logging. Use the following commands to set each of these.

Get - ReceiveConnector "Default FrontEnd*" |
    Set - ReceiveConnector –ProtocolLoggingLevel Verbose Get -
        FrontendTransportService |
    Set - FrontendTransportService -
        IntraOrgConnectorProtocolLoggingLevel verbose Get -
        ReceiveConnector "Default servername*" |
    Set - ReceiveConnector –ProtocolLoggingLevel Verbose Get -
        ReceiveConnector "Client Proxy*" |
    Set - ReceiveConnector –ProtocolLoggingLevel Verbose

The logs created by these connectors can be found at the following locations (these are the default locations):

  • For the FrontEnd Receive connectors: C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
  • For the Hub Transport Receive connectors (ie. Default” and “Client Proxy”): C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
  • For the Intra Organizational Send connectors: C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend

Posted on Saturday, May 3, 2014 12:56 AM | Back to top

This article is part of the GWB Archives. Original Author: KAY GERBEN SELLENRODE

Related Posts