Print - Is Your Exchange Server Relay-Secure?

In August 1999, Microsoft released an Exchange Server 5.5, post-Service Pack 2 (SP2) hotfix to address a specific Exchange mail-relaying vulnerability. This fix plugged a security hole that let the Internet Mail Service (IMS) relay encapsulated SMTP messages, even if you'd configured the server to prevent relaying.

Many companies, however, haven't secured their servers. In a quick test of 20 sites, I found that between 60 and 70 percent of them either hadn't applied this security patch or hadn't configured their servers to block relays in the manner that the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2505 suggests.

If you haven't completely secured your server against relaying, an outsider can use your server to deliver email that appears to have originated from your server and possibly from one of your mail accounts. In the United States and other countries, people periodically debate whether systems' owners are liable if someone uses their system as a relay. The crux of the debate is whether an owner knew about the problem but chose to do nothing about it. Aside from concern about owners' liability, relaying is also a form of Denial of Service (DoS) attack because it takes system resources away from legitimate operations. Relaying is also bad for your company's business because it can generate ill will among your customers.

Let's look at some ways to protect your system against relaying. The sidebar "Protect Your Server Against Encapsulated SMTP Address Vulnerability" discusses the fix for a specific type of relaying problem.

RFC 2505
In February 1999, the IETF released RFC 2505, "Anti-Spam Recommendations for SMTP MTAs." This RFC explains the problems associated with unsolicited commercial email (UCE, or spam) and specifies the functionality that an SMTP Message Transfer Agent (MTA) needs to reduce UCE's effects. RFC 2505 makes 13 recommendations, two of which are most closely related to relaying:

A system must be able to restrict unauthorized use as a mail relay.
A system must be able to configure and provide different return codes for different rules (e.g., 451 Temp Fail vs. 550 Fatal Error). Specific return codes let you diagnose configuration problems that are blocking legitimate mail delivery.

If you're using Exchange Server 5.5, you have the tools to implement these recommendations and prevent the unauthorized use of your resources. To maximize your ability to use these capabilities and configure your system's antirelay defenses, you need to be running SP2 or later and the encapsulated relaying hotfix. An alternative to installing the hotfix is to install SP3, which includes the hotfix. In Exchange Server 5.5 before SP2, you could block relaying only by manually editing the Registry.

As Screen 1 shows, two options on the Routing tab of the Internet Mail Service Properties sheet—Do not reroute incoming SMTP mail and Reroute incoming SMTP mail (required for POP3/IMAP4 support)—control mail relaying. The obvious choice seems to be Do not reroute incoming SMTP mail, but this option has several drawbacks, including that it isn't as secure as it might seem. Selecting this option prevents the IMS from relaying messages, but the IMS still accepts the messages and then generates a nondelivery report (NDR) that specifies that the recipient's address doesn't exist on the system. This configuration doesn't meet the second RFC recommendation because it results in an error code that indicates success and generates an incorrect delivery failure report.

If your server is running in the Do not reroute incoming SMTP mail configuration and you have an email account elsewhere on the Internet, you can confirm the flaws in the process I describe above by configuring a POP3 mail client to use your Exchange server as its SMTP host. For example, if you're using Outlook (i.e., a POP3 mail client) and your external address is joe@realdomain.com, on the General tab of Outlook's Internet E-Mail Properties sheet, set the email and reply addresses to joe@realdomain.com. On the Servers tab, set the Outgoing Server to the IP address or domain name of your Exchange server. Compose a message, and try to send it to a friend's address. Exchange will accept the message, but you'll receive an NDR at your external address.

The IMS Help screen states that this behavior is by design, but this feature has two major drawbacks. First, this configuration could allow your system to be the origin of reverse UCE or even a mail flood. Second, the configuration places an unnecessary processing burden on your system.

Reverse UCE. If you set your system to Do not reroute incoming SMTP mail, malicious users can use your system as a launching point to flood another computer system with SMTP messages. Because the messages include your company's address, they look as if you sent them. For a more detailed look at the SMTP protocol dialog between sender and server, see Mark Minasi's Windows NT Magazine article "Untangling Email" (April 1998). Figure 1 shows a typical SMTP dialog.

As the system issues each of these commands, the Exchange server returns a code to the sending system. All the server responses in the dialog start with a numerical code. This code is either 250 OK, which represents success, or another error code, such as 501 Unrecognized parameter. The SMTP protocol specifies that 200-level codes signify success, 400-level codes signify temporary failures, and 500-level codes signify critical failures.

The logic that the IMS uses when determining whether to deliver a message flows as follows:

Accept sender's address.
Accept recipient's address.
Accept a data stream containing message header and body text.
Determine whether the recipient is a member of the local system (i.e., whether the address is in the Global Address List—GAL).
If yes, deliver the message to the local recipient. If no, use the sender's address to generate an NDR.

Because step 5 can result in the system directing a message back to the sending address, a malicious user could engineer a mail flood by supplying a bogus addressee (RCPT TO) with a valid sending address (MAIL FROM)—the target of the flood—and then infinitely generating messages to the Exchange IMS. In any case, the malicious user achieves the objective of getting an unsolicited message to a destination.

