Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [really non-ASCII message bodies ]

[Jon Steinhart]

> Even for attachments, as I understand it, that's keyed off a pseudo-header
> added to the components file (and so appears in the draft), right?   Do we
> really need a switch to enable that.   I'm (again) all for backwards
> compatability, but is there any serious believe that people are really
> adding "Attachment:" (whatever it is, "MH-Attach:" might be better) headers
> to their messages and expecting that to be delivered?    And yes, I know
> non-standard headers are OK, but we have non-switch-enabled locally invented
> headers used for this kind of purpose already (like fcc) - another,
> expecially if given a MH specific name, should be harmless.  It would be
> simpler to just do the processing and not require a switch (switches that
> we more or less tell people that "everyone should have this in their profile"
> are just dumb...)

Let me explain how the code works here.  There needed to be some way track
attachments for a draft between programs because of the modular nature of
nmh.  I suppose that I could have used a shadow file, but instead I used a
legal "X" header.  However, there is no way that I could 100% guarantee that
any X header wouldn't collide with something that some user was doing since
that namespace is uncontrolled.  That's why the name of the header that
tracks attachments is settable.

All attachment headers are stripped off by send before the message is sent.
Send examines the headers and changes the draft into a MIME message that
includes the attachments specified by those headers.

I can see where one could claim that this approach was overkill and could have
just been hardwired.  This was my first contribution to nmh and it was a rather
large change in functionality.  It was clear from reading the mailing list that
breaking things was bad, so I went about this in a safe way.

Had I received this input a decade ago I might have done things differently.
But, I didn't.  I am aware of users with custom environments who build drafts
with these attachment headers.  I don't see anything so compelling in changing
the name of the header field name that it's worth breaking things for these
users.

It's done.  Hindsight is wonderful but at some point you gotta let go.

Jon