In 2012, Paul Cunningham wrote about this topic based on the state of the art at the time (Exchange 2013). Time marches on, and new versions of Exchange Server mean that it’s appropriate to review the current position up to and including Exchange 2019.

Why discuss Exchange 2019 Transport now, since it seems like everybody is moving to the cloud? Well, many of the organizations that move to the cloud run an Exchange hybrid organization and need at least one Exchange 2019 server on-premises for management purposes. This server (or these servers) is often used for SMTP relay purposes. I see a lot of customers struggling with SMTP and SMTP relay, so it’s time to update our knowledge about SMTP transport services.

SMTP Transport Services in Exchange 2019

Transport services in Exchange have not changed dramatically since Exchange 2013. The most visible change is that Microsoft combined two server roles used in Exchange 2013 (Client Access server role and Mailbox server role) into one server role (Mailbox server role) in Exchange 2016 and Exchange 2019. This means that all transport components are now combined in one server role.

The complete set of transport services in Exchange is called the transport pipeline. When identifying the different components in the transport pipeline, you see the components that come from the old Client Access server role and from the old Mailbox server role. Microsoft created a nice overview of the transport pipeline of an Exchange 2019 server, and this is shown in Figure 1:

Exchange 2019 Mail Flow and Transport Services
Figure 1: transport pipeline of an Exchange 2019 server

At the top of the pipeline, you see the front-end transport services. This is where external SMTP messages are sent and received. When a message is received from an external sender on port 25, the server determines, based on a directory lookup, if the recipient is an internal recipient or an external recipient. If the recipient is internal, the message is sent to the transport service. If the recipient is on the same server, the frontend transport service sends the message to the transport server on this server. If the recipient is on a different server, the frontend transport service sends the message directly to the transport service on that server. The transport service listens on port 2525 and places the incoming message in the submission queue. When the categorizer determines the mailbox of the recipient, the message is put on the delivery queue before transport routes it to another mailbox server or to the Mailbox transport service. The names look similar, but it’s a different service. The Mailbox transport service is the service that communicates with the mailbox database to deliver the message to a mailbox or to pick up an outgoing message from a mailbox.

The mailbox transport service is the only service that uses RPC communication. All other communication between services uses SMTP.

For compliance reasons, all messages are processed by the transport service, even when a recipient’s mailbox is on the same server. When a user sends a message to themselves, and we check the message details using the Microsoft message analyzer, we can clearly see this happening (Figure 2):

Exchange 2019 Mail Flow and Transport Services
Figure 2: Header information from a message that a user sends to himself

Receive Connectors in Exchange 2019

As you can see in Figure 1, an Exchange server can receive messages in multiple ways through receive connectors. Details of receive connectors are retrieved using the Get-ReceiveConnector cmdlet on an Exchange server:

Get-ReceiveConnector -server AzEXCH01

Identity                                  Bindings                  Enabled
--------                                  --------                  -------
AzExch01\Default AZEXCH01                 {0.0.0.0:2525, [::]:2525} True
AzExch01\Client Proxy AZEXCH01            {[::]:465, 0.0.0.0:465}   True
AzExch01\Default Frontend AZEXCH01        {[::]:25, 0.0.0.0:25}     True
AzExch01\Outbound Proxy Frontend AZEXCH01 {[::]:717, 0.0.0.0:717}   True
AzExch01\Client Frontend AZEXCH01         {[::]:587, 0.0.0.0:587}   True

By default, every Exchange server has five receive connectors. Every receive connector listens on the standard IP address, but on different ports. I’ll discuss them here:

  • The ‘Default Frontend <servername>’ receive connector uses the frontend transport service on port 25. This port is what all mail servers, applications, or devices connect to when they want to send mail to recipients in the organization using SMTP. Inbound connections are anonymous connections, and you can check them in the Exchange Admin Center. Figure 3 shows the security settings on the ‘default frontend <servername>’ of my Exchange 2019 server:
Exchange 2019 Mail Flow and Transport Services
Figure 3: Anonymous users are checked by default on the ‘Default Frontend <server>’ receive connector

A connection comes in anonymously and can deliver mail to recipients in the organization, but this mail cannot be relayed to recipients outside the organization, so there’s no need to worry about having an open relay in this situation.

This situation can easily be checked. When I configure my Synology NAS appliance and try to send out notification messages to a Gmail recipient, for example, it fails with the following error:

“Test mail failed to send. Please check your settings and try again. 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain” as shown in Figure 4 :

Exchange 2019 Mail Flow and Transport Services
Figure 4: SMTP Relay failed to send messages outside of the organization
  • The ‘Default <servername>’ receive connector is used by the transport service (as part of the mailbox server). This connector is typically only used by the frontend transport service to connect to the transport service.
  • The ‘Client Frontend <servername>’ receive connector on the frontend transport service is used for authenticated SMTP on port 587. When a sending host connects to this receive connector, it must authenticate before proceeding. The good news is that once authenticated, it can send messages to internal and external recipients.

The bad news is that for authentication, the account must have a mailbox. If the account does not have a mailbox, it will result in the following error message:

“Test mail failed to send. Please check your settings and try again. 550 5.7.60 SMTP; Client does not have permissions to send as this sender” as shown in Figure 5:

Exchange 2019 Mail Flow and Transport Services
Figure 5: SMTP Submission account has no mailbox, and authentication fails.
  • The ‘Client Proxy <servername>’ receive connector on the transport service is used by the ‘Client Frontend <servername>’ receive connector on the frontend transport service. When an inbound connection on port 587 is authenticated, the connection is relayed to the ‘Client Proxy <servername>’ on port 465. This receive connector is not used by end-user clients.
  • The ‘Outbound Proxy Frontend <servername>’ receive connector on the frontend transport service is also not used by end users. This receive connector is used by Send Connectors created in the transport service that are using the frontend transport service to send outbound messages.

