Unblocking your IP address in spamhaus.org

2011-12-07 by Lawrence Widman

email to some but not all sites is blocked with errors like:

The mail server's IP address may be blocked by spamhaus.org which is widely used by mail servers that receive mail to filter spam. One common reason, addressed below, is that your mailserver is identifying itself as "localhost.localdomain" when it sends mail to remote mail servers. This is taken by spamhaus.org as a sign that your mail server may be infected, but the problem is easily solved. An explanation of the role of spamhaus.org in filtering spam is at http://cbl.abuseat.org/tandc.html


  1. Look at returned mail. Some remote mail servers will reference spamhaus as the reason for rejection, others give no explanation.
  2. Check at http://www.spamhaus.org/query/bl?ip=< your mail server's IP address > This will query spamhaus.org's 3 databases and show any that list your IP address. Note that the IP address to use is that of the public-facing side of your firewall.
  3. Follow the instructions that spamhaus.org's response page gives.
  4. In one common case (that which affected me), the problem was in /etc/hosts, which resulted in sendmail identifying itself as "localhost.localdomain" when it sent mail to remote mail servers. The steps for dealing with this are:
    1. Confirm that this is the problem by sending email to helocheck@cbl.abuseat.org. You will get a virtually immediate rejection, by design, but the reply email will show what your mail server (acting as a sending client) is giving as its HELO identity. For details, see http://cbl.abuseat.org/helocheck.html Your server's HELO identity is shown in the section:
                ----- The following addresses had permanent fatal errors -----
                < helocheck@cbl.abuseat.org >
                (reason: 550 HELO for IP < your IP address > was "localhost.localdomain")
      In the above example, the identity is "localhost.localdomain".
    2. To fix this problem by patching up /etc/hosts on Linux, see http://cbl.abuseat.org/hostname.html Briefly,
      1. the line that begins must contain *only* localhost localhost.localdomain.
      2. the line that begins with the LAN or WAN IP address of the machine must have the fully qualified domain name as the first datum after the IP address. Others can follow this.
      3. It does not seem to hurt to have a line with the same data as in (2) except beginning with
      4. eg, if your mail server's public name is A.B.com and its local IP address behind your NAT firewall is, your /etc/hosts file might include the following. Of course, you will want to make sure your name server returns your mail server's public IP address for A.B.com. Below, "C" is a local nickname for the mailserver that is not available on the public side.
                         localhost.localdomain   localhost
                    ::1                     localhost6.localdomain6 localhost6
                         A.B.com  A
                   A.B.com  A  C
      5. You can see whether this is the problem and whether you have fixed it by running "uname -n", "hostname -s", "hostname -d", "hostname -f", and "hostname". These should return the fully qualified domain name (eg A.B.com), the node name (eg A), the domain name (eg B.com), and for the last 2 cases the fully qualified domain name, respectively.
      6. Reboot the mail server (eg, /etc/init.d/sendmail stop then /etc/init.d/sendmail start) as root.
      The above document gives instructions for other flavors of Linux too.
    3. To fix this problem by forcing sendmail to use one fully qualified domain name, see http://cbl.abuseat.org/sendmailhelp.html
      This shows how to modify the Dj option, which is commented out by default. I would think that fixing up the machine's identity is better, as well as simpler.
    4. Check that the problem is fixed by repeating step (a) above and verifying that HELO is sending your correct machine name.
    5. Unblock your IP address by clicking the link that is at the very bottom of the page returned by http://www.spamhaus.org/query/bl?ip=< your mail server's IP address > This will take up to a few hours to take effect, but some servers will begin to respond within an hour.
  5. Secondary problem. If you see that your outgoing email is being "queued" in /var/log/mail.log, you may have a problem with DNS. In my case, /etc/resolv.conf got overwritten inadvertantly. You can have sendmail try to send the mail in its queue with
    sendmail -Ac -v -q
    (Thanks to http://www.unix.com/solaris/87923-solaris-sendmail-issue.html with confirmation at http://serverfault.com/questions/78221/sendmail-relay-status) If there is a problem, it will show a transcript of its attempts. If you have fixed the problem, it will send the email and show you a transcript of its interactions with the remote mail server.

Copyright (c) 2011 Cardiothink, Inc.