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.
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.
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 nobody@nowhere.invalid Thu Jan 1 00:00:00 1970
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.
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.
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.
