[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: Steffen Nurpmeso
Subject: Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.
Date: Wed, 24 May 2017 14:58:08 +0200
User-agent: s-nail v14.9.0-pre4-80-gae58644a

Robert Elz <address@hidden> wrote:
 |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.

It seems it has been simply be carried along from original Unix
mail storage, and never has been properly adjusted thereafter.
POSIX also standardized this loose format which was in use since
that beginning.  RFC 4155 defined a more proper format.

In the end MBOX is just a database format, the MUA i maintain uses
a MIME content-encoding to ensure the assertion of this format is
not contradicted, but we do not yet re-encode messages like that
when copying over, for that we have to perform proper From_
quoting as necessary, then.  This is a huge pile of cr.p.  Still,
using RFC 4155 rules for one lowers the possibilities for database
format clashes, and may give surprises due to different detection
of message boundaries, our upcoming version will warn when opening
mailboxes where this could be a problem.

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

Jamie Zawinski of Netscape+ on that[1] is pretty famous:

  [1] https://www.jwz.org/doc/content-length.html

 |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

My MUA strips those because it doesn't manage them, unless the
variable *keep-content-length* is set.  I think i have to obsolete
this, and at some future time either silently drop or fully
support them.  But they are redundant if messages are
content-encoded, and in times of digital signatures etc. you need
to make sure that user input is identical to output anyway, so
proper content-encoding is the right thing to do.

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

reply via email to

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