Newsgroups: comp.mail.sendmail
Date: Thu, 25 Jan 2007 06:53:06 +0000 (UTC)

>I get the "ESMTP connection timed out" error when trying to send email.

Actually, no, you don't (and there is no such error msg in sendmail).

>  $ sendmail -f test@email.addr -v
>  test@email.addr... Connecting to [127.0.0.1] port 587 via relay...
>  220 ;; ESMTP connection timed out; no servers could be reached
>Sendmail 8.13.8/8.13.8/Debian-3; Wed, 24 Jan 2007 23:21:21 -0500; (No
>UCE/UBE) logging access from: my.host.name(OK)-my.host.name [127.0.0.1]
>  >>> EHLO my.host.name
>  250-;; connection timed out; no servers could be reached Hello
>my.host.name [127.0.0.1], pleased to meet you

You seem to be a victim of the same broken "helpfulness" as described in the (apparently misthreaded by google) thread at

http://groups.google.com/group/comp.mail.sendmail/browse_frm/thread/7095fe4c3569eed1

i.e. some install script or whatever has "configured" your sendmail with a *host name* of literally " ;; connection timed out; no servers could be reached"! This is actually an error message from the 'dig' command - i.e. the script probably tries to use 'dig' to get the fully-qualified host name, and blindly accepts any output from 'dig'. The slightly different greeting comes from the fact that sendmail inserts the "ESMTP" there as the second word, under the reasonable assumption that the host name is a single word…

>  250 2.0.0 l0P4LLHX023711 Message accepted for delivery
>  test@email.addr... Sent (l0P4LLHX023711 Message accepted for delivery)

So the submission went OK, despite the repeated "error messages".

>In /var/log/mail.log:
>
>  Jan 24 23:21:21 myhost sm-mta[23713]: l0P4LLHX023711:
>to=<test@email.addr>, delay=00:00:00, xdelay=00:00:00, mailer=relay,
>pri=120408, relay=my.isp.com. [199.x.x.x], dsn=5.0.0, stat=Service
>unavailable

This occurs when the MTA relays your message to your smart host - the sender should have received a bounce with a more detailed explanation than "Service unavailable", but it's a good guess that the broken host name makes the remote complain and reject the message, or the whole transaction - e.g. it would result in a syntactically invalid HELO/EHLO command for starters.

Per Hedeland @hedeland.org