ITworld.com – Many systems administrators have run into errors in their syslog files that complain that mail is looping back, suggesting a possible MX problem. The common cause of this problem is that a server is receiving email for a domain that it doesn't recognize as its own. Then, when the server looks up the MX address for the intended target (in order to send the mail on its way), it notices that the MX record is one that identifies the mail exchanger as the system itself.
Here's an example of this type of message from the syslog file:
553 5.3.5 mail1.elsewhere.com. config error: mail loops back to me (MX problem?) |
Recently, however, I ran into a situation in which this familiar scenario did not describe what was happening. Instead of running into "loops back to me" errors for domains for which the server should legitimately have been receiving mail, the server in question was collecting the errors for numerous unfamiliar domains. For most modern Unix servers, this issue rarely occurs because all recent versions of sendmail do not relay mail by default (i.e., they do not accept mail from outside the domain that is also destined for outside the domain). In this case, however, the server was configured to relay mail for authenticated users, so it was required to attempt delivery.
To understand why "loops back to me" errors occur, it is useful to think about the way that mail servers go about sending mail. Most email is addressed to user@domain. For example, sstocker@itworld.com. The server then needs to figure out what mail server is responsible for accepting mail for the particular domain. To do this, it requests the MX (mail exchanger) records for the domain in question. You can look up MX records yourself with nslookup or a similar tool as shown below.
> nslookup Default Server: ns1.local.com Address: 10.1.1.11 > set querytype=mx > elsewhere.com Server: ns1.local.com Address: 10.1.1.11 elsewhere.com MX preference = 20, mail exchanger = mail2.elsewhere.com elsewhere.com MX preference = 10, mail exchanger = mail1.elsewhere.com mail1.elsewhere.com internet address = 123.4.5.6 mail2.elsewhere.com internet address = 123.4.5.7 > exit |
Once our mail server has looked up this information on mail exchangers, it can initiate a connection with the indicated mail exchanger and send the components -- sender, recipient, message contents and such -- to the intended system.
In the case of the server with the "loops back to me" errors, however, there was a slight twist to this normal sequence of events. The MX record for the target domain, instead of identifying a legitimate mail server, contained the loopback address, 127.0.0.1. As a result, any mail delivery attempted for the domain would be directed back to the system trying to make the delivery. It's as if the mail server, in Pogo-like fashion, were saying "I have identified the target system and it is me". Let's look at a couple examples (using nslookup).
Our first example is for trib.com.
> nslookup Default Server: ns1.local.com Address: 10.1.1.11 > set querytype=mx > trib.com Default Server: ns1.local.com Address: 10.1.1.11 Non-authoritative answer: trib.com MX preference = 10, mail exchanger = mail.trib.com mail.trib.com internet address = 127.0.0.1 |
> version.net Default Server: ns1.local.com Address: 10.1.1.11 Non-authoritative answer: version.net MX preference = 3, mail exchanger = mail.version.net mail.version.net internet address = 127.0.0.1 > exit |
While it's relatively easy to repair configuration problems on your mail server -- such as when you need to configure an additional domain that you should be accepting mail for, there's absolutely nothing that you can do to change the configuration on other organizations' mail servers.
You'll get the same result if someone sends mail directly to a particular host (as opposed to sending it to the domain), such as mail1.elsewhere.com whose hostname is set to the loopback. For example, if you were to try to send mail to the host, localhost.fabulous.com, your server would look up the IP address of the intended system and find out that it's set to 127.0.0.1. Again, we find ourselves with an address that simply points back to the local server.
Can you use this trick yourself? Well, yes. If you want to set up a domain or a single system to which mail cannot be sent (at least not without knowing its public IP address), this is one way to accomplish the task. However, in next week's column, we'll examine a more elegant way to refuse mail on a single system.
This story, "Unix Tip: Mail loops back to me" was originally published by ITworld.