nmh-workers
[Top] [All Lists]

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

2019-05-09 12:23:23
(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 <kenh@pobox.com> 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



-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>