The Linux mailing list had an admonition for Mutt users to fix their Mutt configuration. A recent change to that otherwise popular e-mail client has broken the way Message-ID headers are formed in Mutt. The developers have proven unwilling so far to fix it, therefore the onus falls upon Mutt's regular users to make local reconfigurations to avoid breaking the mailing lists and archives they might be participating in.
At some point in the recent past, mutt changed the way it generates Message-ID header values. Instead of the perfectly good old way of doing it, the developers switched to using base64-encoded random bytes. The base64 dictionary contains the / character, which causes unnecessary difficulties when linking to these messages on lore.kernel.org, since the / character needs to be escaped as %2F for everything to work properly.
Those receiving Mutt-generated messages will thank you for it, even if silently.
Previously:
(2018) (Neo)mutt F***ery with Multipart Messages
« Pluralistic: This is Your Brain on Fraud Apologetics | Expectant Lemur Dads See Hormonal Changes in Response to Pregnant Mates, Poop Shows »
Related Stories
Mutt and Neomutt users now have a trick available in their toolbox to mess with senders who try to embedd web pages in their e-mail. A guide entititled (Neo)mutt fuckery with multipart messages walks through the steps to get either client to turn regular e-mails into MIME multipart messages by tacking a lame message on as text/html.
I've been using Mutt, and then Neomutt, as an email client on my laptops for a while (I generally use Evolution on my desktop, because it runs on GNOME, while the laptops run on i3wm). Today while talking with colleagues who also use a TUI, text-only email client, we realized we had one shared pain about this, which was receiving multipart emails where the text/plain part was either the HTML source of the text/html part or a single line saying "This email has no plain text version, refer to the HTML version" (If you don't know how multipart emails and MIME work, wikipedia has a good primer).
We thought it might be fun as retaliation to send multipart emails, with the text/html part saying "This email has no HTML version, please refer to the plain text". An hour and a few curses at mutt's documentation later, I'd come up with this solution: [...]
[...] P.S.: I know I shouldn't have to say this but please don't actually use this to annoy people who use graphical email clients. We're the weird ones, basically everyone uses a graphical email client, and they're clearly the standard now, plus it's clearly a dick move to do this. Please refrain. Thank you for your understanding ❤️
(Score: 3, Interesting) by darkfeline on Monday March 06, @03:30AM (3 children)
I checked the RFC, and slashes are allowed in Message-ID.
Still, that is a poor attitude for a maintainer of an email client, which is perhaps the most critical software that needs to maintain compatibility with the myriad other implementations in existence.
If the maintainer of your email client doesn't care that your emails break when sent to certain (prominent) destinations, well, you may as well Russian roulette all your messages to /dev/null, or better yet, not send them in the first place, since it isn't important that your messages get received at all.
Join the SDF Public Access UNIX System today!
(Score: 4, Informative) by coolgopher on Monday March 06, @04:01AM
If one follows the "uninterested in" link, one finds out that there is in fact someone on the mutt end who cares and is hoping to get a fix merged in soon.
(Score: 3, Insightful) by GloomMower on Monday March 06, @07:06AM (1 child)
Seems like it should be an easy fix for lore.kernel.org
(Score: 5, Insightful) by pTamok on Monday March 06, @09:39AM
I agree.
If mutt is following the relevant RFCs, then it is the downstream service that is not RFC-compliant. It may well be a big (possibly even practically impossible) job to change the downstream software, but asking (or sometimes, demanding), that somebody else break the rules for your convenience is at best, impolite.
(Score: 1, Insightful) by Anonymous Coward on Monday March 06, @03:36AM (2 children)
I've used modified Base64 with stuff like Replace("+", "-").Replace("/", "_") or similar for various stuff.
Is that so hard for the Mutt developer(s)? I mean they've clearly run out of more important things to fix right so they should have time for this.
(Score: 3, Interesting) by janrinok on Monday March 06, @06:17AM (1 child)
Like many bits of software that are written outside of the commercial world there is always the temptation to tinker with it to improve its functionality or appearance often in a trivial and unnecessary way. As you rightly point out - there cannot be many significant bugs lurking in that code after all of these years.
Perhaps this is simply one of those moments when the unnecessary but hard to resist tinkering breaks something else. At least he now has a significant bug to work on.
(Score: 2) by isostatic on Monday March 06, @08:07PM
Like many bits of software that are written outside of the commercial world
And far more inside. You don't get recognition, promotions, bonuses or job satisfaction for maintaining someone else's code. You get them for creating or rewriting software to do the same function in a slightly different way.