6.14. Mail delivery fails with "(-2, 'Name or service not known')", aka I am not receiving any notification messages from Mailman.
Question: When I create a new mailing list, I don't get the usual notification E-mail message from Mailman that I know I'm supposed to get. Instead, I see these log entries in smtp-failure:
Dec 22 21:03:29 2004 (1060) delivery to email@example.com failed with code -1: (-2, 'Name or service not known') Dec 22 21:18:32 2004 (1060) Low level smtp error: (-2, 'Name or service not known'), msgid: <firstname.lastname@example.org> Dec 22 21:18:32 2004 (1060) delivery to email@example.com failed with code -1: (-2, 'Name or service not known').
What do I do?
Answer: It took me an extremely long time to crack this one. The problem lies in your resolv.conf. What is happening is that Smtplib, whose subroutines are being called by the $PREFIX/Mailman/Handlers/SMTPDirect.py script, is unable to find an FQDN hostname associated with your machine. Therefore, the exception that is raised by Smtplib is then reflected back in the smtp-failure log, as demonstrated above. One can see exactly where the exception is coming from by doing the following at the Python prompt (this is a transcript of a relevant interactive Python session):
>>> import smtplib >>> connection = smtplib.SMTP() Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.4/smtplib.py", line 255, in __init__ addr = socket.gethostbyname(socket.gethostname()) socket.gaierror: (-2, 'Name or service not known') >>>
You will notice that it was the call to SMTP() that ended up failing to Smtplib, and the call to socket.gethostbyname() that failed inside the module. The solution to this one believe it or not, is actually very simple. Add a domain search path to the top of your resolv.conf, like so:
search my.domain nameserver 220.127.116.11 nameserver 18.104.22.168
Substitute the above example entries according to your current DNS configuration. In my case, I run my own domain, with everything querying my Nameserver directly on localhost. Therefore, my resolv.conf looks like:
search lava-net.com nameserver 127.0.0.1
Note: In the above case, the problem was with resolve.conf, but this exact same symptom can result from other underlying issues. It is sometimes caused by incorrect or incomplete information in /etc/hosts. In at least one reported case it was due to /etc/hosts not being world readable, i.e. 'root' could read it but not 'mailman'.
If the above Python snippet returns the error and you still can't figure out why, try the following:
>>> import socket >>> x = socket.gethostname() >>> print x (response) >>> y = socket.gethostbyname(x) >>> print y (response) >>>
in order to isolate whether the problem is in getting the local host name, gethostname(), or in getting the IP address from the name, gethostbyname().
If the various diagnostic snippets above don't fail, first make sure you are running them as the 'mailman' user and not as root as this can make a difference. Also see <http://mail.python.org/pipermail/mailman-users/2005-May/044976.html> and <http://mail.python.org/pipermail/mailman-users/2005-May/044746.html> for more complete tests, and if these work, make sure you don't have different (wrong) settings for SMTPHOST and/or SMTPPORT in mm_cfg.py.
Also see 4.73 How do I debug smtp-failure problems - delivery to user-example.com failed with code -1- and Low level smtp error- for an additional debugging technique.
Note: One more way socket.gethostbyname() can fail is the obvious one, you haven't set the machine's hostname to an actual fully-qualified domain name. Mine was still set to the temporary name the machine had when I installed the OS.
~# hostname canoworms ~# hostname realname.example.net ~# hostname realname.example.net
solved the problem and
~# cat /etc/hostname canoworms ~# echo realname.example.net > /etc/hostname
made it stick.
Converted from the Mailman FAQ Wizard
This is one of many Frequently Asked Questions.