Exchange - receiving and sending mail using Receive Connectors

This article was also published as part of the Microsoft TechNet Blog CZ/SK in the Microsoft section on Živě Exchange: handling mail using Receive Connectors.

Note: The information provided corresponds to Exchange Server 2010 SP2, but even the 2007 version is very similar in this area.

The title mentions sending mail using Receive Connectors, which may seem contradictory, as this connector is used for receiving mail. For sending, we have a different type of connector called a Send Connector. However, the configuration of permissions on the Receive Connector can influence, in certain situations, whether we are able to send a message further. Also, we need to look at the terms "receive" and "send" from the perspective of the Exchange server, not our own. The configuration of the Send Connector does not have any pitfalls, and we will not go into that here.

Description of Receive Connectors

On an Exchange server, we can create a variety of receive connectors. They are distinguished by a unique combination of parameters, which are the local IP address, port, and source IP address range. Based on these values, the connector to be used for a given connection is selected.

Configuration or creation of a Receive Connector is done using the Exchange Management Console (EMC), which does not allow setting all properties, or the Exchange Management Shell (PowerShell), and for some settings we can also use ADSIEdit.

When working with connectors, we most often deal with two areas:

• who can connect to the connector - i.e., authentication
• where messages can be delivered through the given connector - only to mailboxes on the server or forwarded further to the internet, or what the sender address can be - so it's about permissions

Note: The term Open Relay is also related to the Receive Connector. This refers to a server that allows anyone from the internet to send mail through it (i.e., messages that do not end up on it) without authentication. This has been completely undesirable for a long time, as such servers are abused by spammers.

On the Hub Transport server (which is part of the domain), information about the connectors is stored in Active Directory. We can look at them using the ADSIEdit.msc tool in Configuration - Services - Microsoft Exchange - company - Administrative Groups - Exchange Administrative Groups - Servers - server - Protocols - SMTP Receive Connectors.

The configuration of the Receive Connector using the Exchange Management Console is located in Server Configuration - Hub Transport - our server.

Default connectors

After installing the server with the Hub Transport role, two connectors are automatically created: Client Servername (the NetBIOS name of the server is servername), which is intended for receiving mail from non-MAPI clients, is set up for the Exchange User with authentication, but uses port 587 for receiving (although this is a commonly used port for this purpose, it is much less known than the standard port 25). The second connector is Default Servername, which is intended for receiving mail from other Hub Transport and Edge Transport servers, also requires authentication, and allows connections from servers, listening on port 25 by default.

It is assumed that we have an Edge Transport Server, where a connector is created that accepts anonymous connections from the internet (which we need to receive messages from other mail servers). If we don't have one, we need to modify the default connector or create a new one.

Creating a connector

When creating a new connector, we set the expected usage purpose, and based on this selection, the authentication and permissions on the connector are set. For an already created connector, we cannot change this purpose (there is nothing like that in its parameters, this value is used only for setting in the wizard), but we can individually adjust the authentication and permissions.

We can set the following five values, with the corresponding properties that will be set.

• Client - permission groups: ExchangeUsers, authentication: TLS, Basic authentication + TLS, Integrated Windows authentication
• Custom - permission groups: none, authentication: none
• Internal - permission groups: ExchangeServers, ExchangeLegacyServers, authentication: Exchange Server authentication
• Internet - permission groups: AnonymousUsers, Partner, authentication: None or Externally Secured
• Partner - permission groups: Partner, authentication: TLS + Enable Domain Security (Mutual Auth TLS)

The following two images show the first tabs in the properties of the created Receive Connector, as we can view and edit them using the EMC. Here, the basic connector properties are set, which are intuitive enough that we won't go into them in detail, and will instead look at the next tabs.

When an SMTP session is established, the appropriate connector is first selected based on the network parameters. Then the client is offered the allowed authentication methods on the given connector. The client chooses the best one it supports and authenticates. After authentication, the corresponding permissions are set. These things are related to the values we set on the connector, in the EMC they are the Authentication and Permission Groups tabs.

Authentication

On the Authentication tab, we choose which authentication methods the connector will offer and support. If we want a connection without authentication, we don't check any option. For connection from some application servers, we need to select Basic Authentication (which corresponds to SMTP AUTH), ideally with TLS, because otherwise the password is transmitted unsecurely (the username and password are only encoded using Base64). Integrated Windows authentication uses NTLM or Kerberos.

Permission Groups

Permission Groups are predefined groups of objects (users, computers, security groups) that we can set on the Receive Connector. For example, Exchange Users contains the AD group Authenticated Users and Anonymous users are unauthenticated users. Additionally, various detailed permissions are automatically assigned to each group. For Anonymous, these are Ms-Exch-SMTP-Submit, Ms-Exch-SMTP-Accept-Any-Sender, Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender, Ms-Exch-Accept-Headers-Routing. For Authenticated Users, the rights are Ms-Exch-SMTP-Submit, Ms-Exch-SMTP-Accept-Any-Recipient, Ms-Exch-Bypass-Anti-Spam, Ms-Exch-Accept-Headers-Routing.

Receive Connector Permissions

