> I wouldn't bother searching any further -- mailbox formats are generally
> (and IMO wrongly) regarded as outside the scope of RFCs and suchlike.
> ...
> I certainly agree that it should be documented, however.
qmail sites usually document quite particular. Their mbox(5) page speaks
of formats: mboxo, mboxrd, mboxcl, mboxcl2. As does mutt's mbox(5).
However, that's regarding 'mbox' formats... not 'Maildir', which is strictly
one message per file, where such headers like 'content-length'
and 'lines' have no reason to apply that I know of from searching so far.
I think we're looking at, minimally, a need for copy.c, copy.h, mbox.c,
parse.c, sendlib.c ... to know that they're working with Maildir and not
modify mail in that case. I say 'minimally' so as not to intrude the
Maildir space fully across mutt if it thinks it was designed to use mboxcl
for mbox space.
parse.c knows it's redundant :)
/* ignore the length given in the content-length since it could be wrong
and we already have the info to calculate the correct length */
> What happens if you chmod a-w them? I sympathize with the crypto hash
> change problem, but there are other ways of protecting your files.
Who knows. What if you chflags uchg them and run mutt as root :)
And doing some of these things would prevent the user from rightly
sorting/using their mail.
We shouldn't have to resort to protection antics... don't touch my
files... it's the principle of the thing.
> Huh? "Open source" shouldn't do it? Either it's good practice or it's
> bad practice; whether the source code is freely available or not seems
> immaterial to me.
Yes, of course it's all bad, and neither one should be modifying your files.
Though we somewhat expect, or are used to, closed source / commercial
doing these kind of silly gratuities. We also expect the open source unix
world to not do it. It's the principle again. It's like the 'Lines: ' header,
there's no reason to add it under Maildir.
With Maildir, I tend to consider any MUA that stores a message on disk
differently than it was received over the wire (or read from disk) as broken.
And it can cause problems later when you have x MUA's from y users
making z of their own changes and you go to convert archives from Maildir
to Mbox or the other way. It's just better not to modify the mail you were
given unless instructed to... 'import your mail [y/n]?' ... n :)
Ignore test data below...
>From foo
>From foo
from foo
>from foo
