Sendmail Domain of sender address does not resolve. Unable to send any emails.

geo_james asked:

I’ve got myself in a muddle with Sendmail. I’ve newly inherited responsibility for an app that uses sendmail and I have no previous experience. I’m using Ubuntu Ubuntu 10.04.4 LTS. Recently we realised that users were no longer receiving emails. I’ve tried testing using the following command but this doesn’t seem to trigger any activity on the mail log.

sudo sendmail -s 'Hello world'

Upon looking at the sendmail log I found messages to do with the sender address domain name not resolving. There seems to be a problem with the domain li31313-134. See below:

Apr  9 16:42:07 localhost sendmail[18230]: s39Kg7nA018230: from=www-data, size=598,                  class=0, nrcpts=1, msgid=<201404092042.s39Kg7nA018230@li313-134>, relay=www-data@localhost
Apr  9 16:42:07 localhost sendmail[18230]: s39Kg7nA018230:, delay=00:00:00, mailer=esmtp, pri=30598, dsn=4.4.3, stat=queued
Apr  9 16:43:51 localhost sendmail[18247]: s39KhpLD018247: from=jparker, size=149, class=0, nrcpts=1, msgid=<201404092043.s39KhpLD018247@li313-134>, relay=jparker@localhost
Apr  9 16:43:51 localhost sm-mta[18248]: s39KhpDC018248: ruleset=check_rcpt, arg1=<root@li313-134>relay=localhost.localdomain [], reject=451 4.1.8 Domain of sender address     jparker@li313-134 does not resolve

I’ve tried modifying my /etc/hosts with no success. Below is my current hosts file. As you can see I’ve tried a few combinations:       localhost.localdomain   localhost
<EXTERNAL IP>   li313-134       li313-134.       li313-134       li313-134.

Another issue I can’t rule out is IPTABLES blocking the outgoing mail. Again, not much experience with it but I’ve tried to ensure port 25 is open for sending/receiving. I can receive mail ok. IPTABLES rules below. There may be a couple of rogue rules in there:

Chain INPUT (policy DROP 10 packets, 508 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     210K   67M fail2ban-ssh  tcp  --  *      *                 multiport dports 22
2    4986K 6254M ACCEPT     all  --  *      *  
3      27M 4312M ACCEPT     tcp  --  *      *             multiport dports 22,80,443,3690,5432,8999:9003
4      147 10052 ACCEPT     udp  --  *      *             multiport dports 53
5      18M   12G ACCEPT     all  --  *      *             state RELATED,ESTABLISHED
6        0     0 DROP       all  --  *      *
7       51  2464 DROP       all  --  *      * 
8       75  6399 DROP       all  --  *      *
9        0     0 DROP       all  --  *      *
10    9425  669K DROP       all  --  *      *  
11       0     0 ACCEPT     tcp  --  eth0   *             tcp dpt:25 state NEW,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 11M packets, 766M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    4986K 6254M ACCEPT     all  --  *      *  
2      39M   16G ACCEPT     all  --  *      *              state RELATED,ESTABLISHED
3        0     0 ACCEPT     tcp  --  *      eth0             tcp spt:25 state ESTABLISHED

My answer:

The easy fix is to rename the host to a name that actually does exist in the DNS.

View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.