How to track down disappearing email?

Question

I have an email generated by a CMS that goes to two people on different hosts. The person on host A always gets the email. The second, on host B, never does.

The CMS is on the server at host A. The two people can send and receive email to each other without a problem. He's checked his spam filter and they're not there. I tested sending the email to two other hosts without a problem.

There was an issue with the From field being blank but I fixed that and he still doesn't get the email.

What is the best way to get started on tracking down why the guy on host B never gets the email generated from the CMS?

Answer 1

There are many reasons why an email could be blocked or rejected. However email is designed in a way that it shouldn't just disappear. It should be delivered to a mailbox, in a queue, or bounced back to the sender. Both the host A and host B MTA logs should show the attempted delivery and the result of the attempt. I'm assuming that you probably don't have access to the host b MTA logs though. So you'll need to figure out how to trouble shoot this from your side.

Web apps can be a bit tricky though b/c some of them send email using a simple smtp app or library that blindly attempts to deliver an email in a best effort approach. These don't always have queues to deal with delivery issues. Something as simple as grey listing can cause delivery failures with these.

Worst comes to worst you can do a packet capture to see what the conversation looks like between host A and host B. SMTP is sent in clear text so WireShark can easily read the exchange between the servers.

If you have more information on how the CMS tries to send email and what MTA/smtp application it's using someone can probably point you to the log files you should look at. But on Linux /var/log/mail.log is a good place to start.

Answer 2

You are not going to learn anything from a packet capture unless you have a MTA you wrote yourself that needs debugging.

Chances are the problem has something to do with the downstream hosts. What logs do you have access to? Try to look in the maillog of the MTA on the CMS system and any secondary MTA system accessible to you which is used for SMTP relay. Do you get an 250 OK status for delivery of the mail to the remote host B? If so, you have successfully delivered the message. If not, we need more detail on what was the error in your log to tell you more.

The problem can be that the next hop doesn't like your email. It can have bad headers, messed up MIME encoding, etc., which trigger a reject without a bounce because the email is taken to be possibly malicious if it isn't following the relevant RFCs for email format.

If you are getting a "250 OK Sent" type of status on your end, the only thing you can do is have the client at host B talk to their service provider, ISP, or IT department and ask what is happening to their email and why. Only the remote site's logs will tell the story when they are not bouncing the email back to you.

Answer 3

Are you sending mails thru an email server or just an SMTP service? When emails are sent from applications (like your CMS) usual choice for delivering the emails are

1. Email Server on the network (Exchange, others)
2. An SMTP service (IIS SMTP, others)

Here is the catch. If the application (your CMS) is in the same network as an email server, then this is the preferred choice, since the email server is the desiginated post-office for that domain. If on the other hand, the application has no access to relay emails thru a mail server and an SMTP service is used then note the following

If the SMTP will send directly to external users then you need to make sure the IP(public) is cleared from any blacklists, make sure you have correct PTR records are setup for reverse DNS by other mail servers, and for heavens sake turn off relay.

In your case, if the person on HOST A is on the same network as the CMS then he/she will get the mail. If HOST B is on a separate network, perhaps HOST B mails server is doing a reverse lookup and is unable to determine if the SMTP is a legit mail server. You also need to have proper MX setup.

If both users are on the same network, then it could be that the sender (from address e.g. noreply@yourcompany.com) is not allowed to send to that user. Can't you ask your email admin to put a trace on the email? (that's if you are sending from a mail server.