There is an old expression, through rain or sleet or dark of night, the mail must get through. The same sense of urgency applies to the delivery of e-mail. This article details how e-mail flows between mail servers, through firewalls and across the Internet. E-mail can be difficult to troubleshoot because it uses SMTP (Simple Mail Transfer Protocol), DNS (Domain Name System) and TCP/IP (Transmission Control Protocol/Internet Protocol). To troubleshoot e-mail outages, start with DNS troubleshooting and consider the basic concepts of network troubleshooting as well.
HOW E-MAIL TRAFFIC FLOWS
An originating mail server must resolve the name of the destination mail server in order to send e-mail to it. If no caching is involved, the process begins by determining the DNS server of the destination domain. From there the authoritative DNS server is queried to determine the preferred mail server and resolve its IP address. Once this process is complete, the mail server sends the message using TCP/IP.
DNS will either provide the public IP address of the destination mail server or the external interface of a firewall. In place of public addresses, most sites enable dynamic Network Address Translation (NAT) to obscure the private IP addresses of internal systems. In this case, the firewall must provide a static NAT or a proxy to pass the SMTP traffic to the private address of the mail server. When DNS resolves to the static NAT of the mail server, a permit rule or the SMTP proxy "Inbound Through" configuration must be used. When DNS resolves to the external address of the firewall, the "Inbound To" setting must be used and the SMTP proxy passes the traffic to the mail server.
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.
Copyright © 2005 CyberGuard Corporation All Rights Reserved.
Reprinted with Permission