Troubleshoot: Possible reasons that your email message does not reach it’s recipient.

Question: Why wasn’t my message received by the recipient?

Answer: There are many potential reasons a sent message is not received by the recipient.

-Your message may have been sent to the wrong email address. If your message was sent to the wrong email address, one of two things may happen:
If the email address the message was sent to exists, somebody else will receive the email message.
If the email address the message was sent to does not exist, you will receive a return email message informing you that the message cannot be delivered.
-Your message may be delayed. If your message was sent recently, it may be on its way. The recipient’s system may take some time to scan incoming mail for spam and viruses.
-Your message may also have been incorrectly trapped by a spam filter at the recipient’s end. Ask your recipient to check their spam filters for the message.

Try verifying the recipient email address, and resend the email. Also send test email to another recipient to verify other recipients are still receiving your messages.

Inbound Troubleshooting

  1. From an external system, use the nslookup command to verify that DNS resolves the IP address of the mail server (set type=SOA). Is the IP address of the mail server what you expect? If the IP address is incorrect, inbound mail will never reach the server.
  2. Are the correct combinations of configurations in place?:
    a. If the SMTP proxy “Inbound Through” setting is in use, a static NAT or public address is required.
    b. If the SMTP proxy “Inbound To” setting is in use, the mail server should be entered in the proxy’s servers tab.
    c. If a SMTP permit rule is in use, a static NAT or public address is required.
  3. If a static NAT is in use, does it point to the private address of the mail server?
  4. Determine if mail traffic is reaching the firewall. On a CyberGuard firewall, enter “netguard -An | grep mail server IP address”. A “P” in the second column indicates the traffic was permitted. If a proxy passes the traffic, an “Xr” will be present. If you see a “D” there, the traffic was denied. If you don’t see anything, mail is not currently flowing through the firewall or the traffic never reached the firewall.
  5. Try using the ping command to reach the mail server’s IP address (this requires an ICMP permit rule). If you are unable to ping the mail server, the issue pertains to the network or the availability of the mail server.
  6. Try to telnet from the firewall to the mail server (requires a SMTP permit rule):
    NETWORK > telnet mail.cyberguard.com 25
    helo mail.example.com
    mail from: jsmith@example.com
    rcpt to: jsmith@cyberguard.com
    data
    Subject: Test message

    Did you get this?
    .
    quit
    NOTE: The “.” dot on a line by itself sends the mail (above quit).

  7. Check the firewall and mail server for error messages.
  8. Capture SMTP traffic flow with the tcpdump command. Examine the output with Ethereal.

OUTBOUND TROUBLESHOOTING

  1. From the mail server, use the nslookup command to resolve a domain’s mail server (set type=SOA). If this fails, troubleshoot the issue until DNS functionality is restored. The mail server must be able to resolve names in order to send mail.
  2. From the mail server, use the ping command to try to reach its default gateway.
  3. Review the mail server and firewall error logs.
  4. Determine if mail traffic is reaching the firewall. On a CyberGuard firewall, enter “netguard -An | grep mail server IP address”. If a proxy passes the traffic, an “X” will be present.
  5. Capture SMTP traffic flow with the tcpdump command. Examine the output with Ethereal (See previous article “How Network Traffic Flows“).

TROUBLESHOOTING E-MAIL ALERTS

In order for mail alerts to be sent from a firewall, DNS must resolve the mail server to its private IP address. The best method to facilitate this is to use the Split DNS configuration. Otherwise, DNS will resolve to the public IP address of the mail server, the firewall will send alerts out via its external interface and delivery will fail. A permit rule from the firewall to the mail server must also exist.

One way to see if mail alerts are leaving the firewall is to generate an alert and check /var/spool/mailq/outgoing/smtp and /var/spool/mailq/data. If these directories contain files, the e-mail alert did not go out. If there are no files present, the alert was sent successfully.

Troubleshooting e-mail can at times seem a difficult task. Start with the basics of DNS resolution and network connectivity and work from there. The root cause rarely lies with the SMTP protocol.

source: 10.lotus.com

gideonrasmussen.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s