On 2025-05-16 08:37, Mutt list wrote: > On 16.05.25 01:31, Kurt Hackenberg wrote: > > If you think this is a mess, you're right. People have tried to fix > > it, but it can't really be fixed. The only good solution is to not > > use mbox, and store mail in other ways instead. > > I've yet to see anything to fix, having used mbox format exclusively > since the 1980s, with mutt since the late 90s. It just effortlessly > works with complete reliability - never a hiccup.
The trouble with escaping is that there are several different standards, some of which mangle the other ones. The following lines have a progressively-increasing number of prefixes prepended: >From me with no prefix >From me with one prefix >>From me with two prefixes >>>From me with three prefixes Assuming program X uses the "only escape /^From /" rule, and program Y escapes any /^>*From /, if they interact with the same mailbox you get data loss. Program X stores that as (indenting to prevent munging): >From me with no prefix >From me with one prefix >>From me with two prefixes >>>From me with three prefixes and now neither X nor Y can distinguish between the first two. And if program Y "properly" escapes them when storing (indenting again): >From me with no prefix >>From me with one prefix >>>From me with two prefixes >>>>From me with three prefixes program X will only un-mung the first one (correctly(ish)) but fail to unmung the other three, introducing new ">" characters that weren't in the original message. Or, if you're like most mail(1) implementations I poked at recently, they don't unmung them at all, meaning they display the escaping ">" characters rather than stripping them. And when message-content gets corrupted, GPG signatures start failing as a side "bonus" :-) It's such a mess. The classic AI, Joshua, summarized mbox well: "A strange game. The only winning move is not to play." ;-) -tkc
