FSL Company Blog

By far the most common tech support call we get concerns a missing email.  And the most common solution is that it went missing because of a badly configured server that sent the email. In fact the sender's server and not a server that is using our BarricadeMX products cause most of the delivery problems we see. We get these support calls because tracking email delivery can be a confusing and complicated process.

Finding an email problem can be simplified if you follow some basic procedures and learn a few new skills. Unfortunately there is not much information available that presents how to track emails in a logical and detailed manner. To help fill in this gap, this first article will outline the process that should be followed to track an email delivery. Future blog articles will provide details of the steps that you will need use to find and understand the exact path the message followed and what eventually happened to the message.

Some background of how email evolved is a good place to start and a short history of the origin of email is available from Wikipedia. It's also important to understand the rules actually govern and control the transmission of email on the Internet. These rules are contained primarily in two RFCs,  RFC 2822, "Internet Message Format Internet Message Format", and RFC 2821, "Simple Mail Transfer Protocol". While it's not necessary to study these documents in detail to track an email, both are clearly written, understandable documents which should be read by anyone who wants to have good understanding of how email works and why it fails.

But before we begin a few important facts to remember about email.

• Email is a convenient way to communicate; it is not a guaranteed delivery process. If a business critical message absolutely, positively must be delivered, do NOT depend on email.

• Despite what Outlook may tell you, there is no way to know or even find out if a message was actually read by the intended recipient.

• If servers are configured in conformance with the RFCs that govern email delivery, no email message should ever "disappear". You should, in most cases, be able to track almost any and all email messages.

The first step in solving any problem is assembling the knowledge necessary to analyze the problem and obtain the facts that will be needed find a solution. I can't tell you how many times we get this the following technical support request, or some close variation of it:

"My customer says that he (or she) is missing very important emails. Please check this out immediately and let us know what the problem is" - followed by several exclamation marks.

To start tracking an email you need at least, the To: address (a sender), the From: address (a recipient) and the approximate Time and Date of the delivery. Obviously without at least this information there is nothing you can do to track email delivery and often, even more information may be needed to find what happened to the missing message.

The referenced Email Tracking Process diagram outlines the steps necessary to find out what happened to a message during the email delivery process. Simply following the processes shown in this diagram should enable you to find out exactly what happened to any message.

Step one is to determine if the sender of the message received a Non-Delivery receipt (NDR) when the message was not delivered. If they received a NDR, simply have them forward the NDR message intact (no snipping please!) to your support team at your "backup internal mail address". A backup internal email address is an address that will be delivered to your support team without passing through any type of anti-spam or anti-virus processing at on the email gateway. Anti-virus processing may still be used on the message at the Mail hub and Desktop levels as long as you can track a message that is trapped by such software. The NDR should always contain the name of the server that rejected the message, an error code, an explanation of the error code and time and date of the rejection.

Armed with this information you may be able to solve the non-delivery problem by simply analyzing the information contained in the NDR.  Often you'll find the server that rejected the email was not even part of your email system.  If this is the case, the sender's postmaster must solve the delivery problem, since the message is not even reaching your gateway. If the reporting server is one of your gateways, you may be able to determine what caused the problem simply by reading the explanation of the error code. If not, the NDR will contain a message ID that will allow you to find the message in your server's mail log. If, after finding the message in the mail log, you still find the explanation is confusing, you can simply "Google" the explanation or error code, contact support@fsl.com or wait until I publish the article on Understanding Mail Logs.

If the sender did not receive an NDR, you should start by searching the mail logs for any entries that contain the senders' email address or domain. You can speed up the search by limiting the date and time of the search to the approximate date and time the delivery should have been attempted. The detailed process for searching these logs will be the topic of a future article but if you are using our BarricadeMX or BarricadeMX Plus software you already have a web interface that allows you to search these logs. 

If you find entries in the mail logs that are related to the missing message you should skip to the Analyze Logged Errors step on the Email Tracking Process diagram. If you do not find any related log entries, one of two things must have happened. Either the sending Mail Transfer Agent  (MTA) program never connected to your gateways or the email was sent by a server whose IP address did not resolve to a hostname in the sender's domain.

At this point you can go no further until you have more information. What you need to find out is the IP address or hostname of the sending MTA. Mail for many domains is often sent by a third party service.  These services deliver mail for the sender's domain using a server with a hostname that's not in the sender's domain. If this appears to be the case you should try to find out if the sender's domain publishes SPF records. If they do, you can look up the SPF record and then check the mail logs for any IP addresses, Hostnames or Domain name that are included in the domain's SPF records.

If these steps fails to provide a match in the mail logs, looking up the names and IP addresses of the MX servers for the sender's domain and then search the logs for any IP addresses, Hostnames or Domain name that are included in the domain's MX records.

If any of these steps succeed, you can skip to the Analyze Log Errors task on the Email Tracking Process diagram. If none of these steps succeed you must find out one of the possible IP addresses and hostnames of the sender's MTA to proceed further. If possible, have the sender resend the message to your "backup internal mail address"

 and to your "backup external email address". A backup external email address is an externally hosted email address that can be read by or forwarded to your support team.  This address can be used to communicate with the outside if your email gateways or mail hubs are down. It may also be used to check the deliverability of problem emails by testing delivery of such messages to an outside, "neutral" account.

If neither of the resent emails is delivered, the chances are that the sending server has a configuration problem that prevents it from delivering email to many typical email servers. Your only recourse at this point is to have the sender contact their postmaster and have them track the non-delivery problem from the sender's end. There in nothing else you can try from you side of the transaction.

If either of the messages is received, you should be able to examine the full headers of the message and determine the hostname and IP address of the server that sent the message that. You can then skip to Check Log For IP / Hostname in the Email Tracking Process diagram.

 If you find now find the message in the logs you should be able to determine what caused the tracking problem. If you still find the explanation is not descriptive enough, you can either "Google" the explanation or error code, contact support@fsl.com or read the next article on working with mail logs.

And hopefully that's enough email tracking to digest for this week. Check in next week for an explanation of how DNS and Email work together. Other future topics will include:

• When Email leaves your domain
• Then SMTP conversation (Gateways to Gateway)
• When Mail Enters Your Domain
• Email Log Structure
• Searching Logs
• Understanding Logs
• The Email Tracking Process, a Summary

 Steve Swaney

CEO Fort Systems Limited

steve@fsl.com