Linux for system administrators

Glynn Clements | 7 Nov 2009 12:10

Re: sendmail blues

Yuri Csapo wrote:

> Does anybody know how to do one of the following:
> 
> - make the sendmail queue runner expand aliases
> - make the queue runner send to a port other than 25
> - make sendmail behave like in the good old days and forgo the need for the queue runner

Sendmail only uses submit.cf if it exists, otherwise it uses
sendmail.cf. Also, you can force a particular configuration with the
-Ac and -Am switches.

However: if /usr/sbin/sendmail isn't setuid-root (like it was in the
"good old days"), direct delivery (bypassing the submission queue)
won't work for anyone other than root.

FWIW, the rationale behind having a separate MSP is to eliminate the
need for sendmail to be setuid-root; instead, the sendmail binary is
setgid to the "smmsp" group.

When sendmail is invoked by a normal user, setgid-smmsp is sufficient
to add the message to the submission queue. The daemon is started by
root, and runs with root privilege, so it is capable of completing the
delivery process.

BTW, Local delivery shouldn't require that anything is listening on
port 25. However, you may have to tell sendmail what constitutes
"local"; it's possible that sendmail is treating "localhost" as a
normal (remote) domain rather than a local one.

(Continue reading)

headers

Yuri Csapo | 7 Nov 2009 13:49

Re: sendmail blues

Glynn,

Thank you for the thorough answer - reminded me of "the good old days."

Glynn Clements wrote:
> Sendmail only uses submit.cf if it exists, otherwise it uses
> sendmail.cf. Also, you can force a particular configuration with the
> -Ac and -Am switches.

I was not aware of this. I'll do some tests Monday.

> FWIW, the rationale behind having a separate MSP is to eliminate the
> need for sendmail to be setuid-root; instead, the sendmail binary is
> setgid to the "smmsp" group.

I understand the rationale. And I suppose it makes sense these days when 
a lot of people running Linux are desktop users who have no idea and no 
desire to learn better. Sendmail was hit hard in the early days of the 
Eternal September because of this, so they had to do something. OTOH I 
always thought it very silly how everybody runs away from the root user, 
designing mechanisms to prevent its use (i.e. root can't log on to a 
default install of Ubuntu). It ends up turning sudo into Linux's version 
of Microsoft's OK button - people use without reading, understanding or 
caring, compounding the problem. Of course you shouldn't be root for 
your day-to-day tasks but there's nothing wrong with using root when 
that's required. It's a matter of common sense and best practices. Sorry 
for the rant, you just happened to push one of my buttons... <sm>

> 
> BTW, Local delivery shouldn't require that anything is listening on

(Continue reading)

headers

Glynn Clements | 8 Nov 2009 08:13

Re: sendmail blues


Yuri Csapo wrote:

> > BTW, Local delivery shouldn't require that anything is listening on
> > port 25. However, you may have to tell sendmail what constitutes
> > "local"; it's possible that sendmail is treating "localhost" as a
> > normal (remote) domain rather than a local one.
> 
> Local delivery is not what I'm looking for. I want this box to forward 
> along to our smart host.

If it wasn't for the need to expand aliases locally, you could just
use:

	FEATURE(`msp', `smarthost.mydomain.com')dnl

and not run the "normal" sendmail daemon.

If the Sun MTA doesn't use port 587, try:

	FEATURE(`msp',`[127.0.0.1]',`MSA')dnl

in submit.mc and:

	FEATURE(`no_default_msa')dnl
	DAEMON_OPTIONS(`Port=587, Name=MSA, M=E')dnl

in sendmail.mc.

This should force the MSP to send to port 587, and the main daemon to

(Continue reading)