Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Earl Hood]

On Wed, Feb 19, 2014 at 1:44 PM, Paul Vixie wrote:

> i would. first, i'd adopt the messages-as-directories model norm gave,
> since it supports MIME, where our current model does not. by "support"
> i mean i want to use normal UNIX file access to work with my message
> store. there is no file-level access to attachments right now, which
> means i have to run "mhstore" to turn an opaque black-box attachment
> into a UNIX file i can access. mhstore is highly impure by MH's
> overall design principles, even though i'm grateful to have it under
> the circumstances.

I have mixed feelings about this.  Personally, I want the original, raw
email message left alone and always available.  Extraction of
attachments could still be done, but leave the original.  This allows
preexisting email to be reparsed to leverage newer capabilities of the
MUA, or by other external systems (e.g. digital signature verification).

A problem that exists is the definition of "attachment"; it is not
clearly defined in email.  Content-Disposition is supposed to indicate
if something is an attachment, but attachment could be inferred if the
MUA is unable to rendering the entity directly (at a given moment of
time).  So, would it be required to extract each MIME entity to a
separate file, regardless of disposition since one cannot predict how
the user may want to access them at the file-level?

It would cause a lot of duplication of data.

--ewh