ph10@??? (Philip Hazel) wrote on 03.01.01 in <Pine.SOL.4.21.0101031127580.7326-100000@???>:
> 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.
The point would be to keep that in one config file, since (presumably) it
would only differ in the message accept phase.
I see the different accept method list somewhat different:
* SMTP on port x (for any x that's needed), with or without TLS - with
STARTTLS, it's optional anyway
* -bS (rsmtp) input
* -bm + From_ (UUCP rmail) input
* -bm (sendmail) input
* -bs (SMTP bidirectional pipe) input
* possibly selected by some new command line option
The relevant options would be mainly options specific to one type of
message source, such as host-IP-based options for SMTP-on-a-port or
trusted users for messages-from-piping-to-Exim, possibly also different
sets of rewriting rules - I think that's about it, everything else should
be global or really handled with a different config file.
Sort of inverse transports. Maybe "injectors" or "acceptors" would be a
usable term.
An UUCP acceptor could then be configured to, for example, use UU_MACHINE
and UU_USER (badly documented) environment variables when called from the
UUCP user (and refuse to talk to other users), whereas other acceptors
would ignore them.
(Incidentally, it seems we currently have no way to get at the
environment. Looks like it should be easy to create a string expansion
item for this, say ${env:UU_MACHINE}.)
