The CBL - Composite Blocking List

Naming issues with Linux and xBSD

Incorrect hostnames on Linux (and occasionally with xBSD, such as FreeBSD, NetBSD, OpenBSD etc) often lead to problems both with the CBL, and with hosted spam filters that insist on RFC821/RFC2821 compliance.

This will most frequently appear with sendmail systems that are uttering a helo of "localhost.localdomain" and the headers in sent email will be inappropriately sprinkled with it. Up to and including From lines that have localhost.localdomain instead of your real domain.

Similar issues arise with Exim, Postfix, Sendmail and Qmail.

It all has a common problem: the machine's name is not set right.

Most of this is due to poor understanding of and idiosyncracies in install or configuration change procedures. It confuses the experts because every flavour of UNIX is different, but hopefully, this page will assist with machines intended to be used as mail servers.

This page attempts to describe how to make sure that everything is right.

In this page, "example.com" is used as your domain, "mail.example.com" is used as the hostname you want your machine to be, and 1.2.3.4 is your static IP (assuming that you have one).

WARNING: This page is specifically intended to assist in getting Linux/xBSD mail servers to know their own name properly. Situations where you'd not normally want to run a mail server (eg: the machine is on dynamic IP addresses or WIFI strangeness) are not covered. The link below can be consulted for more advanced situations.

This page is derived in part from http://www.cpqlinux.com/hostname.html

Preliminary checking that things are sane

First, you may want to exercise the various host name query tools to see if they're right, in which case you need to go no further.

The following is a sequence of commands you should execute, and their expected results (subtituting mail.example.com etc with the values you want for your machine):

shell prompt>  uname -n
mail.example.com

shell prompt>  hostname -s
mail

shell prompt>  hostname -d
example.com

shell prompt>  hostname -f
mail.example.com

shell prompt>  hostname
mail.example.com

If the results you obtain from the above commands is what you're expecting, you're done with this page.

Seeing localhost or localhost.localdomain are clear signs of wrongness.

If the results are wrong, first you need to check/correct your /etc/hosts file, second, you have to ensure that the machine knows which /etc/hosts entry to consult during boot (depends on which O/S you're using), and thirdly, reboot the machine.

Check/Correct /etc/hosts

If you have a static IP (even if it's a RFC1918 private IP address behind a NAT gateway), the /etc/hosts file should contain:

127.0.0.1     localhost.localdomain localhost
1.2.3.4       mail.example.com mail

Setting /etc/hosts for DHCP is beyond the scope of this document (why would you want to run a mail server on DHCP anyway?).

Note: many (most) problems people encounter is where the node name "mail" appears in the first line, and Linux takes the first "dotted name" in that line (usually "localhost.localdomain") as your hostname. If that's the case, just removing it should solve your problems.

In any event, the node name (eg: "mail") or hostname (eg: "mail.example.com") MUST NOT appear in the 127.0.0.1 localhost line.

Checking /etc/hostname (Debian, Knoppix et. al.)

If you have /etc/hostname or /etc/HOSTNAME on your system, make sure that it contains your host name (eg: mail.example.com).

Checking /etc/sysconfig/network (Redhat, Fedora et. al.)

If you have a static IP, then /etc/sysconfig/network will have your initial hostname assignment. It should have the following lines:
NETWORKING=yes
HOSTNAME="mail.example.com"

Checking /etc/rc.conf (FreeBSD, NetBSD et. al.)

In FreeBSD, the "hostname" setting in /etc/rc.conf should contain the fully qualified domain name of your computer. Eg:
hostname="mail.example.com"

Checking /etc/myname (alternate for some xBSD systems)

If it exists, should contain the FQDN of your machine (eg: mail.example.com).

Final testing

At this point you should reboot your system and repeat the tests given in the "checking things are sane" section.