‹ back home

Nine months of Xendmail

2024-01-16 #email #open-source #status-update

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:

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:

  1. 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).

  2. 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:

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.

  1. Plenty of applications and libraries support sending emails via sendmail, so using its interface enables easy integration with all those tools. ↩︎

  2. rss-email reads remote RSS feeds and generates an email messages for each new entry. ↩︎

Have comments or want to discuss this topic?
Send an email to ~whynothugo/public-inbox@lists.sr.ht (mailing list etiquette)

— § —