Last year I wrote xendmail, a tool based on the proposal mentioned in my
thoughts on sendmail in 2023 article. Xendmail exposes the same
interface as sendmail1, it takes an email as input,
reads credentials from the user’s secret store, and dispatches the email via an
the appropriate SMTP server. Xendmail implements the 5% of sendmail that I
need, plus 5% extra which no other implementation offers.
The approach has somewhat worked, but has some issues. The experiment has been a success: it has resulted in useful findings. Xendmail itself, however, is likely not the way forward.
To summarise, my goals with Xendmail were:
- Provide a sendmail-compatible interface for any application to send messages.
- This cancels the need to configure email credentials repeatedly in every other application.
- SMTP credentials are not exposed or resting in plain-text.
- No emails are accidentally dispatched without being aware of it.
- Enable non-root users to configure the setup, so it is feasible on shared hosts.
These goal were well met, but additional requirements should have been in scope too…
Problem 1: Not offline mode or outbox
Usually I write an email message (or prepare a git patch) and then hand it over to xendmail, which sends it out immediately. Whenever there is no internet connection available, xendmail outright fails, and I have to figure out what to do with the message myself. I usually save it into drafts and need to remember to manually dispatch it later.
The solution for this issue would be to save messages into a local outbox, and have it dispatched later when I am online again. This is pretty much what old-school monolithic email clients did.
Problem 2: Poor integration with automated emails
Not all emails are prepared manually: Tools like rss-email2, prepare
emails automatically and attempt to dispatch them.
Xendmail tries to use the secret store to read the SMTP credentials, which results in the secret store prompting for user consent before disclosing credentials. This results in random interruptions during the day.
I have considered an approach where xendmail has some form of privileged access to the secret store and can read serets without my approval, but have decided against the idea. Aside from a lot of complexity issues, any misconfigured or misbehaving client can start sending out unwanted emails without indication.
It is clear that xendmail, in its current form, is a bad fit for this type of automated tools.
Using something like opensmtpd
The idea of putting emails into an queue and dispatching them later when network is available again is nothing new. Classic SMTP servers to exactly this.
There are mainly two obstacles with locally running a classic SMTP server like
opensmtpd or alike:
They need to be configured and executed by the root user. The whole point of these experiments is to find a solution where each user can configure their own email on a system with no root access (e.g.: on a shared machine).
Credential management is still an issue. There are two possible approaches:
- If the locally running SMTP server requires a password, then automated tools cannot queue messages without unexpected interruptions.
- If credentials are stored in plain-text form or don’t require user approval before access, then misbehaving processes can send out messages without limitations (and without any awareness of it).
The first of these items (requiring root for configuration and operation) is enough to make this approach non-viable for the given goals.
Future endeavours
Based on these learnings, I’m still thinking of the next approach to try. For the moment, key observations are:
- Try sending an email, and save it into an outbox maildir if sending fails.
- A status bar indicator with the amount of messages in queue.
- A simple UI to review the outbox and send all messages.
I will continue using Xendmail for the time being, but my intent is to eventually deprecate it in favour of one or more tools that can fit this description.