On Sun, 2026-07-26 at 08:56 -0700, alimiracle wrote: > The `sendmail` interface has served Unix systems extremely well > fordecades, but it was designed around assumptions that modern > service managers intentionally no longer guarantee. Trying to > preserve those assumptions inside increasingly hardened systemd units > feels liketreating the symptom rather than the underlying issue.
> An explicit mail submission service with a well-defined API, > whetherover D-Bus or another IPC mechanism, would provide a cleaner > contract between applications and the local MTA. It would also make > authorization, auditing, and sandboxing much more predictable > thanrelying on `setuid`/`setgid` behavior. You seem to assume the “sendmail interface” requires a local MTA (it doesn’t). > At the same time, I hope any new interface remains MTA-agnostic > andsimple to implement. One of the strengths of the traditional > `sendmail` interface is that applications do not need to know whether > the underlying MTA is Exim, Postfix, OpenSMTPD, or something else. It > would be great if we could preserve that portability while > modernizing the implementation. I don’t think the “sendmail interface” is the problem here, rather than many current implementations of it. Maybe the “sendmail interface” implementations provided by Exim/Postfix/etc. need to implement alternative ways to hand over mails on hardened systems though. Or an independent “sendmail interface” implementation (possibly provided by systemd?) needs to act as a bridge. That said, there might be a good reason to define a more modern API than the “sendmail interface”, but that’s a separate issue (it would not solve issues with existing software using the interface). -- Jan Claeys (please don't CC me when replying to the list)
