Martin Burgraf writes:
I don't know why you would consider a background process inferior to a run-on-demand executable.
Well, the background process is hogging CPU and RAM while it basically does nothing.
"Hogging" CPU and memory is putting it strongly, as it is basically suspended while blocked on waiting for a connection, and if left for a long time in an idle state, might be swapped out to disk and not consuming (real) memory, or consuming real memory that isn't in use otherwise.
As I stated before, the resource usage is small compared with all the other stuff going on, so if you don't have a busy mail server, I don't think you should sweat the difference.
The benefits of LMTP should increase with load, as having LMTP resident will save you the overhead of repeatedly loading/unloading LDA, and I'm sure the CPU and memory usage of servicing that overhead will be non-trivial. If you have oodles of memory, then it's no problem keeping a LMTP resident. If you don't have enough memory and are VM disk thrashing, you'll have other problems and LDA/LMTP is the least of your worries.
And when it's running as root there is always the danger of privilege escalation. LDA only runs when it's needed and since it uses only user rights it shoudbe more harmless.
I didn't contest the privilege separation aspect, as it a necessary design trade-off that one daemon doing things for all user will need overriding access. However, if this is a concern, you can virtualize all your users. LMTP can theoretically be subverted, but at least won't be as root. (I'm assuming LMTP stays as root, and not spawning off user processes to do the real work.)
Joseph Tam jtam.home@gmail.com