topic Re: sendmail....! in Operating System - HP-UX

sendmail....!

derek b smith_1 — Tue, 07 Sep 2010 14:24:42 GMT

Hi All,

I am getting this ole sendmail error. I searched and read many prior posts to no avail.
As a sysadmin habit I like to disable sendmail daemon, and still use the smart relay option which I am but I still get this error.

Aug 30 09:51:56 jude sendmail[6394]: o7UDpuC6006394: to=andrew.xxxx@cbc-companies.com, ctladdr=oracle (501/501), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30778, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]

My other hosts do not have this issue.
Below are some configs from my problem host:

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter

> $S
mailhost
> $j
jude.cbc.local

# tail /etc/mail/sendmail.cw
# disklessclient1.foo
# disklessclient1.foo.com
# disklessclient2
# disklessclient2.foo
# disklessclient2.foo.com
##
localhost
jude
jude.cbc
jude.cbc.local

# cat /etc/nsswitch.conf
passwd: centrifydc files
group: centrifydc files
hosts: files dns
networks: files
protocols: files
rpc: files
publickey: files
netgroup: files
automount: files
aliases: files
services: files

# grep mailhost /etc/hosts
10.1.4.16 mailhost.cbc.local mailhost

root@jude [/etc/mail]
# grep local /etc/hosts
127.0.0.1 localhost loopback
131.16.91.95 jude.cbc.local jude
10.1.4.16 mailhost.cbc.local mailhost
10.1.8.210 cbclog.cbc.local cbclog

root@jude [/etc/mail]
# ping 10.1.4.16
PING 10.1.4.16: 64 byte packets
64 bytes from 10.1.4.16: icmp_seq=0. time=0. ms

----10.1.4.16 PING Statistics----
1 packets transmitted, 1 packets received, 0% packet loss

I suppose I could just config it to send-only but...rather not.

Re: sendmail....!

Steven E. Protter — Tue, 07 Sep 2010 15:02:50 GMT

Shalom,

if you disable the sendmail daemon, which is a good job, you need a cron job to run the queue once in a while and get the mail off the system.

After you get some mail in the outbound queue, run this command:

sendmail -v -q

Post a snippet if you get unexpected results.

SEP

Re: sendmail....!

derek b smith_1 — Tue, 07 Sep 2010 16:13:55 GMT

I did run sendmail -v -q with no output and same results:

Sep 7 13:11:02 jude sendmail[14792]: o87HB2rB014792: from=dsmith, size=147, class=0, nrcpts=1, msgid=<201009071711.o87HB2rB014792@jude.cbc.local>, relay=dsmith@localhost
Sep 7 13:11:02 jude sendmail[14792]: o87HB2rB014792: to=derek.smith@cbc-companies.com, ctladdr=dsmith (5008/4), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30147, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]

Re: sendmail....!

Tim Nelson — Tue, 07 Sep 2010 18:40:14 GMT

by the looks of things you are relaying to the localhost.. is that your intent ?

if so, then you need to always run the sendmail daemon in order to recieve that mail..

Not sure what you are trying to accomplish.

you do not need the sendmail daemon running in order to send any email..only to receive.. and on the occasion where the outgoing mail gets queued for some reason ( this is where you run the queue runner via cron. )

Re: sendmail....!

derek b smith_1 — Tue, 07 Sep 2010 18:47:45 GMT

Tim,

Thanks for the reply but you are wrong.
My relay host is mailhost per

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter

> $S
mailhost

above.

I updated it to another relay host, another exchange server and I still get the same error.

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter

> $S
cbcsmtp.cbc.local.

Any other ideas?

Re: sendmail....!

derek b smith_1 — Tue, 07 Sep 2010 19:13:28 GMT

see attachment for debug mode output.

thank you!

Re: sendmail....!

Tim Nelson — Tue, 07 Sep 2010 19:21:02 GMT

must have missed that.. was reading this line in the log output.

stat=Deferred: Connection refused by [127.0.0.1]

Re: sendmail....!

Patrick Wallek — Tue, 07 Sep 2010 19:32:37 GMT

It also appears to me that it is not getting to the relay host.

What does "nslookup mailhost" return? Does it return the IP address of your relay server or does it return "127.0.0.1".

What if you modify your sendmail.cf file and insert the IP address of your relay server rather than the hostname?

Re: sendmail....!

Steven E. Protter — Tue, 07 Sep 2010 19:34:04 GMT

Shalom,

Short term, you might want to turn on the sendmail daemon. Sendmail has been re-structured in recent years to make it harder to queue mail without the daemon running.

Which is the recommended way of running a Unix server.
This link may be helpful.

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1283891629976+28353475&threadId=1408233

SEP

Re: sendmail....!

derek b smith_1 — Tue, 07 Sep 2010 20:00:50 GMT

I have it turned back on in send mode only, but when I change relay to the IP it still fails.

Re: sendmail....!

Patrick Wallek — Tue, 07 Sep 2010 20:20:37 GMT

>>but when I change relay to the IP it still fails.

With the same type of error? Can you post new output/traces, please?

Re: sendmail....!

Jim Walls — Wed, 08 Sep 2010 01:54:11 GMT

You could try putting the following line into /etc/nsswitch.conf

ipnodes: files dns

or possibly just

ipnodes: files

We had problems with telnet name/address resolution because ipv6 is enabled and this fixed it.

Re: sendmail....!

Steven Schweda — Wed, 08 Sep 2010 03:00:48 GMT

> [...] Connection refused by [127.0.0.1]

