Re: [nmh-workers] Can't forward MIME-encoded message

[DuaneTime]

(list mod: if this message isn't suitable for the list, please delete it; I 
copied Mr. Hornstein with it externally)

> When you say, "Forward", what EXACTLY do you mean?

Yeah, no kidding...  could be a bunch of things.

I "Drilled Down" to the lowest possible level...  I have a *file* with the 
message to be forwarded in it, and use "comp -file xxx -use", edit the message, 
and then "push" it out.  (Yes, that's no different from just composing a 
message, except that in this case it's got the "Content-type" header in it (the 
other entries are just "To:", "From:" and "Subject:")

But when I push the message out, "something" (yeah, it was "mhbuild"... read 
on) strips out the hated "Content-type" header, turning the message into peanut 
butter.

> I just 3 different things with the latest nmh, and they all behaved
> "as designed".

I tried the first two, and the behavior remains the same   ("dist" won't take a 
"-file" argument)

> But if you really want to disable that, you can control that via the
> buildmimeproc profile entry (see mh-profile(1)); set it to /bin/true
> or whatever.

BULLSEYE... X-ring...  *That* fixed it!!!!  (I had thought of that, but 
couldn't think of what to put in for a "null process" in the profile entry...).

> When run from send(1), mhbuild is being invoked with the "-auto" flag,
> which will exit silently if it sees a Mime-Version or
> Content-Transfer-Encoding header; that is done specifically so mhbuild
> doesn't affect existing MIME headers. So that shouldn't affect anything.

The only *mandatory* header for "forwarding" (yeah, right) a pre-existing 
message is "Content-type", since it has the (pre-generated) "Boundary" flag...  
So I just edit everything else out.

So, as I suspected, "mhbuild" was silently running and then exiting silently, 
but only after silently raping my message...

(1) I have V1.6.  So I can't guarantee that V1.7.1 behaves the same way (I 
can't try this in V1.7.1 without upgrading to Debian "testing"...  unless 
somebody knows where there's a (hopefully tested?) backport of V1.7.1...  Or 
Something...  ?)

(2) Yeah, I'd rather not *totally* disable "mhbuild"...  For the moment I can 
just leave the (rather meaningless) "Mime-version: 1.0" in the header of the 
message to be "forwarded", in order to "Trigger" (Or rather, UNTrigger) 
"mhbuild"  Or Something (that tactic *does* work with command line "comp"; I'll 
have to make sure "mhbuild" doesn't "silently" do something else when invoked 
differently, FI via "exmh" or whatever..).

(3) I've been assuming that "nmh" (and "exmh", FTM) don't "trigger" on a 
message having been accessed from within MH mail (e.g. as an entry in an MH 
folder), e.g., that "comp -file" will behave the same as "comp" accessing the 
"drafts" folder...  If that matters...

(3) I can construct an *exact* example of a mail message that displays the 
problem, if you want - but it should be possible to use any email that has a 
"Content-type" header with "Boundary" flag... (but, apparently, *without* a 
"Mime version" or "Content-Transfer-Encoding" entry???)

(4) **THANK** you...  (and my correspondents thank you as well...)

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, May 9, 2019 6:44 AM, Ken Hornstein <address@hidden> wrote:

> > After upgrading to nmh v1.6, I can no longer forward a message with a
> > content-type header.
>
> When you say, "Forward", what EXACTLY do you mean?
>
> I just 3 different things with the latest nmh, and they all behaved
> "as designed".
>
> -   When I forwarded a message with forw -mime, it generates a new message
>     with an message/rfc822 MIME type; the original message contained
>     in the message/rfc822 has the correct Content-Type header
>
> -   I forwarded a message with forw -nomime; that message just contained the
>     complete text of the message in the body, so the mail reader didn't
>     interpret it as MIME, but it's always done that; AFAICT that has never
>     changed.
>
> -   I used dist; the redistributed message contained all of the correct MIME
>     headers, including Content-Type.
>
>     So it's not that I don't believe you, but I cannot reproduce what you
>     are describing; if you could explain what exactly you are doing, that
>     would be helpful.
>
>
> > I suspect this is the result of "mhbuild" now being unconditionally
> > inflicted on the message, but I can't find any way to disable it, in
> > order to test that.
>
> When run from send(1), mhbuild is being invoked with the "-auto" flag,
> which will exit silently if it sees a Mime-Version or
> Content-Transfer-Encoding header; that is done specifically so mhbuild
> doesn't affect existing MIME headers. So that shouldn't affect anything.
> But if you really want to disable that, you can control that via the
> buildmimeproc profile entry (see mh-profile(1)); set it to /bin/true
> or whatever.
>
> --Ken