Exim4 'error' - no host name found for IP address


I get a lot of ‘no host name found for IP address’ lines in my exim mainlog. At first, I thought it was an error message, but it turns out that actually it’s exim mildly complaining that its config has asked it to look up something using the sender host name and it hadn’t managed to establish a reliable name from the incoming IP address. With the standard Symbiosis setup, mail can continue to be delivered even when this message appears. Eventually exim will look in the headers to find a hostname it can use in the log and elsewhere.

When a client connects, Exim does a reverse lookup on the IP calling it. This can fail with ‘no such domain’, or it can return a domain name. If it gets a returned domain name, Exim will check that it makes sense, by looking up the domain and checking that it leads to the IP that made the connection. If if cannot verify the name, it doesn’t trust the reverse lookup and the hostname it has for the sender remains unset.

Some Symbiosis postings suggest that you use the error message in your firewall patterns file, because spam often comes from machines that haven’t established a reverse IP. However, it turns out that the forward check is not a reliable indicator that the mail is coming from a domain sending spam, people do understand that a mail sending machine needs a reverse IP established, but they can have complex DNS setups which mean that the forward check may not lead back to the IP they are using for mail.

So given that the lack of a reverse IP is a good indicator that the mail is spam, I want to treat mail from such hosts as if their IP appears in a black list. The code below does this. It uses a direct DNS lookup to check that the PTR record is non-existent, and denies access if this is the case.

I’ve put my test in the ACL for checking the RCPT command, because that’s where lots of sender checking is done. If you’ve wisely selected the use of zen.spamhaus.org, and perhaps installed the additional blacklist sites (see Email defences; additional DNS RBL), then this checking is done in this ACL.

Copy the text below and put it into a new file 77-check-sender-host-name in /etc/exim4/symbiosis.d/10-acl/50-acl-check-rcpt. This places it after the DNS blacklist checks, but before the SpamAssassin and virus checks. If you have a file starting with 77, then you can change the number at the start of the name to put it into the right place.

  # This looks up the sender address in the DNS
  # and will fail if nothing is registered for the PTR
  # which is common with spammers
  # Wise to only use this if running a local caching DNS server

  deny !condition = ${lookup dnsdb{defer_never,ptr=$sender_host_address}{yes}}
       message = No reverse DNS record found

Now backtrack up to /etc/exim4 and type make, to add this to your setup.

I still get the error message, usually when there is no reverse lookup, but I am now rejecting the mail which is likely to be spam. If this is picking up mail from somewhere that you do want to get mail from, you can whitelist it’s ip by adding it to /etc/exim4/whitelist/by_ip.


Thanks, that’s a handy tip.

BTW, I don’t think Exim ever tries to find a domain name in the message headers: none of them can be to contain reliable information. It will, I think, log the argument to EHLO, in which the sending server claims to have a particular host name.


Hi @hillside and thanks for posting.

Just for info., I do something similar - just set to warn at the moment - with this:

# ------------------------------------------------------------------------------
# /etc/exim4/symbiosis.d/10-acl/50-acl-check-rcpt/66-x-deny-rdns-invalid
# ------------------------------------------------------------------------------

# Reject or, at least, delay, connections from hosts without valid reverse dns
# this may occasionally come back to bite... watch the logs

    warn      domains        = +vhost_domains
              !hosts         = ${if exists{VHOST_DIR/.all-sites/VHOST_CONFIG_DIR/whitelists/rdns-fail}\
                                          {VHOST_DIR/.all-sites/VHOST_CONFIG_DIR/whitelists/rdns-fail} {}}
    #         message        = Reverse DNS lookup failed for host $sender_host_address
              !verify        = reverse_host_lookup
              log_message    = ACL:10-50-66 H=$sender_fullhost failed rDNS validation
              control        = no_pipelining
              delay          = 5s

At the time, I was wondering if there would be too many innocent (badly configured) ipv6 hosts so I let it run with ‘warn’ to try and get a fix. Most of the entries were rbl listed so I’ve not revisited it - until now.


Thanks for that


I think that reverse_host_lookup isn’t JUST the presence of a PTR record - I think it’s equivalent to testing if sender_host_name is empty - so it’s relying on the forward lookup - which I’ve found can be unsafe. Of course, I may be wrong.


That’s right. verify = reverse_host_lookup looks to see if it can find PTR record for the sender’s IP address. There may be several, though that’s unusual. If there are none, the verification fails. But if there is a result, it then checks A records for the result, to see if any of them points back to the original IP address. That’s known as Forward confirmed Reverse DNS

Note that you can also say verify = reverse_host_lookup/defer_ok which will not fail when DNS lookups get a temporary problem - so dns hiccoughs won’t prevent mail delivery.


I’ve found that the ‘Forward confirmed Reverse DNS’ is not reliable, the forward lookup can fail to get back to the sending IP. Sendmail’s been blocking people with no reverse DNS for eons, and I expect the Postfix followed this lead - so sysadmins understand the need for setting up the reverse DNS. Looking up the result and needing it to point back to the sending host - just isn’t understood generally. Also I think that there are cases where setting up the DNS like this isn’t desirable - for example a web based system sending acknowledgement email may be based on a different system from the organisation’s main mail host.

So, what’s missing in the Exim setup is an indication that the forward lookup has failed, and the work-around is to lookup the reverse IP in the DNS. This at least picks off the spammers with no reverse IP. It’s at the end of several other checks, and is just a step which picks off the spammers who are not in and DNSBL yet.


I’ve been blocking on invalid rDNS (& invalid A or MX) for years in-house (not exim). Admittedly, very low volume - a few hundred messages a day inbound - but I can only remember noticing one undesired rejection. Seems to work here.

True but anyone concerened with deliverability should be all over it from the off. In other words the important stuff finds a way of getting through - afaik :slight_smile: