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.
back to the top
The following list outlines the recommended hardware, software, network infrastructure, and service packs that you need:
NOTE: For more information about how to obtain the service
packs and the security updates, see the "References" section later in this
article.
This article assumes that you are familiar with the following topics:
When 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.
back to the top
Relaying 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 HOW TO: Secure Simple Message Transfer Protocol Client Message Delivery in Exchange 2000
Configuring 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.
Implementing 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).
Setting 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.
If 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 only configuring your SMTP virtual server to
perform DNS reverse lookup, you do not block the non-matching
domainname/ipaddress messages. The DNS reverse lookup will resolve the DNS
name from the IP address and will replace the DNS name in the header with the
name that resulted from the DNS reverse lookup.
For additional information, click the article number below to view the article
in the Microsoft Knowledge Base:
297412 XCON: Perform Reverse DNS Lookup for Incoming Messages
You 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.
Any 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 article number below to view the article in the Microsoft Knowledge Base:
251509 XFOR: Cannot Restrict Access by Domain Name if DNS Is Not Configured Correctly
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 XFOR: Online Resources for Spam Mail Testing and Information
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 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 article number below to view the article in the Microsoft Knowledge Base:
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 article number below to view the article in the Microsoft Knowledge Base:
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 article number below to view the article in the Microsoft Knowledge Base:
251509 XFOR: Cannot Restrict Access by Domain Name if DNS Is Not Configured Correctly
For additional information about the Window 2000 SRP1, click the article number below to view the article in the Microsoft Knowledge Base:
311401 Windows 2000 Security Rollup Package 1 (SRP1), January 2002
For additional information about the Windows 2000 SNMP Security Update, click the article number below to view the article in the Microsoft Knowledge Base:
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 article number below to view the article in the Microsoft Knowledge Base:
313450 MS02-012: A Malformed Data Transfer Request May Cause the Windows SMTP Service to Stop Working
| Last Reviewed: | 6/5/2003 |
| Keywords: | kbhowto kbHOWTOmaster KB319356 kbAudITPro |