Things look quiet here. But I've been doing a lot of blogging at
dan.langille.org because I prefer WordPress now.
Not all my posts there are FreeBSD related.
I am in the midst of migrating The FreeBSD Diary over to WordPress
(and you can read about that here).
Once the migration is completed, I'll move the FreeBSD posts into the
new FreeBSD Diary website.
Returned mail: Data format error (Sender domain must exist)4 March 2000
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 example
Here 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>
To: <me@myhost.int.mydomain.org>
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 -----
<someone@anotherdomain.com>
----- Transcript of session follows -----
... while talking to host.anotherdomain.com.:
>>> MAIL From:<me@myhost.int.mydomain.org> SIZE=1101
<<< 501 <me@myhost.int.mydomain.org>... Sender domain must exist
501 <someone@anotherdomain.com>... 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.
The solution
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 observations
I 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:
Return-Path: <me@myhost.int.mydomain.org>
Return-Path: <me@myrealdomain.org>
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 cause30 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 bob@blah.servername.com.
I added this to the dns file
blah IN A
77.77.77.77
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.
