IT Employment

Ask something
Discussion Locked

Exchange 5.5 Relay Issues

0 helpful
4 replies

by jwilson

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
Have done all of the requisite blocking on the routing tab of the Exchange 5.5 IMC. Have had users change passwords, but with logging on, I can still see conections being made to my Exchange server and messages being sent through it. The outgoing queue never stops filling up. The defined methods to stop mail relaying from Microsoft don't seem to be doing the trick. Anyone else having this issue?

4 replies

by av .

You could disable the server from sending automatic replies to the internet through the Internet Mail tab.

I do remember having similar issues with my Exchange server when I found out I was an open relay. At the time, I was running 5.5 with SP2. Shortly thereafter, there was another hot fix for the relay issue or you could move to SP3. After that, I did not relay anymore.

When I applied Microsoft's prescribed method to stop relaying, it did not work immediately. In the routing restrictions, I had to reroute SMTP to my domain name. Then, what I did was go into routing restrictions and check under "Specify hosts and clients that can route mail when the following conditions are met" the following option

Hosts and clients with these IP addresses

I did not specify any IP addresses

This was suggested in the another technet article.

I tested the relay capabilities of the server using a telnet session as suggested in the article. The server responded with 550 relaying prohibited. I think it fixed the problem.

Also, under Internet mail advanced options, I had previously selected to disable out of the office replies and automatic replies to the internet. This did not suppress notification to email senders if they wanted a return receipt. Apparently this was a bug that was fixed by a hot fix (that is also available in service pack 3). We were running service pack 2. I applied the hot fix to the server. It replaced 2 files - msexcimc.exe and imcmsg.dll. I tested it and it corrected the problem.

Hope this helps. Its worth a try.

by lordinfidel

In the IMS Queue, looks something like

destination originator
-------------------------
domain <>

Then you do not have anything to worry about.

<> is MS's way of saying it is the mail server itself. So the mail server is trying to send an NDR to the offending host trying to relay. 9 times out of 10 the offending host (left side of the e-mail address) is fictional.

The one thing I do not like about MS relaying, is that if you sucessfully authenticate with a u/p you can effectively relay thru the server. Which is why you should also use the IP restrictions.

I also turned down my NDR delivery time to like 6 hours.

by av .

how you can relay to any domain through the server if relaying is turned off except to your domain or specified domains? I'm not sure I understand.

I agree about <>. Though we'll never know for sure. Just when you think you know whats going on some new tactic comes along.

by lordinfidel

Defining the domains in the IMS does not specifically restrict what exch will or will not relay.

Basically that area in the IMS is just telling exchange the domains it will accept as Inbound to it's own IS.

As long as you have a valid U/P, you can connect to exchange and relay any domain thru it. This is the biggest flaw I have with exchange, because they (M$) messed that part up. And I am a HUGE supporter and user of exchange.

That is the reason why I advocate not only selecting the must have a valid account, but also restrict who can make connections to it.

They basically based it on IIS's smtp service. If you notice in IIS, it basically has the same things. In IIS there are 3 places you have to restrict relaying instead of just 2 in exchange. With IIS you have to deselect the allow valid u/p's to relay, then you have to restrict who can relay, then you have to restrict who can make a connection.

Relaying is the one area where sendmail and postfix got it right.

This discussion is closed to new replies.