The obvious interpretation of that would be
that sendmail (non-daemon) is trying to talk
to sendmail (daemon) on the local host, and,
as you intended, it wasn't not running there.

> > $S
> mailhost

That seems plausible, however, so the mystery
would appear to be why this sendmail is not
using the expected smart relay ("S").

> # sendmail -v derek.smith@cbc-companies.com > derek.smith@cbc-companies.com... Connecting to [127.0.0.1] via relay...

That certainly looks wrong.

I haven't used sendmail in any serious way
for many years, so I know nothing, but I did
try this on an 11.31 IA64 system here, and
it all seemed to work as expected. Around
here:

> $S
alp-l

dyi # sendmail -v sms@antinode.info
sendmail test from dyi.
.
sms@antinode.info... Connecting to alp-l.antinode.info. via relay...
220 alp.antinode.info V5.6-ECO5, OpenVMS V8.3 Alpha ready at Tue, 7 Sep 2010 22:37:52 -0500 (CDT)

So, on my system, it's trying to talk to the
specified smart relay (alp-l).

> My other hosts do not have this issue.

Is that anything like a _problem_?

Have you compared sendmail.cf (and related)
files between systems? Are you sure that
the sendmail which you are running is
looking at the sendmail.cf file which you
are modifying? (It seems that it should be,
but it also seems to have found a way to use
the wrong smart relay.)

> # sendmail -v derek.smith@cbc-companies.com > [...]

For much more fun, you might try that using
"-d" instead of "-v". Again, comparison with
a working-as-expected system could be
informative. Around here, somewhere in the
mess is the decision to use the relay (after a brief flirtation with "local"?):

[...]
===== SENDALL: mode b, id o87HnixM002647, e_from 0x4006db00=root:
mailer 3 (local), host `'
user `root', ruser `'
[...]
sendqueue:
0x400927b8=sms@antinode.info:
mailer 8 (relay), host `alp-l'
user `sms@antinode.info', ruser `'
[...]

Re: sendmail....!

derek b smith_1 — Wed, 08 Sep 2010 18:55:32 GMT

It was using /etc/mail/submit.cf after looking at truss output.
Does anyone know how the system determines whether to use sendmail.cf or submit.cf?
client/server maybe?

Re: sendmail....!

Matti_Kurkela — Wed, 08 Sep 2010 22:50:13 GMT

In Sendmail 8.13 and above, the /usr/bin/sendmail uses submit.cf and can submit the message to the local queue; the sendmail daemon will do all further processing.

The sendmail daemon /usr/sbin/sendmail uses sendmail.cf, as it has always done.

In Sendmail 8.13 and above, if you disable the sendmail daemon, the email will not work at all. If you want to only send email but not receive them, you must use the "send only" configuration: in that, the sendmail daemon only listens on 127.0.0.1 for local connections from /usr/bin/sendmail.

The idea is to split the previously-monolithic and setuid-root Sendmail into two pieces: the piece that must be runnable by all users (/usr/bin/sendmail) will no longer need to be setuid root, so the impact of any unknown bugs in it will be minimized.

The main sendmail daemon must still run with enough privileges to access TCP port 25 and to write to each user's mailbox; this typically requires that the sendmail daemon is run as root (but with proper user/group permissions applied to /var/mail, it might be possible to have the daemon permanently switch to a lower-privilege userid once started).

MK

Re: sendmail....!

Steven Schweda — Thu, 09 Sep 2010 01:58:01 GMT

> Does anyone know [...]

man sendmail

Look for "ubmi". Apparently, as a daemon it
uses sendmail.cf, and when submitting a
message, it uses submit.cf. But the only
submit.cf I see on my system is in
/usr/newconfig/etc/mail, so I suspect that
mine always uses the sendmail.cf in
/etc/mail (where I recently configured a
smart relay ("S"), so that I could play
around with this problem).

> In Sendmail 8.13 and above, if you disable
> the sendmail daemon, the email will not
> work at all. [...]

Depending on what "disable" means here, my
experience seems to differ. My sendmail
claims to be:

Version @(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006

And it seems perfectly willing to send a
message to the smart relay with no daemon
running:

dyi # ps -edalf | grep sendm
401 R root 4722 4474 1 154 20 e00000014c2aa980 29 - 11:43:03 pts/0 0:00 grep sendm

(Normally it runs, but I've killed it for
this test.)

dyi # sendmail -v sms@antinode.info
Test to sms from dyi, no daemon.
.
sms@antinode.info... Connecting to alp-l.antinode.info. via relay...
220 alp.antinode.info V5.6-ECO5, OpenVMS V8.3 Alpha ready at Wed, 8 Sep 2010 21:43:44 -0500 (CDT)
>>> EHLO dyi.antinode.info
250 alp.antinode.info Hello dyi.antinode.info, pleased to meet you, friend
>>> MAIL From:
250 ... Sender OK
>>> RCPT To:
250 <>... Recipient OK
>>> DATA
354 Start mail input; end with .
>>> .
250 OK
sms@antinode.info... Sent (OK)
Closing connection to alp-l.antinode.info.
>>> QUIT
221 alp.antinode.info Service closing transmission channel
dyi #

And the message is delivered to/on "alp", as
desired. It also works when I run as a
normal (non-"root") user. But, as I said,
I'm not an avid sendmail user, so all I know
is what I read in the papers (or see on my
terminal).

For the record:

dyi # uname -a
HP-UX dyi B.11.31 U ia64 4235313755 unlimited-user license