Many Exchange Server deployments face mail flow issues because of bad message routing configurations. Erroneous...
configurations are often caused by an administrator's lack of message routing knowledge and misconceptions about SMTP virtual servers and connectors.
An SMTP virtual server is an instance of the SMTP service running on an Exchange server. It is bound to a particular IP address (or group of IP addresses) and port, usually the well-known TCP port 25.
Connectors, on the other hand, do not belong to a particular Exchange server as such. Routing Group Connector and SMTP Connector are the two connectors most used in Exchange Server deployments. There are a number of other connectors to third-party messaging systems like Connector for Lotus Notes, Connector for GroupWise, et al -- but most organizations do not use the latter connectors on an ongoing basis.
The Routing Group Connector connects Exchange Server routing groups. Within a routing group, Exchange servers can exchange messages directly to/from each other. However, to send/receive messages to/from another routing group in the organization, a connector is required.
The SMTP Connector is generally used to connect to other SMTP messaging systems, including the Internet. SMTP connectors can be used to connect routing groups as well, but routing group connectors perform this function well, and are remarkably easy to set up.
Setting up smarthosts on a SMTP virtual server: Smarthosts are used to connect Exchange Server to an external (to the organization) messaging system. Typical use of a smarthost involves relaying outbound SMTP email to a non-Exchange SMTP host in perimeter networks; or to an ISP or hosted service provider that may offer functionality like mail relaying and spam and virus scanning.
In an Exchange Server organization with a single Exchange server, setting up a smarthost on the SMTP virtual server can work, and may not cause any issues. However, for organizations with more than a single Exchange server, this will stop messages from being routed to other Exchange servers in the organization.
It is a good practice to set up smarthosts for particular address spaces. This includes all non-local address spaces designated by the * address space, and generally thought of as outbound Internet email.
Authentication settings on Internet-facing SMTP servers: Yet another misconception exists about use of authentication for Internet-facing SMTP servers. Common sense dictates that Internet-facing servers and services should have some sort of authentication -- perhaps even encrypted authentication so the credentials are not plaintext.
However, to receive email from SMTP hosts on the Internet -- which neither have any interaction with your organization nor have any type of credentials to authenticate with -- you will have to unlearn this piece of conventional wisdom. You have to leave the host free to accept SMTP connections from anonymous SMTP hosts.
Relay settings on Internet-facing SMTP servers: Exchange 2000 and Exchange 2003 have relaying turned off by default. It is a secure configuration that works. If the SMTP server is responsible for receiving inbound Internet email, it should not allow any sending hosts to relay. In other words, it should not accept email for any domains other than the ones your Exchange Server organization is responsible for, or is configured to accept.
If you have SMTP clients that need to send email using SMTP -- like remote or mobile devices using IMAP4 or POP3 clients -- it is best to set up an additional SMTP virtual server that supports authentication. If requirements dictate, you may also want to encrypt the SMTP session using SSL/TLS.
Microsoft Outlook clients connected to Exchange Server using MAPI do not use SMTP to send email to the server. Devices like printers, scanners and faxes (or their multi-function variants) that send documents by email to internal users do not generally need the ability to relay. Sending email to recipients/SMTP address spaces for which Exchange Server is responsible is not relaying.
However, if such devices use Exchange Server to send outbound SMTP email to external recipients, they need the ability to relay. This is accomplished by adding the device's IP address from SMTP Virtual Server Properties -> Access tab -> Relay.
Other hosts that may possibly need relaying permissions are different line-of-business application servers like customer relationship management (CRM) or enterprise resource planning (ERP) servers. These need to send SMTP email to external recipients using Exchange Server, and to communicate with IT management servers that send notifications using SMTP.
The important point to consider is that relaying needs to be allowed only for those applications that have to send email to recipients external to your Exchange Server organization -- typically Internet recipients.
BEST PRACTICES GUIDE: THE 10 MOST COMMON EXCHANGE SERVER ISSUES
Issue #1: Exchange Server storage sizing and location
Issue #2: SMTP virtual server and connector configuration
Issue #3: Exchange recipient policies and Recipient Update Service
Issue #4: Exchange Server messaging hygiene
Issue #5: Exchange Server and DNS
Issue #6: Front-end/back-end Exchange Server topology issues
Issue #7: Exchange Server information stores and mailbox sizes
Issue #8: Moving or removing Exchange servers
Issue #9: Exchange Server backups and disaster recovery
Issue #10: Exchange Server monitoring -- or lack thereof
|ABOUT THE AUTHOR:|
| Bharat Suneja, Microsoft Exchange MVP
Bharat Suneja is a Microsoft Certified Trainer (MCT), Exchange MVP, and Principal Exchange Architect for Zenprise, Inc., maker of real-time troubleshooting and diagnostics software for Exchange. Bharat Suneja has over 10 years of experience in IT, architecting and managing Exchange Server and Active Directory environments, ranging from small and mid-sized businesses and e-commerce companies to large ISPs and ASPs. An active writer and contributing editor for international IT publications such as PC Quest, Bharat was also a technical reviewer for Exchange Server 2003 24 Seven by Jim McBee. Visit Bharat Suneja's blog at www.exchangepedia.com/blog.
Dig Deeper on Email Protocols