Subscribe to our Newsletter. The latest news and articles delivered to your Inbox!
A Software Development Consultant with over 20 years of experience. Many of his projects involved Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.
Leaving an email server open to relaying hurts the domain reputation. Once listed in public RBLs and private block lists recovering can be costly. Luckily securing Exchange against relaying is easy.
Relaying is the process of forwarding emails between SMTP servers. It takes place whenever a server is unable to directly delivery an email to the destination mailbox. In this case an email must be handed over to another server that is able to deliver or route the email to its intended recipient.
A mail server typically handles two email types:
Emails addressed to local domains i.e. emails for which the server hosts mailboxes
Emails addressed to foreign domains i.e. emails for which the server must resort to relaying
From this discussion it should be clear that relaying is a necessity. However it should only be allowed for emails originating from trusted sources. Otherwise this functionality could be abused giving rise to an open relay.
As shown in
Testing Exchange through Telnet,
it is easy for anyone to test if a server is an open relay. Spammers and maleware distributors quickly discover such misconfigured servers, employing the host to deliver their messages.
Open relays are especially useful to spammers in order for them to hide the true email origin. Consider the case of a reputable organization whose server is misconfigured as an open relay. Suddenly this starts distributing spam. Filters basing themselves on the source host IP might be tricked for a short while until their data is refreshed.
The relaying sever suffers from loss in bandwidth. Even worse it is soon blacklisted in RBLs, many of its emails including legitimate ones ending up blocked.
Relaying configuration is available from the Exchange System Manager under the SMTP Virtual Server properties at:
<Organization> | Servers | <Server> | Protocols | SMTP
Open the virtual server properties and select the Access property page:
Next click the Relay button:
As the dialog shows, by default relaying is allowed for the list of explicitly configured hosts (this list is initially empty). Relaying is also allowed for all authenticated connections.
This blocks relaying over anonymous connections. However some applications might necessitate an exception. For example, a reporting application that is not Exchange integrated and that sends outbound SMTP emails. In such cases you will need to identify the hosts from which the SMTP traffic will originate. At the Relaying configuration dialog, click on Add:
Identify the hosts by specifying a single source IP, an entire subnet, or a domain. Controlling relay access by domain is best avoided as it requires the server to perform reverse DNS lookups that slow down email flow.
Allowing relaying from authenticated connections could potentially provide an opening. This is true when Exchange is internet facing, handling incoming emails from foreign domains. If authenticated connections are allowed, an attacker could attempt to discover valid credentials through a brute force attack. If successful, Exchange would again be available for relaying.
To avoid this, relaying from authenticated connections could be disabled. However this would only solve the risk of relaying. A brute force credentials discovery would still be possible. For this reason, in case of internet facing servers it is often recommended to disable SMTP connection authentication altogether.
This is done from the Exchange System Manager SMTP Virtual Server properties Access page. From here click on the Authentication button:
Make sure 'Anonymous access' is enabled and disable 'Basic authentication' and 'Integrated Windows Authentication'.
Testing Exchange through Telnet
How to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server