Unnecessary burden on system. You can see the second disadvantage of using the Do not reroute incoming SMTP mail setting by reading the SMTP dialog. You're providing the IMS with the following information: the message sender (MAIL FROM), the message recipient (RCPT TO), and the message (DATA). When your POP3 client sends a message, as in this test, it goes through a similar process. In the current configuration (Do not reroute incoming SMTP mail), the IMS accepts the RCPT TO specification and sends the return code 250 OK even if the recipient isn't part of the local system. Next, the IMS lets you execute the DATA command, through which you could supply megabytes and megabytes of message body text. This action can tie up your system resources, even though the system eventually generates an NDR.

A Better Option
If you attempt to perform these operations on most UNIX hosts that you've configured to prevent relaying, you'll receive a 550 Relaying prohibited SMTP error code when you specify the nonlocal recipient. This result is more desirable, meets the RFC recommendation, and eliminates the two flaws I just described. In this configuration, the IMS proceeds through only four steps before preventing a relay.

Accept sender's address.
Accept recipient's address.
Determine whether the recipient is a member of the local system (i.e., whether the address is in the GAL).
If yes, return 250 OK and accept the recipient; if no, return 550 Relaying prohibited (don't proceed to steps 5 and 6).
Accept a data stream containing message header and body text.
Deliver the message to the local recipient.

When the IMS follows this logic, if the sending system doesn't supply a valid recipient, the server responds with 503 Need RCPT TO command and doesn't let the sender execute the DATA command. This action prevents the sender from tying up system resources as it reads and stores a possibly long message. The action also re-lieves the system of the burden of generating and sending an NDR.

Making the Changes
To configure your system in a similar way, you need to select the Reroute incoming SMTP mail option on the Routing tab of the Internet Mail Service Properties sheet, as Screen 2 shows. Although this choice might seem counter to the objective, it provides a more secure system if you configure it properly. After you've selected this option, you must specify all the domains for which your IMS handles incoming mail. For example, assume that you have no internal or external systems that need to use the Exchange server as a relay and that you're not using any POP or Internet Message Access Protocol (IMAP) clients. Your primary domain is realdomain.com, and you host mail for one other organization: virtualdomain.com.

On the Routing tab, add realdomain.com and virtualdomain.com to the Sent to list. When you add these domains, you have three routing options to choose from, as you see in Screen 3.

Should be accepted as "inbound" signals that all recipients with this domain name must match a corresponding SMTP address in the GAL.
Override relay restrictions. Always "relay" exempts the domain from any restrictions that you set by using Routing Restrictions.
The Should be rerouted to this domain option lets you specify the domain where the system will redirect mail. The IMS replaces the original domain name with the value you specify here. For example, if mail comes into joe@dec.com, the system rewrites the address as joe@compaq.com and sends the message on to the compaq.com mail host.

Select Should be accepted as "inbound" for both realdomain.com and virtualdomain.com. This choice assumes that you don't have any complex scenarios in which you're hiding internal hosts and addresses or allowing relaying through to specific domails.

Choosing the routing option is only part of the configuration. You need to set routing restrictions to protect your system from being wide open for relaying. The Microsoft article "XFOR: Restricting Routing in the Internet Mail Service" (http://support.microsoft.com/support/ kb/articles/q196/6/26.asp) describes how to choose a routing restriction option. Click Routing Restrictions on the Routing tab to display the dialog box you see in Screen 4. Enter the IP addresses of systems that you want to let deliver and reroute mail through your server. This dialog lets you control access to Exchange Server's relaying capabilities under several conditions:

The Hosts and clients that successfully authenticate option assumes that an additional security mechanism is in place to confirm the identity of the sender or system. For example, a host might need to use an Enhanced SMTP Auth command or NT LAN Manager (NTLM) credentials to validate its right to relay.
The Hosts and clients with these IP addresses option lets you grant specific machines or machines on specific subnets the ability to use Exchange as a relay.
The Hosts and clients connecting to these internal addresses option lets you let systems relay if they can access a specific network adapter on a multihomed system.
The Specify the hosts and clients that can NEVER route mail option lets you prohibit specific hosts from relaying when you've granted a large group, such as a subnet, the ability to relay.

What the Microsoft article and online Help don't spell out is that when you select a routing restriction, you can choose not to enter any IP information. The trick is that you can select the Hosts and clients with these IP addresses check box but not specify any IP addresses. Unless you have a specific need to have your Exchange server relay, don't enter any IP addresses on this page. This selection changes the rules that the IMS uses when evaluating the SMTP protocol. Instead of letting the IMS accept the RCPT TO specification blindly, this selection causes the IMS to check for local delivery before letting it upload a message. If the recipient isn't local, the IMS will return 550 Relaying prohibited.

Confirming the Configuration
To make these changes take effect, stop and restart the IMS. If you want to confirm that your server is rejecting relays but still accepting mail for your local recipients, you can use a Telnet session on the SMTP port. Open Telnet, and connect to your Exchange server on port 25. You can connect quickly by selecting Start, Run and typing

telnet servername 25

where servername is the name of your Exchange server. The Exchange server will respond with a message similar to 220 host.domain.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2650.10) ready. Then enter the following commands. The commands aren't case-sensitive, but the punctuation (e.g., colons, angle brackets—< >) is important, so include all the marks.

Enter
```
HELO me
```
The server will respond with 250 OK and identify your IP address and possibly your host name.
Enter
```
MAIL FROM: someaddress@somedomain.com
```
Again, the server will respond with 250 OK.
Enter
```
RCPT TO: nobody@afakedomain.com
```
The server will respond with 550 Relaying prohibited.
Using a valid address from your GAL, enter
```
RCPT TO: thegaladdress@yourdomain
```
The IMS will reply with 250 OK when it accepts the address.
To close the session, type
```
QUIT
```

Protect Your Server and Your Reputation
These changes protect your Exchange server against relaying and help protect your reputation. If you need to allow relaying, check out the Microsoft articles "XFOR: New IMS Routing Functionality in Exchange Server 5.0 SP2" (http://support.microsoft.com/ support/kb/articles/q169/6/83.asp" and "XFOR: Restricting Routing in the Internet Mail Service," which I cited earlier. You can make your server safer when you configure the system to allow as few systems as possible to relay through your server. And don't forget to always thoroughly test your configuration!

This article helped with a similar situation I had and the links led me to the exact solution I needed for the Exchange 2000 server with the same issue. Now, does anyone know how I can log the ip/header information from the originator who was using my server as an unauthorized spam agent? I would really like to NAIL this xxxxxxx!

This Microsoft article provides good information about this process: http://support.microsoft.com/support/kb/articles/Q279/8/60.ASP

The only thing the author failed to mention is that clients who access their Exchange Server through POP3 must use SMTP authentication or they will get a relay error when trying to send email to anyone not on the Exchange Server's domain.

Your article is informative, but your example is for people with no POP3 or IMAP. I support IMAP (internally only) for some of my clients. How do I set up relaying options for that environment? Do I use the "Hosts and clients that sucessfully authenticate" check box or the "Hosts and clients connecting to these internal addresses" check box and use x.x.x.0 for each of my internal segments? Thanks for the informative articles. They really help.

I'm testing an Exchange server through http://abuse.net/relay.html. The server has undergone relay fixing as detailed in this article, but on test 6 of a possible 17, the test fails as follows: Relay test 6 >>> RSET <<< 250 Ok >>> MAIL FROM: <<< 250 Ok >>> RCPT TO: <<< 250 Ok How can I stop '%' SMTP relaying?

This article is for Exchange 5.5 , but I have the same problema with Exchange 2000. How can I get a solution for Exchange 2000?

I'm kind of new to this job (CNA) and I like reading this kind of article, which has helped me a lot. However, I have a big problem. Some people have been using my server to send spams (UCE). I use Win2K Advanced Server and Exchange 5.5 SP4 with IMS installed. I host some domains and followed the steps in this article, but it didn't work 100%. I can send and receive emails as long as I send them to the accounts that are in my GAL, but if a client in one of the domains that I host tries to send out an email to a domain that I don't host, it won't relay. I set up two servers so one of them receives and the other one sends out, but I still have a problem because I need to stop SMTP in the first server, which is the one that is being used to send UCE. Can somebody tell me how I can stop SMTP relaying in my server Exchange 5.5 SP4 server with IMS?

Is there any ways to restrict relaying so that only those messages with a sender or receipient on the local system will be relayed?

My Exchange Server has been a victim of relaying and I have implemented the recommendations mentioned in the article (i.e., I've checked "Hosts and clients with these IP addresses" and not specified any IP addresses in the Routing Restrictions dialog box). This all works fine and stops the relaying used by the spammers. However, now my email users who access the mail server remotely cannot send email to anybody other than my other email users. I cannot add their IP addresses as they are dynamically assigned when they log on to their ISP. Have I implemented this correctly? The result is obviously not a desirable one. How do I stop the spammers and still enable my email users to send mail to people other than my mail server users?

When I Telnet to my Exchange server and attempt to enter any commands, I get the following error message: "500 command not recognized." Any ideas what's causing this error?

Thanks a bunch. This is an excellent site chock-full of extremely valuable info. Your work is GREATLY appreciated. Thanks guys!

This is probably the most valuable Exchange resource site I have found! Keep up the good work and thanks.

I just wanted to send a quick appreciation note to the author for his excellent article on "Exchange Server Relay Secure issues". I personally used this and applied to my Exchange Server... Many thanks, Hung Ong

I am an administrator of Exchange Server 2000 , and my server always be used by someone to relay. So I need your help for the problem necessarily. Thank you very much.

Actually there's still a problem here. We've had a DDoS attack recently which illustrates the problem. This attack cost us hundreds of dollars in traffic charges. Some spammer spammed thousands of people with a forged reply address which was in a domain homed on our server. Note the original spam was NOT sent from our server, but we received thousands of NDRs from all over the world because of it. These should've have been rejected with a 550 error code by our server (which uses the configuration specified in the article) because the address did not appear in the GAL. But actually it seems that the mail will always be accepted if the DOMAIN is ok, even if the email address is invalid.

The settings offered here do not solve the relay problem. Try enter the following commands at step 3. RCPT TO: nobody%afakedomain.com If anyone found a better solution please let me know. Many thanks.

It does not protect Exchange Server 5.5 (SP4) from relaying to SMTP addressing with "!" in address.

I followed all the steps to secure my Exchange Server (Ver. 5.5 SP4) - (WinNT Server 4.0), but I can´t send messages from my recipients to the Internet! (Yahoo, Hotmail, etc.) The message "Relaying is prohibited" appears. I can receive messages from the Internet to my recipients. What´s happening?

Hello. Has anybody received a reply to posted questions which relate to an ! or % in an e-mail address as these WILL relay. In addition, addresses which are enclosed in comments (i.e. "address"@domain.com) WILL also relay.

I followed steps 1-5 as outlined in the article. However, when I do step 4 and enter a valid address from my GAL, I get the "550 Relaying is prohibited" message. Can you help me determine why this happens? I'm not certain, but today, I started getting complaints from users that external senders are getting the 550 message when they try to email someone in my company. Can you help further? Response from author: I have heard of this before when a relay restriction is set up and the "Hosts and clients with these IP addresses" option is cleared. It sounds like you selected only the "hosts and clients" that authenticate option in the relay restrictions settings. This is a valid selection, but you should also select "hosts and clients with these IP addresses" --and just not enter any IP addresses.

I have set this up as stated in the article and also used the suggestion to Rich on Feb 11, 2002 about Hosts and Clients that sucessfully authenticate. We are using POP3/IMAP4 and using this setup requires our users to check "My server requires authentication" and "Use same settings as my incoming mail server" under Accounts/Properties/Servers in Outlook Express. Thx for everything....

Great Options. I followed the steps in "making the changes", left the "Hosts and clients with these IP addresses " blank. BUT... I sniffed the SMTP port and found mail going through with "MAIL FROM:<>" and MAIL FROM: asdf@mydomain.com" where asdf is some random username and mydomain.com is my actual domain name. Any insight???

I followed the instructions in this article and no one in our company could send email out. Do I have to specify their IP addresses in order for this to work? I was under the impression that I didn't have to do that. If I must specify IP addresses, I would like to put in a range of addresses as one article indicated. I tried it, but I would not accept 1.1.1.0> to include all IP addresses greater than that. Any ideas?

i've set the routing tab to no relay. however i'm not getting the 550 server side msg? but mail is no longer being relayed...

Either the article is not complete, or there is a serious flaw in the Internet Mail Connector in version 5.5 (Service pack 4) of Microsoft Exchange server. Although the server passes the simple relay tests as written in the article, a more through relaying test program indicates that it is possible to relay using wildcards % ! and names in comments. I don't trust the simple Microsoft test. Go to http://freshmeat.net/projects/relaytester and download a simple Perl script (written by R. Foster) - You will need a linux system to run the script. Run that against your exchange server. The script simply telnets into the Exchange server port and tries about 17 different address combinations looking for a loophole. Unfortunately, it demonstrated that the exchnage server is relaying. If you don't have access to Linux, just look at one of the files called format.gen and you get an idea of the different address combinations that it tries.

Goto http://www.abuse.net/relay.html , fill in your mailservername (or IP) and see that Exchange is not secure..... (no Linux needed.) Now all we need is a solution to stop relaying mail with ! or % in the address. Anyone found one already? (We're using E5.5SP4)

Good article but has anybody found a way to stop the use of the wildcard characters (!%). Is this an exchange bug or configuration issue, any help would be appreciated.

I wasn't able to implement suggestions successfully. When I did the telnet test, I got a 550 Relay Error on the last command (rcpt to: username@mydomain.com). All other telnet commands tested okay. I am also unable to send email to an address outside of mydomain.com from a mydomain.com address. When I uncheck the box "Hosts and clients with IP addresses" and restart IMS, I am able to send mail out of the domain again. But this doesn't fix the open relay issue. Is there some other configuration I need to change? What am I missing? Please help.
Author response: The only time I've heard of this type of thing is when you select the "Users that authenticate" check box but leave the "Hosts and clients with these IP addresses" clear. Select both of these check boxes.

OK, I think I figured it out, here goes. I used the article to close out relaying using EX 5.5 sp4, and like the rest of you, found that it stilled allowed relaying, or what appeared as relaying to the tester at MAPS (http://work-rss.mail-abuse.org/cgi-bin/nph-rss?). I then instead of attempting to control the IP from outside using the top box (Hosts and Clients with these IP Addreses) of the routing restrictions, I set the middle box Hosts and Clients connecting to these internal addresses) to use the IP address of the Exchange server that for me, was already behind a firewall, and therefore had a gateway MX record listing a routable Ip address, and an actual unroutable IP address in it, and was also the location that all of the departmental machines connect to to use Exchange. This now tests totally clean according to MAPS, which I think, also checks for the echoing back of the received statement. So, I think this clears it up for me. I will test some offsite POP3 connections, hoping that those that are connecting to the Exchange server thru POP3 and not on the same side of the FW, will Exchange view them as being connected to it directly? Hmmm, inquiring minds want to know. Claude

I try to do the test but when I type "RCPT TO: nobody@afakedomain.com" the telnet give me "Bad command format" ... I type this command several times and give me the same error. ... Ed

For those of you concerned about the abuse.net relay test reporting your server *may* or *may not* be relaying, you might like to read this: http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q304897&

Couldn't you guys have shortened this article down. Just give us the quick and dirty facts and tell us how to fix it. This article is way too long and begins to become confusing the further down you read.

I agree somewhat with JMB's comment re: length of article, although as someone without admin experience, some of the additional info did provide good background. Thank you, DrC, for posting the link to the Microsoft Support article, because the relay test I performed via the internet did indicate that my server would relay mail.

Thanks for the article, but as we use pop3, we still have a problem. Could anyone help us in case of pop3/imap clients ... thanks for help.

The implication from this article is that you can configure IMS to check the specified recipient email address against every entry in the GAL and reject those that aren't valid. This doesn't seem to be the case - it seems to only look at the *domain* portion of the email address and automatically accepts it if the domain is considered to be local. It would be nicer/better if it did check the recipient against the GAL first because it could then reject the spam with an error code rather than bunging up the outbound queue with NDRs that can't be delivered to non-existent spammer addresses.

I am using Microsoft exchang 5.5 SP4 and I had a problem when I implemented the following - accept routing from Hosts and clients with these IP addresses check box but not specify any IP addresses. i didn't enter any IP addresses as the article stated -- I also checked hosts and cleints that successfully authenticate-- But the problem is the Exchange excepts this mail and although it doesn't relay it --it remains in the outgoing mail que until it expires -- another problem is that because of this acceptants it fails open relay tests in spite of the fact it doesn't relay - is there any way to stop the mail from being accepted --period?

I have tried all the options given and suggested in the forum and in the article and I still can't stop relaying in Exchange 5.5 SP4 (we use POP3 and IMAP4). I have a choice of I can allow relaying, whichs allows my users to recieve emails, or I can disable relaying which as a result, stops ALL emails coming in. Please help!

I read and followed the instructions in this article after I was notified that my server had an open-relay. Apparently, it fixed the open-relay but it created a very weird problem. I cannot send messages to ANY address in the earthlink.net network in which I myself have a personal address. It's my experience that the weirder the symptom, the simpler the solution, but I have not yet stumbled upon it. Can anyone relate or have any suggestions? Thanks.

i dont know if u have tried this, but those experiencing problems with relaying pop3 client mail like microsoft outlook should try the following. enable relaying on the server. then go to each pop3 client, start outlook express and go to tools. go to account and click on mail accounts. highlight the account and click on properties. on the server tab, under outgoing mail server, tick my server requires authentication. click on settings and provide user name and password. this should sought u out. i figure that the client needs to conect over a secure port.

RE: Sara's Comment...I have tried all the options given and suggested in the forum and in the article and I still can't stop relaying in Exchange 5.5 SP4 (we use POP3 and IMAP4)... Well, Sara found the fix and helped me out as well. I did not have to apply all these fixes myself, as we do not need to relay at all. However, for most of you who do, here's the fix: First, for those that don’t have a need to relay, don’t. Select “Do Not Reroute Incoming SMTP Mail". If you realize you need to allow relaying, I suggest going through the fix I sent: Must backup first. Then install Exchange 5.5sp4 followed by: 1. 09/04/2001 01:01 AM 1,624,280 Q289606engi386.EXE 2. 08/06/2001 01:01 AM 567,680 Q301361i386.EXE 3. 19/07/2001 01:01 AM 7,162,240 Q304062engi386.EXE 4. 09/08/2001 01:01 AM 3,209,600 Q283238engi386.EXE 5. 05/09/2001 01:01 AM 588,176 Q307195engi386.EXE 6. 22/10/2001 01:01 AM 1,153,408 Q289258engi386.EXE * 7. 05/12/2001 01:01 AM 1,218,960 Q313576engi386.EXE 8. 16/05/2002 01:01 AM 1,161,560 Q312273engi386.EXE Go to http://support.microsoft.com/default.aspx?scid=fh;en-us;kbinfo and down the bottom of the page, enter the name of the .exe file, and you will find a patch to download. You must apply them to your Exchange server in this order. [Of the 8 files to download and install, all are available except the 6th one. When you go to the Q Article it says to contact Microsoft for it and obviously you have to pay. Go around that by downloading Q289258engi386.EXE here: http://online.securityfocus.com/bid/4205/solution/ (free to download).] Once this is done and reboots are complete. Go to Connections, Internet Mail Connector, Routing, and make changes accordingly. The changes I made to my routing restrictions were to allow Hosts and Clients that Authenticate, and also Hosts and Clients with these IP Addresses (with the IP and the Mask in the box). I looked through my logs in “imcdata” and found that it was sending “550 Rerouting is Prohibited” messages to people who were attempting to use my exchange server. In regards to the mail queues, you will need to delete those occasionally because sometimes they still manage to connect to your server and will attempt to send mail, and it gets refused, but it will sit in queues. Just delete the queues when you remember. You'll probably find a lot of them come from an originator with "<>" as the name. I also suggest turning up your Diagnostic Logging up to the maximum for all the options, just for a few weeks. It can take up a bit of space, but it's worth going to the “imcdata” folder and having a look to see if Exchange doing what it's supposed to be doing. Don't forget you have to apply those patches in that order...otherwise it won't work, some of the preceding ones have bugs and applying the patches in order fixes the previously installed bugged patches! Thank you Sara!

Melissa, Thanks for submitting your comments on July 23, 2002. My office mail server was tested and the results that were sent to me said it was an open relay. I contacted the consultants who were taking care of the IT stuff in my office before I was hired and they told me they never patched 5.5. I followed your directions and everything is set. Thanks again!

Thank you for the article. We, however, are experiencing the very same problem as did Rich on 2.11 and Ron Kelley on 3.10. We have verified that both check boxes, namely the "Users that authenticate" AND "Hosts and clients with these IP addresses" are selected. However, we can not get the relay to allow a local address from the GAL to pass. Help! What else should we try?

(Part II): It appears, reading further and in particular, the response given to Sara, that if one does not have a need to relay, then one should NOT follow any of the steps in the given article. Is this a correct assumption? If it is correct, then how is one to then make secure their Exchange Server?

A new IMC hotfix not already listed was released in late July. All the hotfixes for Exchange 5.5 since SP4 are available for free download at the M$ Download Center (http://www.microsoft.com/downloads/search.asp?)

We have Exchange 5.5 running on Win2k w/Active Directory. We host 4 domains that POP through the Exchange server. When I disable the open relay, none of the clients can send SMTP. However, they can receive mail. I have applied all the hotfixes, gone into IMS/Routing, entered each domain in the routing table and set the Route to: as , in Routing Restrictions have "hosts and clients with these IP addresses" checked and left the table blank. This still does not work. I have tried entering the IP addresses of the clients in the "hosts and clients with these IP addresses" which still does not work. I have tried variations of checking "hosts and clients that successfully authenticate" and "hosts and clients with these IP addresses", still to no avail. If anyone can shed some light to this matter it would be greatly appreciated.

I tried to do the "better option" but I still got "unable to relay" when I used a GAL.

I was directed to this article by ORDB.ORG as a result of allowing relaying on my mail server. Your article was excellent and your TELNET test made it possible to verify the fix. Thanks!

I've been suffering the same problems everybody else has. Think I finally fixed it .. Try this .. in Routing Restrictions .. CHECK BOTH Hosts and Clients that Auth AND Host and Clients with these IPs (don't specify any IPs.) The trick is on the client side (where you send mail from) you must turn on 'My server requires authentication' under the Outgoing Mail Server section. (I'm using Outlook 2000 Internet Mail) Good Luck .. ok, now how do we expose / prosecute the ones responsible for the hundreds of spam relays ??

Sorry, but if I have got 50 stores all over my country and one Exchange 5.5 server in the central office how to my stores can sent e-mail to the another domains? They haven't got static IP....... and using pop3.... I don't want ask Microsoft because they have the anwser for everything.

I have Exchange 2000. Is it possible that Exchange 2000 does not have Internet Mail Service (IMS). The closest thing I can find to the rounting functionality you describe in this article is in the SMTP Virtual Server Properties. From everything I've read, it appears that the only way to prevent this on EXCH2000 is to specify the IP address of acceptable senders. Is it possible that this newer server has lost the ability to filter relaying on each message From: and To: content?

I have followed this article and carried out the instructions but on step 4 of confirming the configuration I get 550 Relaying prohibited. So it does not work - what have I not done?

I followed this instruction to prevent my exchange 5.5 server from relaying ("The trick is that you can select the Hosts and clients with these IP addresses check box but not specify any IP addresses") but the exchange continues relaying. The only way to stopt relaying was to select the "do not reroute incoming mail" option.

A MILLION THANKS to Dano for his suggestion (require authentication and accept relays from hosts and clients with these IP addresses (none specified)). I applied the fix, tried the telnet test, and eveything seems to be working correctly. It even seems to accept ASPemail generated messages from my web site (this was a sticky point before). Thanks Again - DANO

This article helped me slay the evil dragon of UCE relaying via our Exchange server. Thank you for putting it out on the Internet, the information was truely a blessing!

Great information, took care of my 40,000 e-mail bounces a day. Thank you, Sir. I hate spammers.

OK, hoping someone still reads this feed!! One of my sites requires relay (users who are remote have their mail re-directed to local ISP's in their area, so I am using Custom Recipients (globe icon). My IMC (exch5.5, SP4) was an open relay and I locked it down as per your article - which I have done to other servers before.. Why then, can I no longer send mail to these custom recipients, or even to postmaster - who is an alias for administrator? I think I am going crazy... As per routing restrictions, top two boxes ticked.. no entries in window below that. I once saw an article that mentioned the following IP's to enter: 128.120.0.0(255.255.0.0), 169.237.0.0 (255.255.0.0), and also the IP and subnet of your server.. Can't figure out why, but on this occasion, it won't work. Hoping someone has insight into relaying to custom recipients? Kind regards, Paul

The proposed solution does not work at all for me and I did not see any difference in the amount of huge amount of undeliverable mail that sits in my IMC Outbound Queue. It's one thing to make the Exchange server RFC compliant but it doesn't address the problem which is that spammers appear to be able to somehow relay mail even with re-routing disabled.

If I understand this article correctly... I can host multiple domains and allow "inbound relaying" for each one. By setting up the routing restrictions to allow hosts and clients that authenticate, and not populating any specific IP information, my clients should be allowed to connect and send via POP3 and IMAP (which then can). However, by specifying that hosts must authenticate, messages that originate from the internet to be delivered to the local clients fail because the remote hosts are unable to authenticate, as per this configuration. What other options are available that will allow any host to submit messages for my local users (on my hosted domains) that will also prevent these hosts from successfully submitting messages for users that do not belong to the domains that I host? I believe i have been a victim of one of the exploits mentioned here, wher the reply to address is the same as the invalid senders address, which effectively bypasses the relay when the message is delivered to them by way of an NDR. If I have missed something obvious, please post comments. thanks.

Let's say you want to let internal employees send emails using IMAP4 to the outside world. Would you add * - so all emails sent from an IMAP4 cleint would redirected outside? * = all domains.

This is a great reference document. Very usefull. Thank you Martin Québec, Canada

I run Exchange 5.5 SP3 and have followed all the advice in this article but still I am being relayed. Why?

If you have followed the instructions contained in this article and still find your server relaying mail; make sure your guest user account is disabled.

Very cool !. But my server continue being detected as a "Server relaying mail". What do you mean, exactly, about The Guest account?. Do you mean Winnt Guest account, or Mailbox Guest account?. Thx, by all help !

This configuration does disable the relaying test show above, but it would be nice to have links to sites that have the ability to do higher level testing. Thanks for article, John.

I have tried the way that was in this article, no luck even when telnet to the server everything looks okay, byt still I can see that somone sending smtp mail via my server Henrik

Your article was VERY enlightening. Unfortunately, I am receiving emails from various email servers telling me the address was invalid; meaning, someone is sending email messages with my domain (kai-research.com). My server is definitely configured correctly. Any suggestions??

I am so thankful that I someone in MS Exchange Community News Group pointed to your article. I tried the suggestion that Microsoft Article suggested but to no avail. With the help of the article and turning on Exchange diagnostic Log to Maximum I was able to block spammers and disable or change passwords of my domain passwords. thanks, fin

The advice here was very good, a whole lot better than the Microsoft KB articles and it fixed my relaying problem. Thanks for this article.

I always thought that my exchange box was setup to prevent all relaying only to be nailed by some bot in Taiwan. This article proved a great assistance in understanding the reasons why our server was relaying and how to ensure we don't relay again. Thanks

This article give incorrect information about the behavior of "Should be accepted as inbound". This choice does NOT look up the recipient name in the GAL before accepting the e-mail (as the line describing it implies). There is currently NO way to force Exchange 5.5 to look up a recipient address before accepting an e-mail. There is a custom coding example provided by MS to create a Windows 2000 SMTP Protocol Event Sink, but this might be beyond most people. MS has released an article that talks about why they chose NOT to allow GAL-lookups before accepting an e-mail: http://support.microsoft.com/default.aspx?scid=kb;en-us;304897&Product=ech I think it is wrong and mis-leading to talk about "A Better Option" (which involves looking up a recipient before accepting an e-mail), and then tell users how to make the changes - never telling them that this WILL NOT look up a recipient address before accepting an e-mail.

Hello, I did everything as described in your article. One issue still remains : In the routing page, I stipulated that email sent to "mydomain.com" should be accepted as inbound. This works fine, except that he also accepts all mail to "xxx.mydomain.com" as inbound, which offcourse is not wanted. Can you give me any suggestions as how to solve this ? Thanks in advance. Krist Cappelle

Great article. I have one question, I have POP 3 emplyoees accesing our server remotely and through various ISp's does your remedy prevent them from sending emails? PK

My mailserver was by accident configured as open relay server. I was searching for an solution. Wich was found here on this site. Thank you

Your article is very intersting and I want to have periodicaly something like this, if possible (for all microsoft's products).

This article was great...The section on what the MS KB doesn't tell you was particularlly useful to me. Additionally I have a question that I think others would be interested in regarding the MS KB article 324059 - XFOR It states Important Do not include the range of address that include the Exchange server. If you add the range that includes the server as a member, you may make the server an open relay. (Adding it to the list of "Hosts and Clients that can route mail") Why is it that including the hosts own IP address would cause it to be an open relay?

Great artical. Did the tests, but for some reason exchange will accept the % as the @ and let the mail pass .. will it work or is it a glitch? Cheers Josh

I have this setup. I got those test messages. BUT. I am using Sawmill to look at the logs... they indicate that in the morning prior to any office workers get logged in, that for example adv@check-buy.com is the number one ORIGINATOR of messages???? 16 this morning. is the number one for the month of Feb. NOW IS MY EXCHANGE SERVER BEING USED AS A RELAY AGENT OR NOT?????????

This is a very interesting & straight to the point article, that gives useful info into the relay & do not relay issue that can be a nightmare for Mail admins. The wording is simple to understand, and the issues contained are of great help. Thanks

This article was very informative and led me to exactly what my problem was. exchange is quite counter intuitive.

It was very helpful, I save a lot of time doing this. Even a certified professional from Microsoft could'n fix this. The problem is that I still have some relay problems with wildcards. It is correct that I can't stop all relay? Thanks.

can this article be applied to exchange 2003 on 2003 server??? thank you rgds arthur

How would you prevent an attacker from connecting externally to your mailserver and sending a mail from your own domain to the employees of your company?: f.ex. telnet mailserver xxx 25 mail from: ceo@trusteddomain rcpt to: pooremployee@trusteddomain data: you are fired!! . .

Hi I am a bit lost and confused. First of all I have two email ids - one provided by my ISP and the other is the alias of the ISP email address. When I type my work email in the Email Address section (under options -> Email Account -> Email address) my emials are tagged as spam (message was added by a relay) but my emails ar enot tagged as spam if I have the email adress as provided by the ISP. Eventhough I have my work email id in the REPLY to section my email id gets displayed as the ISP email address. The people I deal with know me as the work email id. I don't want to confuse them. I would appreciate your help in this matter. Thanks in advance :) Regards Jaishree Jaishree Ravindran Email - jaishree@graffiti.net

Thank you a lot! I had this issue for a long time, but my previous attempts to fix it failed for no reasons. Shortly after I followed the procedure, I found thi in the log file: Refused to relay for 218.17.90.201 (218.17.90.201). I take it as a good sign

Thanks guys, my exchange 5.5 server is finally blocking relaying, not just saying in the routing tab that it is.

Your article is educative and real good. Now, give me some tips on how I can secure my relay through my ISP

Like all the other articles I have found online, your setup only tells how to deal with internal setups and telnetting into the server. Telnetting is blocked and I have many clients that use Outlook Express at home via POP3. So how do I make the changes to secure the system and lock it down without blocking them out? I have full masks in the "Never Route Mail" set to 0.0.0.0 which should block out everyone but it doesn't Can anyone help? Exchange 5.5 sp4 with multiple patches and fixes.

For Exchange 2003 no trick is needed, just read this great article: http://support.microsoft.com/default.aspx?scid=kb;en-us;823866

Please can somebody point me to a link that refers to the fix for Exchange 2000?

This article was very informative. I stumbled upon it and I am so glad that I did.

i have configured all of the above but when ever i leave the reroute option open over the past seven days i keep geeting block in que and out bound que with some body trying to advertise vigra i have spoekn to microsoft they had no idea at what it is the cause of the problem unti virues companies had no idea's so i am just very confused please help and now our ip is blocked ip addres 195.147.205.194 we are not open relay never ben but never the less we did suffer this attack any ideas

Hi shiraz shah hre i couldnt send & receive email from outside world (internet)but i can send & receive email in intranet ..... there is one proxy server with public ip address (cable line internet connection)its distributing into lan through natting NAT .... there is also a dail up connection .................. how could i send & receive email directly to any .com r .net...............plz b quick i hve less time.......... also there is a problem with logon authentication from remote computer..........when the user wants to connect outlook express directly .....when he r she want to acces outlook express by typing ip address of MS Exchange servers .............but it is not showing the logon authentication dailog box......... so i want to appear the logon authentication to the user when the user types the ip address in the internet explorer................so bquick

HOW TO: Prevent Exchange 2000 from Being Used as a Mail Relay in Windows 2000 http://support.microsoft.com/default.aspx?scid=kb;en-us;q310380

I've corrected my relaying with the said intructions here, but why is it that when I go to www.dnsreport.com it still says that I fail in the open relay test.

Y'all may wish to prevent Exchange 5.5 from Reverse NDR attacks/relaying too... Update available in Exchange Server 5.5 to control whether the Internet Mail Service suppresses or delivers NDRs http://support.microsoft.com/?kbid=837794

What is the most recent SP for Exchange 2000 (running on a Win2k Server)? Someone is relaying off of my server and I can't find it. I pass most tests but in a 19-test system I failed 3 of them. Thanks~