Kurt Hackenberg wrote in <[email protected]>: |On Mon, Aug 25, 2025 at 01:51:53PM +0200, Steffen Nurpmeso wrote: | |>No, i love MBOX, the thing is that this MBOX quoting of all kind |>is unnecessary if the messages are MIME encoded, *if* the MIME |>encoding takes care for ^'From ', which i think practically all |>do. | |Practically all? No. | |The only MIME protection against future mbox damage is part of the MIME |type text/plain format=flowed (RFC 3676). Few mail readers even |implement that type.
That is not correct. Has nothing to do with that, only with the content-transfer-encoding. The only problems i encounter are open source developers which insist on NOT using MIME at all. But normally, i am pretty sure mutt also acts like that, if you let it, a From_ line (or, more likely, any "^From " regardless) causes a c-t-e to kick in, likely quoted-printable. Only if c-t-e is consciously unavailable MBOXO quoting is used (the >From that can still be seen, or the " From" that ezml seems to have produced.) -- i know of no other occurrance, nowhere. |>So RFC 4155 is a great database format in conjunction with MIME |>encoded emails, especially for long time storage of constant data; |>or for "normal" emails and append-only. Completely unambiguous. | |Nope, sorry. MIME doesn't help, and RFC 4155 has a problem. Its default |format, the only one it defines, defines the From_ line rigidly, |forbids ">From " escaping, and does not use a length. It says messages |should be found by recognizing the whole From_ line, with exact syntax. Yes. It came after MIME, and with MIME you *will* apply a c-t-e, and if only to avoid (non-MBOX-related, too) From->>From alone the message path. One reason why for example PGP or S/MIME enforce a c-t-e, only with it reproducibility can be assured. |That fails when the message body includes such a From_ line, as it |might when people use email to discuss mbox format, as here. Like this |(except indented here for safety): | | From [email protected] Thu Jan 1 00:00:00 1970 I am sure mutt would not let you send this "as is", unless you configure it not to have the option to apply a c-t-e (if that is possible: it has been about 13 years i stopped using it, and fiddling with its config thus). |An RFC 4155 reader would take that line above as the beginning of a new |message, and would fail to read the rest of this message. | |Furthermore, RFC 4155 is yet another incompatible variant of mbox, |which adds more confusion. No no, .. not. |And there's another problem: the IETF defines only network protocols. |It declares that whatever happens locally, within computers, off the |network, is beyond the IETF's scope. That local action includes file |formats, of course. You are very much mistaken, the IETF even manages "media types", including file extensions. |RFC 4155 was a trick, an attempt to sneak in a file format definition. |It claims to define only a MIME type, not a file format, but clearly |you think it defines a file format. | |Fortunately, far as I know, RFC 4155 has never been implemented. It has. At some later time, when i live long enough, not only for newly created messages. But, eh, this thread becomes off-topic in that i would be interested about any thought regarding this very devilish email and the fact that mutt recognized ^From_ directly after an empty header continuation line that is *not* an empty line. --End of <[email protected]> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
