From - Mon Jun 22 15:43:01 2009
X-Account-Key: account6
X-UIDL: UID52-1242085352
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Received: (qmail 11994 invoked from network); 22 Jun 2009 15:42:58 -0700
Received: from smtpauth01.prod.mesa1.secureserver.net (64.202.165.181)
by ip-97-74-114-123.ip.secureserver.net with SMTP; 22 Jun 2009 15:42:58 -0700
Received: (qmail 12509 invoked from network); 22 Jun 2009 22:42:57 -0000
Received: from unknown (172.21.44.241)
by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with ESMTP; 22 Jun 2009 22:42:57 -0000
Message-ID: <4A4008F1.8020205@desertwebdesigns.com>
Date: Mon, 22 Jun 2009 15:42:57 -0700
From: Mark Stoecker <webmaster@desertwebdesigns.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: admin@poundbangwhack.com
Subject: Test Email
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

When troubleshooting email delays, the first thing you want to do is get all your times in the same time zone. Some servers will timestamp based on their current time, some will timestamp based on GMT. It will be easier to read if they are all the same timezone. In the example above, there are 6 timestamps we need to be concerned with, 2 of which are in GMT.

After getting all your times sorted out, the next thing you want to do is follow the delivery path (from bottom to top). Each server that the message passes through will stamp it. The tricky thing about reading the Received: lines is that they list first the sender, then the recipient: Received: from smtpauth01.prod.mesa1.secureserver.net (64.202.165.181)
by ip-97-74-114-123.ip.secureserver.net with SMTP; 22 Jun 2009 15:42:58 -0700 As you can see here, the message was received from smtpauth01.prod.mesa1.secureserver.net by ip-97-74-114-123.ip.secureserver.net. If this gets confusing, just rearrange it to make it easier: Received by ip-97-74-114-123.ip.secureserver.net from smtpauth01.prod.mesa1.secureserver.net Now it makes a bit more sense.

So if we were to take the critical delivery points in the chain, fix the timestamps, rearrange the delivery notices, and re-order the server stamps so it reads top-to-bottom like we do, our headers would read something like this:Date: Mon, 22 Jun 2009 15:42:57 -0700
Received: by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) from unknown (172.21.44.241) with ESMTP @ 22 Jun 2009 15:42:57 -0700
Received: (qmail 12509 invoked from network) @ 22 Jun 2009 15:42:57 -0700
Received: by ip-97-74-114-123.ip.secureserver.net from smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with SMTP @ 22 Jun 2009 15:42:58 -0700
Received: (qmail 11994 invoked from network) @ 22 Jun 2009 15:42:58 -0700
From - Mon Jun 22 15:43:01 2009 If you compare the two “headers” carefully, you will see that all I did was change the timestamps to MST, swap the “Received From” and “Received By”, and ordered them top-to-bottom instead of bottom-to-top. Looking at the headers now, there was obviously no delay in this message. However, had one of the timestamps been off by 30-40+ minutes, looking at the headers this way will help us determine where the delay is. We would know that when the message came in late at one step, the server it came from is having the problem.

There are plenty of other uses for reviewing mail headers that are too numerous to count in this post. However, if you’re email is not delivering in a timely manner, this will help you track down the cause. Once you get the hang of reading email headers, you’ll be able to read them as they’re printed without having to rewrite them.

I had initially posted instructions on how to change the default Qmail port. However, an associate of mine pointed out the fallacy in my instructions. Changing the default Qmail port will prevent email from being delivered to your server as foreign mail servers will try to connect to your server on port 25 and if you change it, you won’t be able to receive email. I completely forgot about that little side effect when I posted this and have thus changed this post to only show how to configure an alternate port for Qmail.

A couple days ago I wrote about how to troubleshoot an email server when it isn’t working. This post isn’t necessarily follow-up to that, but more of a corollary. One of the things I didn’t mention in that post is what to do if you are running an email server and your ISP does not allow outgoing connections over port 25, the standard SMTP port. Many ISP’s have this policy to cust down on Spam sent through their servers, mine included. So when I tried to connect to my email the other day through Mozilla Thunderbird, I ran into a problem. I knew what I had to do. I had to configure Qmail to use an alternate port.

