Re: [Exim] Exim v4 - thoughts

Top Pagina
Delete this message
Reply to this message
Auteur: Philip Hazel
Datum:  
Aan: Phil Pennock
CC: Exim Users
Onderwerp: Re: [Exim] Exim v4 - thoughts
On Tue, 2 Jan 2001, Phil Pennock wrote:

> Do people like these? More importantly, do _you_ like them Philip?
> Or are they even more upheaval than you were wanting?


They are a bit more upheaval than I was wanting. But all suggestions are
useful because they cause me to think.

> We now have LMTP, SMTP, SMTP/TLS for incoming mail. All potentially
> listening on TCP ports, each different.


We don't have LMTP. Exim supports only outgoing LMTP. As I understand
it, the use of SMTP/TLS on a separate port is not the "official" way to
do TLS (one reason being that you can't log the TLS parameters).
However, I do take the general point about different ports.

> Perhaps Exim needs something analogous to routers, but for incoming
> mail?


The thing about incoming mail is that either you need a separate process
that is listening (the daemon), or you fire things up from inetd. Either
way, you can already have a separate Exim with a different configuration
for each port. I'm not sure we need anything more.

> If the only need for the setuid bit on the binary is for getting stuff
> to the local queue, is it possible to re-architect around this? Not
> having the daemon binary setuid would make me inordinately happy.


You can already have the binary not-setuid. See the comments in the
manual about "security = unprivileged". However, you lose the ability to
do local deliveries as an arbitrary user. You also lose the ability to
HUP the daemon (the list of restrictions is documented).

> Option 1, less preferred:
> For cases where there's a daemon, perhaps LMTP should be the default for
> message submission.


Why? Exim has queuing facilities. LMTP is for things that accept mail
which don't. If Exim says "yes" at RCPT time, it isn't going to want to
say "no" after the DATA phase.

> But I would really be much more comfortable with no setuid-bit on the
> main program binary.


If you can live with the restrictions that this imposes, you can do this
already.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.