Returned mail: Data format error (Sender domain must exist)This article deals with an obscure error message I received when I encountered mail which was being rejected because of a "Sender domain does not exist" problem.
The exampleHere is the message which bounced back to me. Certain bits have been changed to protect the idiotic.
Date sent: Fri, 3 Mar 2000 12:43:12 +1300 (NZDT)
From: Mail Delivery Subsystem <MAILER-DAEMON>
Subject: Returned mail: Data format error
The original message was received at Fri, 3 Mar 2000 12:43:04 +1300 (NZDT)
from denis.int.mydomain.org [192.168.2.199]
----- The following addresses had permanent fatal errors -----
----- Transcript of session follows -----
... while talking to host.anotherdomain.com.:
>>> MAIL From:<firstname.lastname@example.org> SIZE=1101
<<< 501 <email@example.com>... Sender domain must exist
501 <firstname.lastname@example.org>... Data format error
This problem didn’t take me very long to understand the cause. It’s right there: "Sender domain must exist". When the mail server receives the message I sent, it checks the return address to verify that the sender domain exists. For some reason, my box was using the wrong domain. I wasn’t sure where to change this, but then I remembered how I had split my domain name space into private and public sectors. I checked the zone file which contains my reverse look-ups (i.e. the file that maps IP addresses to host names; see my zone files for an example) and I found the problem there.
In my reverse lookup file, I found this:
20 IN PTR myhost.int.mydomain.org.
Ahhh! There’s the problem. When sendmail on my box sends out a message, it looks up the host name for the IP address on which it’s running. In this case, the reverse lookup resolves to an internal domain, which nobody can resolve because I don’t export that sub-domain (i.e. int.mydomain.org). Note that "int" in this context refers to "internal", not "international".
I changed the above line to:
20 IN PTR myhost.mydomain.org.
…and then I HUP’d named. I then sent out a sample message. It’s important to make the destination address somewhere other than yourself In other words, don’t send a test messge from your server to your server. That would not be a valid test. I solved this issue by sending a message to my email address at my ISP.
Some observationsI remain unconvinced that my actions solved the problem. As part of my testing I reversed my changes to observe the effect. I couldn’t reproduce the problem. I HUP’d both sendmail and named. I couldn’t get the old problem back.
For what it’s worth, here is a side-by-side comparison of the before and after headers of my test messages:
It’s important to note the change in the above lines. On the left is the before image. The return page contains the hostname of my box. On the right is the after image. It contains the reply-to address which is configured in my mail client. That’s interesting. As I said, I tried to do some testing in this area to reproduce the problem but failed. Therefor I’m not sure if my conclusions are 100% accurate or not.
Another possible cause (added on 30 September 2000)John Conway wrote in with this note:
I had the same thing, but I don’t have any reverse for my ip’s. The problem was in the DNS file, that particular server was not stated with:myhost A <ip here>
So if someone wanted to go to the server blah.servername.com, it wasn’t able to find an ip for server blah.servername.com ..which was what it was showing as the email@example.com.
I added this to the dns file
blah IN A 126.96.36.199
In short, the host which was sending the mail had to have an IP address associated with it. Before John added the host to his DNS file, nslookup blah.servername.com would have failed.