sendmail....!

[Patrick Wallek]

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

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

[Jim Walls]

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.

[Steven Schweda]

> [...] 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 `'
[...]

[derek b smith_1]

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?

[Matti_Kurkela]

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

[Steven Schweda]

> 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