Hide a message?

[Derek Martin]

On Fri, Dec 14, 2018 at 10:53:03PM -0500, Kurt Hackenberg wrote:
> I dislike mbox because it's a bad design, and has many variants that
> are partially incompatible and more or less indistinguishable.

And yet Mutt manages to handle them all flawlessly.  I don't agree the
design is bad.  I would agree that it has drawbacks, and the fact that
historically the various Unix vendors basically refused to ever agree
on anything sucks.  But Maildir also has drawbacks, and DJB sucks in
his own way too.  So does everything.

> In practice, used certain ways, mbox sometimes loses messages.

> Trouble arises mostly when an mbox file is read and written by
> multiple programs, because they might implement different variants
> of it.  

No, trouble arises mostly when two different programs are trying to
write the mail spool file simultaneously, and one or both of them is
doing it wrong.  Reads simultaneous to a single write should never
cause corruption.  Ever.  If it happens, it's because one program has
a critical bug.

The biggest culprit is using mbox on NFS.  You just shouldn't. This
counts as "doing it wrong." =8^)   

This has to do with the inherent tradeoffs of designing a network file
system that is reliable and performant, as much as it is about how
mbox works.  The mbox format predates NFSv1 by on the order of 15
years, so it's hardly fair to blame mbox's design for that deficiency.
It depends on POSIX file system semantics, and NFS breaks them, so...
you either need a different file system, or a different file object
store format.  Or both.  We got both. :)  I haven't looked into how
mbox does on NFSv4 because I still think NFS-mounted mail spools are
dumb for other reasons (like security) so I can't say whether it works
well enough to make using mbox reliable or not.

> Mbox stores multiple RFC 822 messages in a single file.  RFC 822
> doesn't include a way to say where a message ends, so mbox has to do
> that.  Mbox does that poorly, and in many different ways.  That's
> the problem.

The only actual problem is that various Unix vendors contrived their
own solutions to that problem, and rather quite intentionally did not
standardize them.  So, a well-behaved MUA needs to handle them all,
under the assumption you may have used all of them.  It's not hard to
do if you understand them all, and Mutt does that.

> Mbox doesn't mark the end of each message; the end is implied by the
> beginning of the next message, identified by the control line mbox
> puts before each message, which starts with "From ".

Actually it's "\n\nFrom  " (two newlines, two spaces, followed by
whatever).  That matters because it's not normally something you would
put in a message you've typed.  But, your mailer, at least, knows what
you typed.  Ideally it should prevent you from sending such a message,
by using QP or B64 or some such thing.  ">From" quoting is AFAIK not
really used anymore--or at least shouldn't be.  This is a known
problem with known solutions which are not hard to implement.

> Unfortunately, there are many syntaxes for that From_ line.

This turns out to be largely uninteresting, due to much of the above.
After the demarcation of the next message is established (the
"\n\nFrom  " matches) the format is not remotely interesting.

> I'm not saying anything against Mutt. In fact, from my limited
> knowledge, Mutt's implementation of mbox seems pretty solid. The
> problem is the design of the file format, which came from elsewhere,
> long before Mutt existed.

These statements seem largely contradictory to me.  If Mutt has an
implementation that's reliable (it is) and performs well given known
tradeoffs (it does), and isn't overly complex in its implementation
(it's not) then it seems the design is not the problem, but rather
whatever problems you're having are caused by the bad implementation
of what you're using.  Or, you're doing something crazy.

I will grant you that Maildir's design has the benefit of happening
after many years of the pain of dealing with different vendors'
solving the different issues differently, and so it has a single well
defined spec (mbox predates maildir by more than 2 decades).  But
despite that Maildir still does have its drawbacks, some of which I've
already pointed out (or referred to).  It also suffers from a
portability problem that DJB *should not* have gotten wrong: it uses
colons as separators in the name, which is not an allowable character
in filenames on some platforms.

I'm by no means denigrating Maildir; DJB is brilliant and Maildir does
a great job at solving certain problems.  But that doesn't mean that
mbox is bad.

-- 
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20181218/c0fc6afb/attachment.asc>