On Mon, Aug 25, 2025 at 01:51:53PM +0200, Steffen Nurpmeso wrote:
> |>Thing is that RFC 4155 is lala...
> |
> |Correct. That RFC should be ignored.
>
> Mumble mumble!!! It defines the MBOX DB format.
Sorry, it does no such thing:
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Now, it does define *A* (not *the*) MBOX DB format, which it wants to
consider the default; however since it doesn't define a standard, and
there are already numerous decades-old implementations of mbox in the
wild, all of which this *informational* RFC are at odds with, RFC 4155
is completely bunk.
> 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
This is also clearly not correct.
Abstract
This memo requests that the application/mbox media type be authorized
for allocation by the IESG, according to the terms specified in RFC
2048. This memo also defines a default format for the mbox database,
which must be supported by all conformant implementations.
It does indeed define a file format. It's just that the file format
it defines is basically worthless, given the many millions of lines of
code and probably also millions of users which employ a long-standing
alternative implementation. It's too much to ask for all of the
authors of all of the mailers in the world to rewrite their software
to comply with one random dude's idea of how an on-disk file format
should work.
All that said, I too am (still) a fan of mbox. I read Kurt's blog
post and emphatically disagree with its premise--that mbox has a
design flaw. You can't have a design flaw without a design! =8^)
Not one that's standard, anyway.
[Actually, I find many of the concerns raised in that essay to be
factually wrong, though that's largely beside the point.]
IT'S THE PURVIEW AND PREROGGATIVE OF THE MAIL APPLICATION (AND ITS
AUTHOR) TO USE WHATEVER FILE FORMAT IT LIKES, STANDARD OR OTHERWISE,
VARIANT OR OTHERWISE.
So long as an application implements its file format correctly and
consistently, it will work fine. The fact that there are alternative
variants is not a flaw... it's just an inconvenient incompatibility.
If you feed it incompatible data, then You're Doing It Wrong!™ The
file format is not to blame for user error.
You can certainly argue that the application should be more robust and
user-friendly, by accepting more of the well-known variants of its
chosen format (if they exist, as with mbox); but unless you're willing
to write the code to do that--or perhaps to pay someone else to do
it--it's really not your call to make.
As a practical matter, the "bad messages" discussed in the first post
in this thread are obviously broken, completely worthless, and do not
deserve any further consideration beyond "Don't do that." If you have
other software that's generating such mboxes, it is those that are
broken and need to be fixed or replaced.
Mutt's been around for over 30 years now, as have I been on this
mailing list, and in that time there have been very few reported
issues with Mutt parsing mbox files. Not none--but not so many. In
practice this isn't nearly as problematic as Kurt makes it out to be.
If you know how the major variants work, and the mail agents you are
trying to interoperate with are well behaved, you can hueristically
guess which one is in use the overwhelming majority of the time. if
yours is not well-behaved, then... don't blame Mutt for that. There
ARE limits to how far even the most well-meaning authors can go to
ensure compatibility.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
