Ant Drewery

There are situations where you may want to manually test SMTP connectivity. Some of the common ones for me are:

• When messages are queuing for delivery to or being rejected from a particular domain.
• When I have an application that uses SMTP for notifications but none are being sent.
• Running a basic open relay test.

In the case of queued/rejected messages I’ll first check the MX records for the problem domain via www.dnsstuff.com. For small companies you often see the primary MX record pointing to their server and a secondary record pointing to their ISP. It’s been my experience that the ISP’s mail server is often not configured to store and forward for the domain and instead rejects the message as a relay attempt. This becomes an issue when the primary MX record is unavailable (perhaps the company’s server or Internet connection is down).

So here’s my troubleshooting process in detail:

• Check the MX records for the problem domain via www.dnsstuff.com.
• From the mail server that connects to the destination server (in our case a MailSweeper box) open a command prompt.
• Type telnet mailhost 25 (Mailhost is the host name found in the MX record e.g. myserver.mydomain.com)
• If the mailhost is available you should get a response similar to “220 mydomain.com” followed by some text that identifies the email server software. It is also possible that you get a simpler response designed not to give away any information to potential hackers. If you telnet to my company’s external mail servers you’ll simply get “220 SMTP Relay”.
• If the connection fails you may want to take some additional troubleshooting steps like verifying that the mailhost resolves to an IP address. If you still cannot connect then try the next MX record in order of priority as this is what your mail server would do.
• Once you get a response you need to say hello by typing helo.
• The receiving server should respond with “250 mydomain.com yourIPaddress” or something similar.
• Now you have to simulate sending a message from your domain. To do this first type mail from:youremailaddress e.g. mail from:ant@mycompany.com.
• You should see a response similar to “250 Sender OK”. If you get a rejection it will hopefully give you some additional information to identify why.
• Now enter the destination email address by typing rcpt to:destinationemailaddress.
• You should get a response like “250 desinationemailaddress” although this is often the point where you’ll get an “unable to relay” message if there’s a configuration issue or if you are genuinely trying to relay a message through a closed server.
• Next we need to enter the subject and body text so type the command data which should respond with something like “354 Start mail input; end with .”
• To add a subject you need to type Subject:my_subject_text followed by a carriage return.
• You can then type the body text. When you are finished start a new line type a full stop then hit return.
• You’ll see something like “250 message queued for delivery”.

Following this process through allows me to see at which point it fails and hopefully to obtain a clue as to why.

If I’m troubleshooting an application that should be sending SMTP notifications I would run the commands on the same box as the application and telnet to the SMTP server used in the application settings.

If I’m testing one of my boxes to ensure it’s not an open relay I would telnet to it but use an external email address for both the From address and the To address. I would expect to see a rejection after the RCPT TO: command.

Technorati Tags: Exchange, SMTP, telnet

It’s official, I hate RBLs. For sometime I’ve tolerated and indeed used well run and respected lists like SURBL but then SURBL works differently to the rest. SURBL does not block listed hosts but rather allows you to block messages based on the URIs that they contain. It works well in conjunction with our MailSweeper servers.

The main problem with these types of service is that no one governs them. I could set one up tomorrow and list whoever I liked. Of course, you’d have to chose to use my list with your systems.

Most of these services make it fairly painless to be removed so although inconvenient it’s not the end of the world if you are listed in error, and indeed if you are an open relay then it can be a justified kick up the backside. However, there are some real cowboys out there.

Today we’ve found one of our gateways listed with such a cowboy http://www.us.sorbs.net/. I’ve scanned the box for Trojans and viruses with 2 different products and have thrown every relay test I know against it. Nada. So how did it get listed? SORBS claim that our box sent an email (not a spam, just a regular email) to one of its honey trap addresses. That’s just plain crazy. It could have been an NDR or virus notification in response to a message that spoofed the SORBS address. To make things worse SORBS want a fine to have our box de-listed. This fine is in the form of a donation which I guess gets them round any extortion charges. What a joke.

I’m even more shocked to find a company like Vodafone uses this list as part of their anti-spam measures. Their admins should be shot.

That’s my rant over for now. I need to get back to getting de-listed.

If you have a small to medium sized Exchange environment the chances are you’ll have a single point for inbound email and your MX records will look something like this:

MX 10 smtp.mydomain.com
MX 20 smtp.myisp.com

Your primary inbound point would be your Internet connection and your secondary is often your ISP who provides a store and forward service if your server or Internet connection is unavailable.

If you have a larger environment you may have more than one mail gateway (we have 2 in the US, 2 in the UK and 1 in Australia) and might want to load balance inbound email between them. There are two possible ways to achieve this.

The first method is to use a concept called DNS round-robin. Here you would create A records for your gateways each with it’s own IP address but using the same name. For example:

A smtp.mydomain.com 212.111.212.111
A smtp.mydomain.com 212.111.212.112
A smtp.mydomain.com 212.111.212.113
A smtp.mydomain.com 212.111.212.114

(I made the IP addresses up)

The MX record would then be:

MX 10 smtp.mydomain.com

The second method is to give all the MX records for your gateways the same value. You would have individual A records and your MX records would look like this:

MX 10 smtp1.mydomain.com
MX 10 smtp2.mydomain.com
MX 10 smtp3.mydomain.com
MX 10 smtp4.mydomain.com

Whilst none of these methods will give you 100% perfect load-balancing they are effective in distributing the load between gateways. We have also experimented with Windows Network Load Balancing but have found that it doesn’t play well in our Cisco routed environment. From the Microsoft document “Network Load Balancing : Configuration Best Practices for Windows 2000 and Windows Server 2003″:

Some routers require a static ARP entry because they do not support the resolution of unicast IP addresses to multicast media access control addresses. For example, Cisco routers require an ARP (address resolution protocol) entry for every virtual IP address. While Network Load Balancing uses Level 2 Multicast for the delivery of packets, Cisco’s interpretation of the RFCs is that Multicast is for IP Multicast. So, when the router doesn’t see a Multicast IP address, it does not automatically create an ARP entry, and one has to manually have to add it on the router.