Article ID: 319356 - Last Review: October 28, 2006 - Revision: 2.3 How To prevent unsolicited commercial e-mail in Exchange 2000 ServerThis article was previously published under Q319356 On This PageSUMMARY
This step-by-step article describes how to prevent unsolicited commercial e-mail messages and how to reduce the possibility that your server can be used to relay unsolicited commercial e-mail messages. Unsolicited commercial e-mail messages, or junk e-mail messages ("spam"), is an annoyance of modern office and home e-mail message users. To delete these messages wastes time, but its effects can become far more troublesome if your Exchange Server computers are inadvertently being used as relays for mass-mailings. Some of the recommended changes in this article only apply if your Internet service provider (ISP) provides store and forward services or a smart host for your domain. This is probably the situation if you have a dial-up connection to the Internet or if your ISP provides firewall, routing, or network address translation services for your organization. RequirementsThe following list outlines the recommended hardware, software, network infrastructure, and service packs that you need:
This article assumes that you are familiar with the following topics:
How to Plan and Implement the Level of ProtectionWhen you plan and you implement the steps to prevent the transmission of unsolicited commercial e-mail messages, there are a number of factors that you must consider.How to Prevent RelayingRelaying is the action of an inbound connection to your SMTP server being used to send e-mail messages to external domains. With unsolicited commercial e-mail messages, sending a single e-mail message to your SMTP server with multiple recipients in domains external to your organization does this. Because the default setting for SMTP servers is to use anonymous authentication, the system being used to propagate the unsolicited commercial e-mail messages accepts the inbound message as typical. After the message is accepted, the SMTP server recognizes that the message recipients belong to external domains, and then the SMTP server delivers the messages. Therefore, the unauthorized users who send unsolicited commercial e-mail messages only have to send one inbound message to your SMTP server so that it can then be delivered to thousands of recipients, which slows down your Exchange Server computer's responsiveness, congests queues, and causes irritation and annoyance to the recipients when the messages arrive in their Inboxes.The primary means of controlling relaying is by not granting relay permissions to any other hosts. However, there are times when relaying is required. For example, if you have Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP4) clients who rely on SMTP for message delivery and have legitimate reasons for sending e-mail messages to external domains. You can work around this issue by creating a second SMTP virtual server that is dedicated to receiving e-mail messages from POP3 and IMAP4 clients. This additional SMTP virtual server can use authentication combined with Secure Sockets Layer (SSL) based encryption and can be configured to allow relaying for authenticated clients. Note If you have POP3 and IMAP4 clients, for additional information about how to encrypt SMTP message delivery, click the article number below to view the article in the Microsoft Knowledge Base: 319267
(http://support.microsoft.com/kb/319267/
)
How to secure Simple Message Transfer Protocol client message delivery in Exchange 2000
How to Configure IP Address RestrictionsConfiguring Internet Protocol (IP) address restrictions allows you to specify IP addresses, IP ranges or Domain Name System (DNS) domains from which your SMTP server accepts inbound sessions. This technique is useful if your ISP accepts messages on your behalf, and then forwards messages to you, as it prevents other hosts from connecting to your SMTP connector.Note For IP address restrictions to function, the mail exchange (MX) record on your domain's Internet DNS zone must point to your ISP's e-mail messaging server, not to your Exchange Server computer. If you receive your external SMTP e-mail messages from your ISP's e-mail messaging server, you can configure IP address restrictions. IP address restrictions indicate that your SMTP virtual server only accepts connections from your ISP's e-mail messaging server.
How to Implement AuthenticationImplementing user-based authentication provides the ability for external hosts or clients to present a username and password to log on to the SMTP virtual server. However, similar to IP address restrictions, configuring authentication is possible only if your ISP is acting as a message relay for your organization, and can provide authenticated connections to your SMTP virtual server. Your ISP must also support Transport Layer Security (TLS), which encrypts the whole authentication and message transfer session.Note It is not probable that your ISP supports the option for Integrated Windows Authentication (NTLM authentication).
How to Set Message LimitsSetting message limits involves changing the default number of recipients per message. This procedure reduces the effect of unsolicited commercial e-mail messages by preventing the delivery of a single message to a large number of individuals. Additionally, you can reduce the maximum message size and the session size.Note If you reduce the number of recipients per message this procedure can affect delivery to your internal recipients if you have very large distribution lists that receive their e-mail messages by means of SMTP. However, this is not an issue for Messaging Application Programming Interface (MAPI) recipients.
How to Use Reverse DNS LookupIf you are receiving messages directly from other domains on the Internet, you can configure your SMTP virtual server to perform a reverse DNS lookup on the incoming e-mail messages. This configuration makes sure that the sending e-mail messages server's IP address (and its fully qualified domain name) matches the message sender's domain name. Reverse lookup helps to prevent address spoofing. However, reverse lookup adds an additional load on your Exchange Server computer. See the "Troubleshooting" section for more information. This technique also requires that your Exchange Server computer can contact the reverse lookup zones for the sending domain.Note If you are only configuring your SMTP virtual server to perform DNS reverse lookups, you will not block the non-matching domain name / IP address. The DNS reverse lookup simply resolves the DNS name from the IP address and replaces the DNS name in the header with the name that resulted from the DNS reverse lookup. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: 297412
(http://support.microsoft.com/kb/297412/
)
The "Perform Reverse DNS Lookup for Incoming Messages" option is for host name resolution
How to Configure the SMTP ConnectorYou may have created an SMTP connector on your Exchange Server computer to make outbound connections and to accept inbound connections to and from other SMTP servers on the Internet. This SMTP connector must be associated with at least one SMTP virtual server to operate. You must verify that the SMTP connector is best configured to reduce your vulnerability to relaying unsolicited commercial e-mail messages.
How to Confirm that the IP Restrictions Function
TroubleshootingAny restrictions based on DNS lookup can adversely affect the performance of the Exchange 2000 Server computer. Because the Exchange 2000 computer performs a reverse DNS lookup on each inbound connection, it requires a functioning DNS reverse lookup zone to be available and that the sending host is registered with that zone.For additional information about how to configure reverse lookup zones, click the following article number to view the article in the Microsoft Knowledge Base: 251509
(http://support.microsoft.com/kb/251509/
)
Cannot restrict access by domain name if DNS is not configured correctly
REFERENCES
For more information about how to prevent unsolicited commercial e-mail messages, see the Exchange Server 2000 Help and the Exchange 2000 Server Resource Kit. A list of resources about how to prevent unsolicited commercial e-mail messages is in the following Microsoft Knowledge Base article: 249266
(http://support.microsoft.com/kb/249266/
)
Online resources for spam mail testing and information
For additional information about how to encrypt SMTP message delivery, click the following article number to view the article in the Microsoft Knowledge Base:
319267
(http://support.microsoft.com/kb/319267/
)
How to secure Simple Message Transfer Protocol client message delivery in Exchange 2000
For additional information about how to configure security for incoming POP3 connections to your Exchange 2000 computers, click the following article number to view the article in the Microsoft Knowledge Base:
319273
(http://support.microsoft.com/kb/319273/
)
How to secure Post Office Protocol client access in Exchange 2000
For additional information about how to configure security for incoming IMAP4 connections to your Exchange 2000 computers, click the following article number to view the article in the Microsoft Knowledge Base:
319278
(http://support.microsoft.com/kb/319278/
)
How to secure Internet Message Access Protocol client access in Exchange 2000
For additional information about how to configure reverse lookup zones, click the following article number to view the article in the Microsoft Knowledge Base:
251509
(http://support.microsoft.com/kb/251509/
)
Cannot restrict access by domain name if DNS is not configured correctly
For additional information about the Window 2000 SRP1, click the following article number to view the article in the Microsoft Knowledge Base:
311401
(http://support.microsoft.com/kb/311401/
)
Windows 2000 Security Rollup Package 1 (SR about the Window 2000 SRP1), January 2002
For additional information about the Windows 2000 SNMP Security Update, click the following article number to view the article in the Microsoft Knowledge Base:
314147
(http://support.microsoft.com/kb/314147/
)
MS02-006: An unchecked buffer in the SNMP service may allow code to run
For additional information about the Windows 2000 Security Patch, click the following article number to view the article in the Microsoft Knowledge Base:
313450
(http://support.microsoft.com/kb/313450/
)
MS02-012: A malformed data transfer request may cause the Windows SMTP service to stop working
| Article Translations
|
Back to the top
