https://bugs.exim.org/show_bug.cgi?id=1925
Heiko Schlittermann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #6 from Heiko Schlittermann <[email protected]> --- The problem in sandboxed environment arises because Exim needs privilege escalation to access the spool directories. Using a fallback spool directory (/tmp or some other writable place) doesn't seem to be wise, because independend queue runner processes won't find these spools without additional effort. (And we might get even more security issues.) Delivering the message to a local inet listener should be simple and does not need additional privileges. Unfortunately some Unix tools still need to pass the message via a pipeline into 'sendmail' or 'sendmail -t'. While there exist simple replacements for sendmail (e.g. ssmtp) which just accept the message and deliver it via SMTP to some smarthost, I'd like to see an Exim provided solution. Delivery via the inet socket loses the identity of the sender. If we would install a small non-suid binary as sendmail, taking the id of the calling process (as Exim does currently) and forward the message via SMTP to a local inet socket, we can pass the identity information via the AUTH=.... MAIL parameter. Or - Exim could listen on a UNIX socket. I think on a Unix socket, the server can get the peer identity ((r|e)uid of the connecting process). This way Exim has a trusted source of the sender identity, as it would have when called the traditional way. For this solution we only need an even more simple wrapper 'sendmail', that forwards its standard input to unix:/run/exim.socket. Just some ideas. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
