Outbound SMTP e-mails can sometimes fail with a peculiar error, "451 Action Aborted," that is often echoed repeatedly to the recipient or sender. The failed message will sit in the IMS queue and will continue to echo the error until the message is deleted or sent successfully (which often never happens until the underlying problem is fixed).
Exchange classifies a 451 error as a "local error," but this can sometimes be a slightly misleading classification, because the problem is not always due to conditions on the local server. There are several reasons why a message will produce a 451 error, some due to local conditions and some due to the remote server. Here they are, roughly in descending order of probability:
- The domain name in the MAIL FROM packet is not a valid domain. This is usually the reason for the "local error" designation -- it means that your local server is misconfigured and not providing remote servers with the correct domain name. Many remote mail servers will perform a reverse DNS lookup to insure that the incoming mail is in fact being transmitted from the server in question (although a great many of them, such as those on low-rent ISPs, can be set to skip this step for the sake of speed!). If the name does not match the domain name in the DNS lookup operation, the remote host will reject the mail. Check to make sure your MX records for your domain are configured correctly -- or that you have one at all.
- A firewall may be creating trouble. Some firewalls are designed to strip SMTP commands from packets, and may do this as part of their default configuration. Check your local firewall settings to make sure this is not happening. If the problem is not a firewall on your end, but on the remote server, you may want to look up the administrative record for the remote domain and drop a phone call about the horribly misconfigured server! (One way to determine if the other end is the problem is to Telnet to the other server and attempt to enter a message by hand.)
- Other network conditions may be causing the connection to close prematurely, such as a low timeout threshold. One way to get to the bottom of this is to turn on diagnostic logging, especially for IMS's internal processes, and check the logs to see if anything obvious shows up.
Serdar Yegulalp is the editor of the Windows 2000 Power Users Newsletter.