SMTP server cannot email outside LAN

Question

There are a lot of variables in my question, so I'll try to be as concise as possible:

Objective: To setup a local SMTP server for our other servers to connect to a local IP address to mail out. We're moving to Google Apps email, and smtp.gmail.com won't work for us for the applications we're running.

Progress so far: Followed these instructions to setup a Windows Server 2008 x64 to run SMTP. SMTP is setup to allow all connections from anyone, and relay restrictions are set to allow all IPs to relay through it, with anonymous access (I'll play with tightening down security later, not sure how it will affect our applications). This server does NOT have MX records setup for our domain, as they have been setup for our new domain to Google. Our old mail server (Groupwise) is still running on our network, with our old domain's MX records pointing to it. All traffic that is going out of our network is not blocked by our firewall, traffic coming in to the network to the SMTP server I setup is blocked on all ports, but that can easily be changed. I also have access to several public static IPs I can use.

Problems: When sending an email using telnet to test, it works to our internal mail server on our old domain (my feeling is that it never leaves our LAN and goes out to the internet, so obviously it works). When I try to email outside our domain to, say, Gmail or Yahoo email address, I get the following error in event logs: "Message delivery to the host '67.195.168.31' failed while delivering to the remote domain 'yahoo.com' for the following reason: The remote server did not respond to a connection attempt." The emails show up in C:\inetpub\mailroot\Queue, but they are stuck there and never go anywhere. I turned on SMTP logging, and there are absolutely no messages in there that are related to the emails I'm trying to send out to Gmail/Yahoo, although ones to our internal domain/mail server do.

Questions:

1. Do I have to setup an MX record for our domain in order to run an SMTP server--all this is for is just emailing out? (My mom always told me there are no such things as stupid questions, although I'm wondering about this one....)
2. Do I have to open up port 25 to the outside world on an specific static IP for SMTP to work (or, perhaps to word it differently, is SMTP more than just a one-way street)?
3. Perhaps I'm not even asking the right questions. All I'm trying to do is setup a simple SMTP server to just shoot emails out, with no authentication if possible (because of the way our applications work). Am I on the right track?

Solution 1

Sounds like the remote side of the SMTP conversation is not even allowing a connection. To me that sounds like your firewall isn't allowing TCP/25 out of the network for the IP address of your new SMTP server, or possibly the remote SMTP server is blocking your connection for some reason. You'd get a different error message if the problem happened during SMTP negotiation.

If it's your firewall doing the blocking, not an uncommon step to prevent botnets from using corporate networks as spam-farms, then set an exception for your server.

If it is the remote side doing the blocking, that gets trickier. A lot of the fancier anti-spam systems use IP reputation systems as their first step in blocking spam. If your IP is on one of those lists (and it may not show up on any of the RBL checks, since private companies now manage their own rep lists), getting it off can be a major pain.

Solution 2

1. MX records are only required for incoming mail. For outgoing email you need an A record for the external IP address (outgoing from the firewall/NAT), and should have a corresponding PTR record pointing to it. You mail server should identify itself using the name on the A record.

2. You need the firewall open for connections to port 25. Some sites may try connecting back, but they should use your existing MX record to locate the server to connect to. Try using telnet from your mail server to port 25 on the host you have problems with.

3. You are likely not on the right track.

Try configuring your SMTP server to send all your email via your Groupwise server or your ISP's server. This will resolve any number of problems as you should not have the authentication hoops you would otherwise have. If you do so, you can skip the following.

Make sure that both your domain and IP address can be resolved via DNS. I have been blocking a lot of spam based on lack of DNS servers for either the IP address or the corresponding domain lately.

Check to see if you have SPF defined for your domain. If so, you may be blocking yourself.

Check to see if your address is on any blacklists. Spamhaus is heavily used and trusted and easy to get off of in many cases.

Comments

[Matt]

Thank you so much....I was thinking it might be a firewall issue as well--although there was no way it was our main firewall since it allows all traffic out. Turns out, our content filter (required because I work for a school district) was configured to drop everything from TCP/25 except for our old mail server and the content filter box itself, which made it very confusing to troubleshoot. But all solved now--just added my SMTP server to the allowed list and we're good to go. Probably will configure our firewall to handle the blocking of TCP/25 traffic for simplicity but that's another day.

[Matt]

Hm, guess I can't mark two answers as 'correct'. Thank you very much for your very clear explanation--I learned a lot today about SMTP and mail traffic :)

[Matt]

Thank you for your answer...it didn't really occur to me to try to telnet to the other servers it was trying to connect to--but once I did it was a big 'duh'. That really helped narrow down the issue.