SMTP Protocol Logging

How do you know which servers, appliances, or applications use your Exchange servers for SMTP purposes?

By default, the ‘default frontend <servername> receive connector, and the ‘Outbound Proxy Frontend <servername>’ receive connector have protocol logging enabled. Protocol logfiles on the Exchange servers are stored in the C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive directory. When checking a protocol logfile, you can find information like this:

2023-05-19T12:49:09.022Z,AzExch01\Default Frontend AZEXCH01,1,10.83.4.56,>,"220 AzExch01.labs.local Microsoft ESMTP MAIL Service ready at Fri, 19 May 2023 14:49:08 +0200",
2023-05-19T12:49:09.034Z,AzExch01\Default Frontend AZEXCH01,2,10.83.4.56,<,HELO FILESERVER,
2023-05-19T12:49:09.035Z,AzExch01\Default Frontend AZEXCH01,3,10.83.4.56,>,250 AzExch01.labs.local Hello [10.83.4.56],
2023-05-19T12:49:09.047Z,AzExch01\Default Frontend AZEXCH01,4,10.83.4.56,<,MAIL FROM:<synology@exchangelabs.nl>,
2023-05-19T12:49:09.098Z,AzExch01\Default Frontend AZEXCH01,5,10.83.4.56,*,08DB58670C40BA1D;2023-05-19T12:49:09.021Z;1,receiving message
2023-05-19T12:49:09.099Z,AzExch01\Default Frontend AZEXCH01,6,10.83.4.56,>,250 2.1.0 Sender OK,
2023-05-19T12:49:09.115Z,AzExch01\Default Frontend AZEXCH01,7,10.83.4.56,<,RCPT TO:<jaap@wesselius.info>,
2023-05-19T12:49:09.119Z,AzExch01\Default Frontend AZEXCH01,8,10.83.4.56,>,250 2.1.5 Recipient OK,
2023-05-19T12:49:09.132Z,AzExch01\Default Frontend AZEXCH01,9,10.83.4.56,<,DATA,
2023-05-19T12:49:09.132Z,AzExch01\Default Frontend AZEXCH01,10,10.83.4.56,>,354 Start mail input; end with <CRLF>.<CRLF>,
2023-05-19T12:49:09.199Z,AzExch01\Default Frontend AZEXCH01,11,10.83.4.56,*,,Proxy destination(s) obtained from OnProxyInboundMessage event.

Note. Some information regarding message ID, Exchange server IP address, and port numbers have been removed for readability.

In the protocol logfile, you can see the date and time of the communication, which receive connector was used, and which IP address is connecting to your server. This can be very useful when you must troubleshoot mail flow issues.

Summary

In this article, I discussed the transport services and the default receive connectors in Exchange 2019. In a default situation, all devices, servers, and applications can access the Exchange 2019 server and send email messages to recipients in Exchange 2019 anonymously. By default, it is impossible to relay messages outside the Exchange organization, except for authenticated SMTP.

In my next article, I will discuss how to customize that receive connector and the various options available for SMTP relay.

Microsoft Platform Migration Planning and Consolidation

Minimize the risk, time, cost, and complexity associated with your next Exchange Online Domain Transfer

About the Author

Jaap Wesselius

Jaap is an independent consultant based in The Netherlands. Starting with Exchange 5.0 in 1997, he has been working with Exchange for almost half of his life. After leaving Microsoft as an employee, Jaap started as an independent consultant in 2006, continuing to work with Exchange and later on with Exchange Online. Besides consulting work, Jaap is an author of several books (some coauthoring with Michel de Rooij), blogger, presenter, and these days part-time (kids leaving the house) dad. Besides working with Exchange, Jaap is also a motorcycle enthusiast, owning several motorcycles. For his work in the community, Jaap received the MVP award back in 2007, an award that was constantly re-awarded up to this day, something he is very proud of.

Comments

  1. Jaap Wesselius

    Hi Ben,
    another solution like the Postfix deployment you mention is I think the best option.
    Thanks, Jaap

  2. Jaap Wesselius

    Hi Ben,
    in my example i have an account in on-premises AD and mailbox in Exchange 2019 and I use this account to submit mail on port 587. If you have a user with a mailbox in Exchange Online and this user wants to use authenticated SMTP in Exchange 2019 that the user must use a local account to accomplish this. It must be a mailbox on-premises.
    But why does a user with a mailbox in Exchange Online wants to use authenticated SMTP in Exchange 2019?

    1. Ben Lye

      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.

  3. Ben Lye

    When you say “The bad news is that for authentication, the account must have a mailbox.” I assume that this means that to send via on-prem Ex2019 servers you need an on-prem mailbox?

    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?

  4. René

    Hi Jaap
    Thank you very much for your reply!
    Please correct me if I am wrong, but from my point of view the situation with Outlook is different because it is about authenticated users with a mailbox. On the default frontend connector, however, anyone who has network access can send with any sender address.

    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é

    1. Jaap Wesselius

      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

  5. Jaap Wesselius

    Hi 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

    1. Edem

      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 !

      1. Jaap Wesselius

        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).

  6. René

    Thanks for the informative article!
    As you mentioned, in a default situation, all devices, servers, and applications can access the Exchange 2019 server and send email messages to recipients in Exchange 2019 anonymously.
    I read in many places, including your article, that the default receive connectors should be left as they are.
    But what if you want to prevent that anyone can send emails via “Default Frontend ” to Exchange recipients?
    Thank you, René

Leave a Reply