[ Please CC me in on replies -- I've had to unsubscribe from the list ]
Below are some thoughts I've had for Exim v4. They're my personal
opinion, not my employer's, yada yada ...
Do people like these? More importantly, do _you_ like them Philip?
Or are they even more upheaval than you were wanting?
Accepting mail
--------------
We now have LMTP, SMTP, SMTP/TLS for incoming mail. All potentially
listening on TCP ports, each different.
Perhaps Exim needs something analogous to routers, but for incoming
mail? (Below, named 'widgets')
And widgets separated out from the main config, to a new section?
If you can specify the IP address for each widget, then you could have
different widgets listening on different network interfaces -- perhaps
useful for a firewall. And then the new accept_recipient stuff might be
a function of the widget, which would simplify the checks for
"TLS or this". Particularly if the widget which accepts SMTP has the
ability to throw processing to a different specified widget if
authentication is attempted.
Message-scanning is also something which might be defined per widget.
So there'd be widgets, corresponding to routers, and then widget
protocols, corresponding to drivers? Is there a need to something
analogous to transports? Am I missing something major here?
Security
--------
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.
Option 1, less preferred:
For cases where there's a daemon, perhaps LMTP should be the default for
message submission. And then use a small MTA for remote-delivery-only
on systems without a daemon?
Option 2, more stable and portable:
Move Exim itself to be eximd. Give it its own options for invocation,
etc, and NOT setuid. Have a small and tight setuid wrapper, called
exim, which can be invoked as sendmail with all the stuff that implies.
The wrapper does the necessary checks and changes, and execs eximd.
Perhaps some of the clean-up code for things like Bcc: headers, etc,
could be in here, perhaps not -- I personally favour keeping the wrapper
as small as possible, once it has sanitised what needs sanitising.
But I would really be much more comfortable with no setuid-bit on the
main program binary.
Feedback and criticism appreciated,
--
#!/bin/perl
seek main::DATA,0,0;print while(<main::DATA>);__END__
