Dear sendmail group,

I am having difficulty with my sendmail refusing local connections with the
message:

Connection refused by [127.0.0.1]

This has the knock on effect that alerts normally delivered to the
postmaster or root are not being delivered and are sitting in the queue.

Here is the sendmail.mc:

divert(0)dnl
VERSIONID(`@(#)lccrelay 1.5 (Sun) 17/01/2005')
OSTYPE(`solaris8')dnl
DOMAIN(`generic')dnl
FEATURE(`nouucp', `reject')dnl
FEATURE(access_db)dnl
FEATURE(`mailertable')dnl
FEATURE(blacklist_recipients)dnl
# FEATURE(`dnsbl', `sbl.spamhaus.org', `Spam blocked by Spamhaus')dnl
 FEATURE(`accept_unresolvable_domains')dn
l
FEATURE(local_lmtp)dnl
FEATURE(`no_default_msa')dnl
FEATURE(`authinfo')dnl
DAEMON_OPTIONS(`Name=MTA, Addr=192.168.1.148, Port=smtp')dnl
define(`LOCAL_MAILER_FLAGS', LOCAL_MAILER_FLAGS`'P)dnl
define(`confCW_FILE', `-o /etc/mail/local-host-names')dnl
define(`confCACERT_PATH', `/etc/mail/certs/')dnl
define(`confCACERT', `/etc/mail/certs/cacert.pem')dnl
define(`confSERVER_CERT', `/etc/mail/certs/cert.pem')dnl
define(`confSERVER_KEY', `/etc/mail/certs/key.pem')dnl
define(`confCLIENT_CERT', `/etc/mail/certs/cert.pem')dnl
define(`confCLIENT_KEY', `/etc/mail/certs/key.pem')dnl
define(`confSMTP_LOGIN_MSG', `Leicester_City_Council gateway')dnl
define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy,noverb')dnl
define(`confAUTH_OPTIONS', `A')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
INPUT_MAIL_FILTER(`milter-regex', `S=unix:/var/spool/milter-regex/sock,
T=S:30s;R:2m')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl

Here is the access list:

To:leicester.gov.uk     RELAY
Connect:mailhost        RELAY
Connect:mail-relay1.leicester.gov.uk    RELAY
Connect:mail-relay2.leicester.gov.uk    RELAY
Connect:10.130.148.40   RELAY
Connect:10.52.1.234     RELAY
Connect:localhost       OK
127.0.0.1               OK

I have tried changing the OK to RELAY for the entry 127.0.0.1 but this makes
no difference.

The connection is dropped immediately:

root@mail-relay3 # telnet localhost 25
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
root@mail-relay3 #

I can't see what else may be preventing this connection. A remote connection
from my machine (10.130.148.40) and from other hosts in the list works fine.
I do not have tcpwrapper or any other port blocking or firewall software
installed as far as I can see.

[ Post a follow-up to this message ]

"John Chajecki" <jchaj.news@group.dsl.pipex.com> writes:
> I am having difficulty with my sendmail refusing local connections with th
e
> message:
>
>   Connection refused by [127.0.0.1]
>
> This has the knock on effect that alerts normally delivered to the
> postmaster or root are not being delivered and are sitting in the queue.
> [...]
> The connection is dropped immediately:
>
> root@mail-relay3 # telnet localhost 25
> Trying 127.0.0.1...
> telnet: Unable to connect to remote host: Connection refused
> root@mail-relay3 #
>
> I can't see what else may be preventing this connection. A remote connecti
on
> from my machine (10.130.148.40) and from other hosts in the list works fin
e.
> I do not have tcpwrapper or any other port blocking or firewall software
> installed as far as I can see.

Standard "warm up" question:
Is sendmail listening on *all* IP interfaces?
[ test on linuxes: nestat -ant | grep :80 ]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/

[ Post a follow-up to this message ]

John,
>
> I am having difficulty with my sendmail refusing local connections with th
e
> message:
>
>   Connection refused by [127.0.0.1]
>
> This has the knock on effect that alerts normally delivered to the
> postmaster or root are not being delivered and are sitting in the queue.
>
> Here is the sendmail.mc:
>
> divert(0)dnl
> VERSIONID(`@(#)lccrelay 1.5 (Sun) 17/01/2005')
> OSTYPE(`solaris8')dnl
> DOMAIN(`generic')dnl
> FEATURE(`nouucp', `reject')dnl
> FEATURE(access_db)dnl
> FEATURE(`mailertable')dnl
> FEATURE(blacklist_recipients)dnl
> # FEATURE(`dnsbl', `sbl.spamhaus.org', `Spam blocked by Spamhaus')dnl
>  FEATURE(`accept_unresolvable_domains')dn
l
> FEATURE(local_lmtp)dnl
> FEATURE(`no_default_msa')dnl
> FEATURE(`authinfo')dnl
> DAEMON_OPTIONS(`Name=MTA, Addr=192.168.1.148, Port=smtp')dnl
....
> The connection is dropped immediately:
>
> root@mail-relay3 # telnet localhost 25
> Trying 127.0.0.1...
> telnet: Unable to connect to remote host: Connection refused
> root@mail-relay3 #
>
> I can't see what else may be preventing this connection. A remote connecti
on
> from my machine (10.130.148.40) and from other hosts in the list works fin
e.
> I do not have tcpwrapper or any other port blocking or firewall software
> installed as far as I can see.

I'm not completely sure on this, but I think your
problem is in: DAEMON_OPTIONS(`Name=MTA, Addr=192.168.1.148, Port=smtp')dnl 
--
you are telling sendmail to only listen on that IP address for connections,
that would preclude localhost.  I 'believe' you could add another line:
DAEMON_OPTIONS(`Name=MTA, Addr=127.0.0.1, Port=smtp')dnl and get it working.

Best regards!
--
John
 ________________________________________
___________________________
John Murtari                              Software Workshop Inc.
jmurtari@following domain 315.635-1968(x-211)  "TheBook.Com" (TM)
http://thebook.com/

[ Post a follow-up to this message ]

"John Murtari" <jmurtari@thebook.com> wrote in message
news:x7mytgzosm.fsf@hammer.thebook.com...[vbcol=seagreen]
> John, 
> .... 
>
>             I'm not completely sure on this, but I think your
> problem is in: DAEMON_OPTIONS(`Name=MTA, Addr=192.168.1.148, Port=smtp')dn
l --
> you are telling sendmail to only listen on that IP address for connections
,
> that would preclude localhost.  I 'believe' you could add another line:
> DAEMON_OPTIONS(`Name=MTA, Addr=127.0.0.1, Port=smtp')dnl and get it working.[/vbco
l]

Probably, NO address should be specified at all - unless there's some
address/interface that should NOT be listened to.

[ Post a follow-up to this message ]

John Chajecki wrote:

>   Connection refused by [127.0.0.1]

Did you start the the process that handles the "submit" jobs (submit.cf)?

sendmail -Ac -q15m
sendmail -bd -q15m

I've also seen this happen in some systems when you don't have localhost
connections allowed explicitly in /etc/hosts.allow.

[ Post a follow-up to this message ]

On 14.11.2007 13:33, John Chajecki wrote (please find the answer below the original text):[v
bcol=seagreen]
> Dear sendmail group,
>
> I am having difficulty with my sendmail refusing local connections with th
e
> message:
>
>   Connection refused by [127.0.0.1]
>
> This has the knock on effect that alerts normally delivered to the
> postmaster or root are not being delivered and are sitting in the queue.
>
> Here is the sendmail.mc:
>
> divert(0)dnl
> VERSIONID(`@(#)lccrelay 1.5 (Sun) 17/01/2005')
> OSTYPE(`solaris8')dnl
> DOMAIN(`generic')dnl
> FEATURE(`nouucp', `reject')dnl
> FEATURE(access_db)dnl
> FEATURE(`mailertable')dnl
> FEATURE(blacklist_recipients)dnl
> # FEATURE(`dnsbl', `sbl.spamhaus.org', `Spam blocked by Spamhaus')dnl
>  FEATURE(`accept_unresolvable_domains')dn
l
> FEATURE(local_lmtp)dnl
> FEATURE(`no_default_msa')dnl
> FEATURE(`authinfo')dnl
> DAEMON_OPTIONS(`Name=MTA, Addr=192.168.1.148, Port=smtp')dnl
> define(`LOCAL_MAILER_FLAGS', LOCAL_MAILER_FLAGS`'P)dnl
> define(`confCW_FILE', `-o /etc/mail/local-host-names')dnl
> define(`confCACERT_PATH', `/etc/mail/certs/')dnl
> define(`confCACERT', `/etc/mail/certs/cacert.pem')dnl
> define(`confSERVER_CERT', `/etc/mail/certs/cert.pem')dnl
> define(`confSERVER_KEY', `/etc/mail/certs/key.pem')dnl
> define(`confCLIENT_CERT', `/etc/mail/certs/cert.pem')dnl
> define(`confCLIENT_KEY', `/etc/mail/certs/key.pem')dnl
> define(`confSMTP_LOGIN_MSG', `Leicester_City_Council gateway')dnl
> define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy,noverb')dnl
> define(`confAUTH_OPTIONS', `A')dnl
> define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
> TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
> INPUT_MAIL_FILTER(`milter-regex', `S=unix:/var/spool/milter-regex/sock,
> T=S:30s;R:2m')dnl
> MAILER(`local')dnl
> MAILER(`smtp')dnl
>
> Here is the access list:
>
> To:leicester.gov.uk     RELAY
> Connect:mailhost        RELAY
> Connect:mail-relay1.leicester.gov.uk    RELAY
> Connect:mail-relay2.leicester.gov.uk    RELAY
> Connect:10.130.148.40   RELAY
> Connect:10.52.1.234     RELAY
> Connect:localhost       OK
> 127.0.0.1               OK
>
> I have tried changing the OK to RELAY for the entry 127.0.0.1 but this mak
es
> no difference.
>
> The connection is dropped immediately:
>
> root@mail-relay3 # telnet localhost 25
> Trying 127.0.0.1...
> telnet: Unable to connect to remote host: Connection refused
> root@mail-relay3 #
>
> I can't see what else may be preventing this connection. A remote connecti
on
> from my machine (10.130.148.40) and from other hosts in the list works fin
e.
> I do not have tcpwrapper or any other port blocking or firewall software
> installed as far as I can see.
>[/vbcol]

you might check on that host by
$ netstat -ln | grep 25
if there is an output like:
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN

if you see the line, then you might check your firewall/netfilter for
not allowed connections on localhost/127.0.0.1

-Ingo.

[ Post a follow-up to this message ]

Andrzej,

I'm not on Linux but Solaris, however:

root@mail-relay3 # netstat -an |grep 25
192.168.1.196.25           *.*                0      0 49152      0 LISTEN
192.168.1.99.25            *.*                0      0 49152      0 LISTEN
192.168.1.148.25     192.168.193.109.11365 62100      0 49680      0
ESTABLISHED
192.168.1.148.25           *.*                0      0 49152      0 LISTEN

Clearly then not listening on 127.0.0.1.

[ Post a follow-up to this message ]

"John Chajecki" <jchaj.news@group.dsl.pipex.com> writes:

> Andrzej,
>
> I'm not on Linux but Solaris, however:
>
> root@mail-relay3 # netstat -an |grep 25
> 192.168.1.196.25           *.*                0      0 49152      0 LISTEN
> 192.168.1.99.25            *.*                0      0 49152      0 LISTEN
> 192.168.1.148.25     192.168.193.109.11365 62100      0 49680      0
> ESTABLISHED
> 192.168.1.148.25           *.*                0      0 49152      0 LISTEN
>
> Clearly then not listening on 127.0.0.1.

In other parts of the thread John Murtari has already "pinpointed" the
problem to DAMEON_OPTIONS line in your *.mc file and D. Stussy has added
some useful comments.

DAEMON_OPTIONS(`Name=MTA, Addr=192.168.1.148, Port=smtp')dnl

I may only add that if you decided for some strange reasons to keep
DAEMON_OPTIONS line  "as it is" then you may change submit.mc to pass
locally submitted messages to  192.168.1.148:25 instead of default
127.0.0.1:25.

P.S.
I promise to read more carefully details in posts I reply too.
[ Treat the above as pre-elections promise ;-) ]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/

[ Post a follow-up to this message ]

John,

You were right.

I did indeed put this line in to make sendmail listen on a specific IP
address. This was because I have two additional sendmail daemons listening
on two other IP addresses on the same host.

I followed your advice and added:

DAEMON_OPTIONS(`Name=LOC, Addr=127.0.0.1, Port=smtp')dnl

I changed the value of the 'name' parameter because when I looked at the
docs on the sendmail website, I found that in the example the name was
unique for each listener.

I now get:

192.168.1.196.25           *.*                0      0 49152      0 LISTEN
192.168.1.99.25            *.*                0      0 49152      0 LISTEN
192.168.1.148.25           *.*                0      0 49152      0 LISTEN
127.0.0.1.25               *.*                0      0 49152      0 LISTEN

In addition, all the mail for root that was stuck in the queue has now been
delivered.

Thanks for helping me solve the problem.

[ Post a follow-up to this message ]

Andrzej,

It seems you sent your response while I was working on it.

I have now done as John suggested and it worked fine and I have responded
accordingly.

Thanks for your contribution.

[ Post a follow-up to this message ]