SMTP Problem - Emails stuck in Queue

Just want to thank the experts in advance:

I have 2 web servers running Windows Server 2003 Web Edition that are load balanced. They are on a DMZ along with another server, connected to a Cisco PIX firewall. On the web servers, I have the other server as the SMTP Smart host, so when my ASP pages send an email, the SMTP server is routed to the Smart host, which then routes the message to an Exchange Server on an internal subnet. One of the web servers works fine. It’s just the one that I recently installed Windows Updates. Ever since then every time I send an email, it gets stuck in the mailroot\Queue folder.

I was getting this System event log error: Message delivery to the remote domain 'stroman.com' failed for the following reason: The connection was dropped by the remote host.

This is my troubleshooting so far, but still no luck:
1. Restarted IIS
2. Uninstalled SMTP Windows Update (KB885881)
3. Reinstalled IIS
4. Uninstalled Lan Gaurd Network Security scanner (After I did this I no longer got the System event error mentioned above)
5. Followed this http://www.experts-exchange.com/Web/..._20794824.html article and performed the troubleshooting defined in there. This guy is having the same problem almost exactly. However, his case was basically unresolved. I used telnet to send an email message, which the SMTP server didn't relay to the smart host. I also enabled SMTP logging, if anyone knows how to read it.

Any help or ideas would be greatly, greatly appreciated. Thanks again.

Bryan Moore
Webmaster

Try an SMTP tool from your web server and point it at the server actually sending the SMTP message and see if it will relay it for you to eliminate the possibility of the host not getting the messaage. That is all that I can think of.

Can you talk to the internal mail server, (Exchange), from the sending server, (not the generating server), by domain name.... It may be a firewall or a DNS resolution issue since the internal DNS name of the server should not be resolvable from the DMZ or you risk leaking information to the public network.

Quote:

---

I was getting this System event log error: Message delivery to the remote domain 'stroman.com' failed for the following reason: The connection was dropped by the remote host.

---

Have you looked at the SMTP log on the receiving server to find the reason for rejection?

Thanks guys for your replies.

Tiger Shark, I can ping my internal Exchange server from the server that I'm relaying the email too, but not from the generating server. That's supposed to be that way.

Fraggin, I did as you suggested and installed an SMTP tool on my web server, but the DNS address lookup failed. This is because the only server that can contact a DNS server on my DMZ is the server set as the smart host.

Shakeshuck, do you mean to look at the System Event logs for SMTP errors or the Logs from SMTP logging?

Bryan Moore

mooreb:

Ok, let me start by making sure I have this right....

Two servers in the DMZ - one is a web server with .asp's that generate emails to pass the information gleaned to an internal address. In order to do that there is a second server in the DMZ that is a mail server for the purpose of receiving the .asp generated emails and forwarding, (relaying), them inbound to the trusted network to an exchange server.

Your problem is that the .asp generates the email and sends it to the second relaying server. However, when the second server attempts to relay the mail to the internal Exchange server it fails and the emails remain in the queue... right?

Ok... my thoughts....