Regarding permissions on the connector, the EMC only allows us to make a rough setting using Permission Groups, which should allegedly be sufficient for most situations (but I don't see it that way). Selecting a permission group sets the rights (ExtendedRights) for a specific object on the connector itself. There are several special permissions for the purposes of the Exchange server. Most of their purpose is quite understandable from the name, but we'll provide a brief description of the most important rights here.

• ms-Exch-SMTP-Submit - basic right for the connector to accept a message
• ms-Exch-SMTP-Accept-Any-Recipient - allows sending messages (relaying) to recipients outside our organization, without this permission it only accepts messages for recipients whose address falls within the accepted domains
• ms-Exch-SMTP-Accept-Any-Sender - bypasses the sender spoofing check, otherwise the user must have permission to send from this address
• ms-Exch-SMTP-Accept-Authoritative-Domain-Sender - allows sending messages from email addresses that belong to authoritative domains (processed by our server)
• ms-Exch-Accept-Headers-Routing - leaves the headers unchanged, otherwise the received headers are removed

Receive Connector Configuration

Creating a connector or setting it up using the Exchange Management Console is not complicated. It's similar using the Exchange Management Shell, where we mainly have two commands available: New-ReceiveConnector and Set-ReceiveConnector. We won't go into that here, but will instead look at settings that we can't do through the EMC.

For detailed permission settings on the connector, we can use either EMS or also ADSIEdit.msc. The further description will use EMS, but the idea is to know what we're setting, and if someone prefers ADSIEdit, there's no problem setting it there (the path where the connector is located was provided at the beginning of the article).

Setting the Banner - server identification

At the beginning, we'll mention only one exception from the further description of permission configuration. It's about a suitable security setting on the connector, especially if it's accessible from the internet. When an SMTP connection is established on the server, it identifies itself by its name and the text Microsoft ESMTP MAIL Service, which may suggest to an attacker (of course, this is not the only thing that can indicate that it's a Microsoft mail server). We can change this text by configuring the connector using EMS.

Set-ReceiveConnector -Identity "SERVER\Default SERVER" -Banner "220 Firma mail server"

Finding the set permissions on the connector

As we mentioned, through the EMC we only see the set Permission Groups. In practice, we often need to look directly at the permissions and possibly change them. Using EMS, we can first list the connectors:

Get-ReceiveConnector

Then display the set permissions on the connector:

Get-ReceiveConnector "SERVER\connector name" | Get-ADPermission | FT -AutoSize

This is a long list and does not contain the ExtendedRights, which is probably the main thing we want to display. So we'll modify our query a bit.

Get-ReceiveConnector "SERVER\connector name" | Get-ADPermission | Sort-Object User | FT User, ExtendedRights, Deny, IsInherited -AutoSize

This is nicer, but still a long list. In many cases, we are interested in the permissions set for authenticated and anonymous users, so we can further limit the list. Alternatively, we can modify it so that it displays the permissions for a particular group or user. Here are two examples.

Get-ReceiveConnector "SERVER\connector name" | Get-ADPermission | where-object {$_.User -ilike "NT*"} | Sort-Object User | FT User, ExtendedRights, Deny, IsInherited -AutoSize
Get-ReceiveConnector "SERVER\connector name" | Get-ADPermission | where-object {$_.IsInherited -eq $false} | Sort-Object User | FT User, ExtendedRights, Deny, IsInherited -AutoSize

Setting permissions on the connector

In practice, there are various situations where the default permission settings do not suit us, and we need to set them better. Most often, it's about wanting to use Relay. That is, for our mail server to forward messages, for example from application servers, printers, etc. The idea is to configure this situation as securely as possible and not create an Open Relay. We'll provide a few common situations and what permissions need to be set. At the end, there is an example command that performs the configuration.

The connector that receives mail from the internet must accept anonymous users. This can also be set through the EMC. In EMS, we can then check that for this group (ANONYMOUS LOGON) it only accepts messages intended for recipients from Accepted Domains, i.e., it does not have the ms-Exch-SMTP-Accept-Any-Recipient right.

The connector for clients usually needs to allow sending messages to all recipients (even outside the organization) and should require authentication, so the Authenticated Users group needs the ms-Exch-SMTP-Accept-Any-Recipient right.

For application servers, we need a connector that is limited to only selected sender IP addresses, either we set authentication on it (e.g., Basic + TLS) or even without authentication (if the client doesn't support it). If we want to send messages outside the organization, we need ms-Exch-SMTP-Accept-Any-Recipient, and we may also need to set ms-Exch-SMTP-Accept-Any-Sender. If we use authentication, we probably have a special account that the client authenticates with, and we can set permissions on the connector only for this user.

If we don't limit the connector, for example, by source IP addresses, we can use it for multiple groups with different permissions. Because we'll set different permissions for authenticated users and different for anonymous ones.

Configuration using EMS looks like this:

Get-ReceiveConnector "SERVER\Default SERVER" | Add-ADPermission -User "NT AUTHORITY\Authenticated Users" -ExtendedRights ms-Exch-SMTP-Accept-Any-Sender, ms-Exch-SMTP-Accept-Authoritative-Domain-Sender