The first thing you will need to do is locate the service script for your email service. In my case, since I use Qmail with Plesk, my script was located at /etc/xinetd.d/smtp_psa. You will most likely have another one for SMTP over SSL named smtps_psa (or something close to). Next, you need to see what ports your server is currently listening on so you do not assign it to the same port as another service and cause problems. To do that, run the following command
netstat -tulpn | grep tcp That will show all current running services, the port their using, and filter out TCP only (so as not to see duplicate ports in the UDP section. You will be concerned with the column labeled “Local Address” as that will show the IP (0:0:0:0 or ::: means all IPs) and the port in use. Pick a random port number not in use for your SMTP configuration. I chose 2525.

How to configure Qmail to use an alternate port

To configure an alternate qmail port, you will need to first copy the default smtp service file to create an alternate configuration. I did this with the following code cp /etc/xinetd.d/smtp_psa /etc/xinetd.d/smtp_alt_psa You will then need to open your alternate service file and configure the alternate service name. Using a text editor of your choice (I like vi), type vi /etc/xinetd.d/smtp_alt_psa The first line should look something like service smtp That line will need to be changed so we don’t have two services with the same name. Hit i to enter insert mode and change the first line to read service smtp_alt Hit Esc, type :wq to write and quit.

We now need to edit the /etc/services file to set the port. Make sure the service name you use matches the service name you entered in the alternate configuration file above. I added these lines right below the original SMTP lines. Hit i again for insert mode and write in the two following lines smtp_alt 2525/tcp mail
smtp_alt 2525/udp mail Your /etc/services file should look something like this smtp 25/tcp mail
smtp 25/udp mail
smtp_alt 2525/tcp mail
smtp_alt 2525/udp mail Hit Esc, type :wq to write and quit. Now restart your email service. Again, here was my code to do that service xinetd restart Run the netstat -tulpn | grep tcp command again to verify that your email service is now listening on port 25 and 2525.

That’s all there is to it. You should now be able to connect through your email client to your server on your alternate port. Questions? Comments? Problems? Post them below and I’ll do my best to help out.

For more help on using the vi/vim text editor, visit our Linux command line cheat sheet with extensive information on using vi.

We’ve all ran into those problems where all of our sudden, we can’t send email and we don’t know why, and don’t know what to do, besides call our email provider. One thing I’ve been focusing on at work lately is empowering our customers to “take ownership” of their servers, to help them figure things out on their own. The way I put it, being a server administrator is like getting married; “through good times and bad.” The problem is most administrators (or wannabe administrators) only want to be the admin when the server is running. Once there’s a problem, they expect us to be the admin. Sorry folks, but that’s not how it works.

Troubleshooting Email Issues

By and large, the biggest problem I see day in and day out is email related. Now granted, their are plenty of legitimate issues, things like getting flagged by a relay server’s spam filter or the relay server not accepting communications from a server. Those aren’t things a customer can do anything about. However, it is my firm belief that if you have a problem, you probably aren’t the first person in the world who’s had that problem. If you are, lucky you…and that sucks. Throw the error message (or description of the problem) into google and see what you come up with. The answer is often on the first page. Spend 10 minutes looking for a solution in google, and you’ll probably find it. But most people would rather send in a ticket and wait 2, 3, 4, or more hours for us to fix it, or tell them how to fix it.

So how can you tell if your email is really broken or not? Let me first say this guide is for people who use a hosted email service, not a free email service like Hotmail, Yahoo Mail, or Gmail. It may not even work if you are using a shared mail server through a large email provider. This will work best for you if you are using a virtual dedicated (virtual private) or dedicated (private) server that utilizes it’s own mail service independent of other users.

Remove all variables from the equation

Let’s say you can’t send your email out through Thunderbird (or Outlook if you choose to go that route). Regardless of the error you’re getting, try your webmail first. If it works through webmail, this will tell you if your mail service is at least working. Your webmail is going to use the same SMTP service that your mail client will. Chances are if you can send through webmail, the problem is local, either with your mail client configuration, or your ISP. If this is the case call your ISP. Many ISP’s will block outgoing communications on port 25, the standard SMTP port. This was the case with my ISP so I had to configure my Qmail to use an alternate port (but that’s another post – look online for the time being). Assuming all your settings are correct in your mail client (you’d be surprised how often this is the problem), we know it’s not a local issue. So you can’t send at all. Is it your local server? Or does your provider make you go through a relay server and that’s the problem? The best tool to troubleshoot your email is telnet.

Sending email through telnet

The first surefire way to test your email is by sending email through a telnet to localhost. This means connecting to your server either via SSH for Linux or Remote Desktop for Windows. If you are using Windows, open a command prompt first. At that point, the process is the same for Linux or Windows. Now, a few people will try this on their own, but often fail. The reason is that their email headers are not RFC compliant. Here is how to send a test email through telnet. Note: Your output may not be exactly the same as below. The bold code is the end user input, the italicized code is variable input/output.
telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 servername ESMTP
HELO localhost
250 servername
MAIL FROM: email address on your server
250 ok
RCPT TO: email address your sending to (off your server)
250 ok
DATA
354 go ahead
from: from address
to: to address
subject: any subject
body of message

.

250 ok 1244530643 qp 9552

A few notes, the data entry should be in the specific order above. There should be an empty line before and after the body of your message. End your message with a period to send it. The 250 ok line at the end means that the message was entered into your local mail queue. Check your from address for a bouceback message. No bounceback message means the message delivered ok.

Was the message accepted or did you get a bounceback?

If the message comes back, the second surefire way to test your email is by sending email through a telnet to your relay server. The process is the exact same as above, however replace localhost with your relay server’s name and follow the same steps. If the message is not accepted, contact your hosting provider. If it is accepted, check your from address for a bounceback message.

Either way, if you get a bounceback message, the first thing you should do is look at the bounceback error code. The error code will tell you the problem. Take that error code and put it into a search engine for additional information. You most common codes will be 553 or 554 (more on these in another post).

The bottom line is, test your email server through telnet first before assuming there’s a problem. Telnet will connect directly to the server on the specified port and will eliminate all external factors in troubleshooting the issue. Email issues are not as complicated to troubleshoot as most people believe. They just take a bit of time and patience.