Derek Martin wrote in
<[email protected]>:
|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
a-ha. Well...
|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[.]
|> claims to define only a MIME type, not a file format
This does not quote what i said, just to point that out.
...
|This is also clearly not correct.
|It does indeed define a file format. It's just that the file format
a-ha.
...
|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
No. In fact Dr. Fink was absolutely right in pointing out that
all these implementations have always been wrong, since the email
standard requires 1+ (actually 2+) header fields to occur in
a valid email, and therefore it becomes possible to code something
pretty fine out.
But, as you say, there are implementations like git's
#?0|kent:git.git$ git show master:builtin/mailsplit.c
by Linus Torvalds which goes
* Totally braindamaged mbox splitter program.
and
/* Ok, close enough */
But *he* is at least honest. Right?
Anyhow shall i ever find time (boy) i will finish the hack i begun
and goes
+ n_PROTO_SMBOX, /* Like _FILE, but "simple" (everybodies') From_ discovery
*/
and then we will henceforth read MBOXes in a way that detects both
variants as it goes, and hints the user to the new smbox://
protocol in case of ambiguities, which will then give compatible
behaviour to git-mailsplit and mutt etc.
However this codebase is still based upon two distinct codepaths,
and does not have the great objects of mutt, and therefore we
cannot simply reencode MIME parts as necessary when saving
a file:// aka mbox:// *not* as a smbox:// etc etc. More years.
|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.
No. This is .. ah, just wrote it shortly ago
Your signature does not protect (see for example the "noxxi DKIM
attack" [1]), especially since in the email arena "the Postel
approach" is in use, and really has to be because of decades of
complicated / bogus / adjacent standards, with all the bugs, false
interpretations etc etc etc (of course you know very well),
^ That.
which means that even though some RFC may say "there must be
only once instance of field X", a second actually is ignored,
and then it depends upon the software which one is used; "if it
is the second", your DKIM does not protect it; ..
|All that said, I too am (still) a fan of mbox.[.]
Yes i am. I also have to, because the MUA i maintain does not
have that "native Maildir" support that mutt has, but actually
requires anything to be sucked into a temporary MBOX first, which
is ... hard.
|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^)
Sure. But since 1996 there was MIME, and it actually was
a follow-up of something elder, so at latest then the actual
problem, even with programs like git-mailsplit interpreting the
output, was avoidable.
|Not one that's standard, anyway.
...
[i reduce a bit..]
|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.
Ok; but .. it was not a MBOX initially, you know, it was just
an email sent to some mailing-list. It could have ended up in a
Maildir file, yet here it did not!?!? It broke a lot of modern
programs, for example public-inbox, which i *think* stores in
SQLite? (I have no idea really though, no LMDB in INSTALL
mentioned :(.)
|i wrote the from headers by hand, instead of setting upasname out of \
|laziness.
|it seems that doesn't work very well.
...
hm, it seems to simply be an attachment?
Anyhow *that* public-inbox got totally wrong, it is shown as
a message by itself.
...
ok, but the one message as such is not in public-inbox *at all*.
Message-ID [email protected] i for one
do not see anywhere around.
...
Having said all that myself, all that is just one more hopeless
case. Btw, what do you think of message/global? I have that
SMTPUTF8 blues in at least one ear all the time, and Viktor
Dukhovni is right when he refers to i18n of local-parts,
yet... you know?
...
--End of <[email protected]>
[sorry for the contraction]
--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)
