UTF8 email with DMA: DragonFly Mail Agent
7 points by jummo
7 points by jummo
I like the idea of using a wrapper to add features or fixes to an existing command.
The more I think about the problem, the more I wonder whether responsibility for providing a Content-Type header lies with cron or dma.
dma(8) describes itself as "a small Mail Transport Agent (MTA)" that "accepts mails from "locally installed Mail User Agents (MUA)." cron(8) describes itself as sending any output produced by the command it runs "to the user specified in the MAILTO environment variable" which suggests it considers itself an MUA.
I briefly looked through a few email RFCs before realising that I know far too little about email to quickly learn whether responsibility for generating a Content-Type header belongs with an MUA or MTA, although I would assume it's reasonable for an MTA to expect an MUA to handle this.
Rather than patching dma — which is a bad idea on a system you want to keep auditable — the solution is a small POSIX sh script installed as the sendmail binary
This also got me thinking about open source software and what "auditable" means here. Open source software comes with no promises or restrictions, so if the author wants to write a wrapper around it, that's their choice. But there's always the option of patching it or opening a bug report.
I have worked with several developers who respond with surprise when I suggest we fix the limitations we find in open source software, wondering if it's acceptable for them to do so. I have worked with developers who despair that their patches or bug reports seem ignored, but don't engage with the maintainers or offer help beyond that, not appreciating the community nature of many open source projects.
What I write here explores my experience of situations like this, not to criticise the author of this article, who I congratulate for solving their problem elegantly and sharing their solution.
I wonder whether responsibility for providing a Content-Type header lies with cron or dma.
Traditionally, sendmail (especially sendmail -t) (whether implemented by Sendmail or another MTA) is responsible for all the message submission header fixups, such that you can edit a message by hand and submit it without having to pay much attention to all the standard requirements. The fixups go beyond what is possible with message submission over SMTP, because sendmail can take care of constructing the envelope (handling bcc) and converting unix usernames to email addresses and display names. Since it also knows the user’s LANG / LC_CTYPE it can also (in principle) fill in the MIME headers if they are missing.
For historical reasons it probably does not, but I think it should because that fits in to how message submission traditionally worked. Messages from cron are a weird but pretty good example of something that emits a bare minimum of message headers and expects sendmail to sort out the details.
(Message submission over SMTP requires the client to do much more of the message prep work than sendmail; a submission client can expect the server to fix Sender: based on the authenticated user and add a Message-ID: but that’s about it.)
The historical reasons for not adding MIME headers based on the locale are roughly that in the 1990s a bunch of alternative MTAs cloned the sendmail command interface and turned it into a de facto standard. That happened when it was reasonable to assume a C locale and/or that just-send-8 would work OK. When UTF-8 started to become common, getting sendmail to add missing MIME headers was a difficult collective action problem that required coordination between many MTAs.
It’s the kind of thing that an operating system such as Debian or FreeBSD could (and certainly used to) implement by policy: patch the MTAs where necessary, on the basis that it’s worth making this corner of free software better right now and let the rest of the world catch up at their own pace.