‹ back home

Thoughts on sendmail in 2023

2023-03-30 #email #open-source

Sendmail is a classic mail transfer agent (MTA) in the world of Unix-like systems. It’s design is simple, and worked well for many setups for decades. For many scenarios it still works. For others, it does not.

Sendmail as a system-wide tool

Sendmail is typically set up by a system administrator and configured to relay emails from any local user via some administrator-defined mechanism. This doesn’t play well with typical multi-users systems as we see today, especially if they each have their own different mailbox providers and accounts. One user might want their email to be sent via their provider, example.com, while another user uses another-example.com for their email services.

Even for single-user systems, sendmail needs access to the credentials to forward emails via the user’s email account. sendmail is then exposed to all processes of the local system. So a developer working on and running an application that sends emails might accidentally start sending emails via their own account – without any prior confirmation. The same is true for misbehaving programs and it’s an incredibly juice target for exploits.

However, many tools have come to support simply running sendmail to send emails, so maintaining its interface is quite valuable.

We can do better

The solution should start becoming obvious by now. A new tools is needed with a few specific requirements.

First of all, it needs to be per-user configurable. So each user can specify their own email provider and credentials and have their messages relayed through it.

In second place, the tool needs to prompt the user for some for of confirmation before sending emails. This feature is very easy to get for free: assuming that the tool relays emails via an SMTP that requires authentication, it will have to read the credentials from the user’s secret store. The secret store should prompt the user before disclosing credentials, at which point the user has the opportunity to confirm granting access to their SMTP.

Finally, the tool should retain the same API as sendmail(8), so any other program that usually works with sendmail will work with this replacement.

Have comments or want to discuss this topic?
Send an email to my public inbox: ~whynothugo/public-inbox@lists.sr.ht.
Or feel free to reply privately by email: hugo@whynothugo.nl.

— § —