1. If your DMZ is a true DMZ, (which I doubt - but I'll get to that later), then the first thing that comes to mind is DNS because there should be no way to resolve an internal name to an IP from the DMZ. Thus, if the relay server doesn't have it's own DNS with a fixed entry for the internal mail server or an entry in it's hosts file it will attempt to resolve the domain name for the mail from external servers which will most likely fail. If you are using MS' SMTP server then you need to telll it to act as a smarthost but to forward all mail to the IP address of the internal server.

2. Are you sure you are allowing SMTP traffic from the DMZ to the trusted? Just because you can ping the Exchange server doesn't mean TCP port 25 traffic can get to it. Have you tried to telnet to port 25 on the internal server from the relay server?

Now... I'm assuming that you can ping from the relay server to the internal Exchange server as a matter of course rather than a temporary firewall rule that you put in place in order to test connectivity.... Feel free to yell at me if I am wrong.... ;)

You are misinterpreting or wrongly implementing your DMZ.......

A DMZ is often called a semi-trusted network.... That's BS.... It's your _exposed_ network and, as such, isn't trustable in any way. Thus, just like if you needed no DMZ and only had a trusted network, it should be firewalled from the trusted network as if it were the public network.

The fact you can ping the internal from the DMZ is therefore bad. While you may chose to allow ICMP from the public network to the DMZ resources to prove connectivity, (though there is no good reason and I don't recommend it - it's a source of information leakage), there is no good reason to "prove connectivity" from the DMZ to the internal. You can allow ICMP from the internal to the DMZ and prove that connectivity just fine....

In the situation you have described I would recommend the following:-

1. Block all traffic from the public network inbound to both the DMZ and the internal networks.
2. Allow _only_ HTTP traffic from the public network to the http server in the DMZ only.
3. Deny all traffic except HTTP outbound from the DMZ to the public and limit the HTTP traffic from the HTTP server _only_.
4. Allow _only_ SMTP, (port 25), traffic from the relay server to the exchange server .
5. Block _all_ other traffic from the DMZ to the internal.
6. Allow whatever traffic you need from the internal to the DMZ for management purposes and secure it using IPSec.

Hope this helps

I don't normally work with Web Edition, so I may be all wet here. However, with load balancing and clustering, you have a heartbeat. When we had a similar problem with the clustered exchange servers, our heartbeat was the core. The person who configured the servers used a 192.x.x.x private range, and a 255.0.0.0 mask. Anything going to a 192.x.x.x address hung in the SMTP que and we got similar responses from the remote SMTP servers (connection dropped) when we tried to manually send an email.

Something to check, anyway. The fix, on our part, was to change the IP range and mask to something with a lot less overhead. ;)

EDIT: And, no, it was not me who performed that bonehead configuration on the heartbeat.

TigerShark you are correct about the DMZ configuration, except that I have 2 load balanced web servers, plus the other email gateway. The strange thing is that the emails are sending fine from the other Web server. One more note: the emails remain in the queue on the web server that generates the asp emails.

From my DMZ I can't resolve any host name, but I can ping the Exchange server by its IP. The routing server is acting as the smarthost, which is fowarding mail to the Exchange server. Also, SMTP is being allowed to the internal network from the DMZ, because I can telnet to the internal server from the routing server to send an test email. I also looked at the PIX configuration and I think the reason that I can ping to the internal network from the DMZ is becuase ICMP is being allowed through. Everything else is pretty much locked down as you suggested.

Rapier57 I am using a 255.255.255.0 subnet mask on the DMZ.

Thanks again for all who have replied. I appreciate your help.

Bryan

Quote:

---

Shakeshuck, do you mean to look at the System Event logs for SMTP errors or the Logs from SMTP logging?

---

I'm a UNIX dude myself, so I'm afraid I can only post generic help; I can't be specific as far as MS s/w is concerned.
The fact that "The connection was dropped by the remote host." appears in the System Event log suggests to me (although someone else here may correct me) that there should be a corresponding message in the SE log on the receiving server.

I agree with Tiger. Forwarding should be disallowed if the message comes from an unknown host or domain, so if you can't resolve the 'from' server it will (and should) be rejected. Is there a manual method under MS where you specify the hosts/domains that you are allowed to relay?

mooreb - Can you telnet to the SMTP relay server from the web server? That would be telnet xxx.xxx.xxx.xxx 25? In SMTP properties on the delivery tab press the Advanced button - what is the smarthost, IP or name?

Also - What SMTP relay are you using?

String, I can telnet to the SMTP relay server from the web server. The smarthost should be set correctly ([xxx.xxx.xxx.xxx]) because it's the same for the web server that is working fine.

Thanks!

Thank you everyone for your help, but now the web server appears to be sending the emails. I'm not sure what caused it to stop working initially but, the Symantec antivirus software that I installed while troubleshooting a few days earlier, had the emails in the mailroot\queue folder locked. Once I disabled the anti-virus service and restarted the SMTP service it began working.