itworld.com: Many sysadmins have run into errors in their syslog files complaining of mail going backwards, suggesting a possible mx issue. The common cause of this problem is that a server is receiving email from a domain that it does not recognize as its own. then, when the server looks up the mx address for the intended destination (to send the mail on its way), it realizes that the mx record is one that identifies the mail exchanger as the system itself.
Here is an example of this type of message from the syslog file:
The cure for this type of problem is to configure the server to understand that it should accept mail for the particular domain. this can be done for sendmail by adding the domain to the /etc/mail/local-host-names file and restarting the sendmail service.
Recently, however, I ran into a situation where this familiar scenario did not describe what was happening. instead of encountering “loops back to me” errors for domains for which the server should have been legitimately receiving mail, the server in question was collecting the errors for numerous unknown domains. for most modern unix servers this problem rarely occurs because all recent versions of sendmail do not relay mail by default (ie 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 delivery had to be attempted.
To understand why “loops back to me” errors occur, it’s helpful to think about how mail servers send mail. most emails are addressed to user@domain. for example, sstocker@itworld.com. the server needs to find out which mail server is responsible for accepting mail for the particular domain. To do this, it requests the mx records (mail exchanger) of the domain in question. you can look up mx records yourself with nslookup or a similar tool, as shown below.
In this example, the system “mail1.elsewhere.com” is the primary mail exchanger identified for the domain elsewhere.com. the system “mail2.elsewhere.com” is a lower priority mail exchanger (with a preference of 20) and will receive mail when the higher priority server is unavailable.
Once our mail server has looked up this information from the mail exchangers, it can initiate a connection to the indicated mail exchanger and send the components (sender, recipient, message content, and so on) to the desired system.
However, in the case of the server with the “loops back to me” errors, there was a bit of a twist to this normal sequence of events. the mx record for the destination domain, instead of identifying a legitimate mail server, contained the loopback address, 127.0.0.1. as a result, any mail delivery attempts for the domain would be redirected to the system attempting delivery. it is as if the mail server, like a pogo, says “I have identified the destination system and it is me”. let’s look at a couple of examples (using nslookup).
our first example is for trib.com.
Notice that the mail exchanger is set to mail.trib.com and the ip address provided for trib.com is the loopback – 127.0.0.1. Continuing in nslookup, we see that the same configuration is used for the version.net domain below:
“get back to me” errors will likely show up in your syslog file (depending, of course, on the configuration of your /etc/syslog.conf file) and bounced mail will likely end up in any user’s inbox. assigned the role of postmaster.
While it’s relatively easy to fix configuration problems on your mail server, such as when you need to set up an additional domain for which you should accept mail, there’s absolutely nothing you can do to change the settings on other organizations’ mail. servers.
You’ll get the same result if someone sends mail directly to a particular host (instead of sending it to the domain), like mail1.elsewhere.com whose hostname is set to 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 desired system and find that it is set to 127.0.0.1. again, we are left with an address that simply points to the local server.
can you use this trick yourself? Okay, yes. if you want to set up a domain or a single system that can’t send mail to (at least not without knowing its public ip address), this is one way to get the job done. however, in next week’s column, we’ll examine a more elegant way to reject mail in a single system.
This story, “unix tip: mail comes back to me” was originally published by itworld.