I think I agree with the direction Simon is describing.
The `sendmail` interface has served Unix systems extremely well for
decades, 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 like
treating the symptom rather than the underlying issue.
An explicit mail submission service with a well-defined API, whether
over 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 than
relying on `setuid`/`setgid` behavior.
At the same time, I hope any new interface remains MTA-agnostic and
simple 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.
على 7/26/2026 8:34 AM، كتب Simon Richter:
Hi,
On 7/26/26 18:29, Andreas Metzler wrote:
Can we create a systemd service that sends a mail, and has its own
lifetime
and permissions?
afaiui the important thing when interacting with a local exim is to
*not* submit mail from a systemd service via the /usr/sbin/sendmail
interface. This avoids having the exim and the respective service in the
same cgroup. Submitting by smtp should work avoid this.
/usr/bin/sendmail is a Unix interface.
It assumes Unix semantics:
- runs as the calling user
- has access to the user home directory
- additional privileges are defined by the sysadmin through setuid.
The distribution provides a default
- background tasks can linger
Systemd explicitly does not want to follow Unix semantics, so we
cannot assume that Unix semantics will hold unless there is an
explicit mechanism for them, and we are seeing breakage precisely
where we're using a Unix tool inside a non-Unix environment.
The answer to that isn't to hack something to restore enough of the
Unix semantics to make it work for another release, but to explicitly
define an interface that does not rely on implementation details of a
non-hardened environment, because that is not supportable.
So: if there should be a way for a program to send mail, there needs
to be a dbus service, with proper authorization through the policy
framework.
Simon
