[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim

From: Robert Elz
Subject: Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.
Date: Wed, 24 May 2017 03:26:07 +0700

    Date:        Tue, 23 May 2017 09:35:52 +0100
    From:        Jon Fairbairn <address@hidden>
    Message-ID:  <address@hidden>

  | One of the first things I learnt was that
  | using in-band data as a separator is a bad idea,

Like most generalizations, that is sometimes true, but sometimes not.

  | so mmdf was obviously a more sensible format than mbox.

Which doesn't follow at all, as MMDF is also using in-band data as
a separator, just a different one.

I never really used MMDF format, so I am not sure of its details, but
as I understand it, the only real issue with mbox format is that the
conversion isn't invertible, that is, in that format, a line that used
to start "From" is stored as ">From" (which exact lines that happens to
depends upon implementation to some extent, but that doesn't matter),
whereas an input like that started ">From" is also stored as ">From".
When it comes time to extract the message, there's no way to invert that
addition of the '>' as there's no way to determine whether the '>' was
one that was added for this purpose or not.

If the mbox encoding format had been properly designed, rather than just
a "we need some way to fix the problem that a line starting 'From' in
a message acts like a separator" (which was a real issue/bug in early
implementations of it) this issue wouldn't arise.

There was one attempt to use (essentially, though as I recall, not quite
implemented that way) out of band data for mail collection files - that
is, adding a header and length field (much like tar format, or cpio, etc,
but much simpler) but which was a spectacular failure, and hated much more
than '>From' (which is mostly an annoyance, though it does screw integrity
checking).  It failed as the messages were still text files, and people
like to edit text files - an in-band separator mechanism isn't affected
by that, but a length field of some kind, which is what an out of band
mechanism requires usually, is, and mangled e-mail archives were far too
frequent with that mechanism.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]