Ant Drewery » Mailsweeper

Using Telnet to troubleshoot SMTP connectivity

Anthony Drewery — Fri, 10 Mar 2006 09:12:44 +0000

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.

[tags]Exchange, SMTP, telnet[/tags]

Customise Exchange 2003 NDRs?

Anthony Drewery — Tue, 21 Feb 2006 13:59:02 +0000

I was asked today if it’s possible to customise the text in the non-delivery reports that Exchange 2003 sends. To the best of my knowledge this can’t be done if you are just using Exchange. However, if you run a product like MailSweeper you could intercept outbound NDRs that match a particular criteria then modify the content before allowing to be delivered. That’s how I would tackle it if we had the requirement in our organisation.
[tags]Exchange, NDR, Mailsweeper[/tags]

Real-time Black Lists

Anthony Drewery — Tue, 13 Dec 2005 16:09:06 +0000

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.

Layers of defence

Anthony Drewery — Wed, 23 Nov 2005 12:17:38 +0000

Due to the critical nature of our email usage a major virus outbreak on our Exchange servers would probably cost me my job. So to help me sleep easier at night I use layers of defence. We run one anti-virus product on our MailSweeper gateway servers and a product from a different vendor on all of our internal Exchange servers. The concept of using different products is if one vendor doesn’t have a definition available to detect a certain virus the other vendor might. This layered approach gives us a fighting chance if a virus gets past MailSweeper or hits us from the inside via a webmail service.

As additional precaution we set the automatic definition updates to be as frequent as possible and also block any executable attachments (internal & external).

Increase in virus traffic

Anthony Drewery — Wed, 23 Nov 2005 12:00:54 +0000

We saw a sharp increase in the amount of viruses caught by our MailSweeper servers yesterday, double the usual volume. Here are the top 10 viruses that we’ve caught so far this month:

1 – W32/NetSky.P@mm
2 – Email-Worm.Win32.NetSky.q
3 – Exploit.HTML.Iframe.FileDownload
4 – Email-Worm.Win32.Sober.y
5 – HTML/IFrame@expl(exact)
6 – Net-Worm.Win32.Mytob.cg
7 – Net-Worm.Win32.Mytob.c
8 – Trojan-Spy.HTML.Bayfraud.hn
9 – Email-Worm.Win32.NetSky.r
10 – Net-Worm.Win32.Mytob.ab