Re: [nmh-workers] Can't forward MIME-encoded message
On Fri, 10 May 2019 23:30:45 -0400, Ken Hornstein said: > Hoo boy, some names from the past in that thread. And Valdis, of course :-) Hey, I didn't post at all in that particular food fight. :) pgpZ7HdwrlIx4.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
>> My under-caffeinated mind is whispering about a myth regarding ancient >> software on SunOS that stuck in things like 'Content-Type: uuencode' >> when using its pre-MIME scheme for sending non-text data. Unclean! >https://www.mhonarc.org/archive/html/ietf-822/1994-12/msg00167.html >makes that suggestion as it argues against ‘C-T-E: uuencode’. But I >didn't find anything else of note. Hoo boy, some names from the past in that thread. And Valdis, of course :-) --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
Hi Valdis, > My under-caffeinated mind is whispering about a myth regarding ancient > software > on SunOS that stuck in things like 'Content-Type: uuencode' when using its > pre-MIME scheme for sending non-text data. https://www.mhonarc.org/archive/html/ietf-822/1994-12/msg00167.html makes that suggestion as it argues against ‘C-T-E: uuencode’. But I didn't find anything else of note. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
On Fri, 10 May 2019 12:58:22 -0400, Ken Hornstein said: > >And many MIME-extension-fields may be present. > >https://www.rfc-editor.org/rfc/rfc2045.html#section-9 suggests that's a > >header matching /^content-/i, including `Content-: foo', I presume, > >unless some RFC says a header can't end in a `-'. > > Huh, that's a new one for me. RFC 5322 says: Section 9 is essentially reserving a namespace for MIME-specific headers. 9. Additional MIME Header Fields Future documents may elect to define additional MIME header fields for various purposes. Any new header field that further describes the content of a message should begin with the string "Content-" to allow such fields which appear in a message header to be distinguished from ordinary RFC 822 message header fields. MIME-extension-field := So the two of you are in what's often referred to as "violently in agreement" :) > Yeah, I am TRYING to understand the reasoning for the deletion of the > Content-Type header; it was clearly deliberate and existed way back in > MH 6.8.3 (and earlier; the earliest version I can find of mhn.c had that My under-caffeinated mind is whispering about a myth regarding ancient software on SunOS that stuck in things like 'Content-Type: uuencode' when using its pre-MIME scheme for sending non-text data. Of course, that was before recorded history^W^WGoogle, so records are sketchy, incomplete, and contradictory. There is even rumor that that some machines stored 6 6-bit or 5 7-bit bytes in one memory location, and as a result special incantations were needed if you wished to converse with a font of knowledge known as "simtel20". pgp9gYBvPT8Mf.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
>Is this just in the email headers, not the part headers? Stepping back a bit ... As I see it, the job of mhbuild is to take a "draft message" and turn it into a valid MIME message; it's job is NOT to verify an existing MIME message. When invoked in send with the -auto flag, it needs to decide if the draft file is already a MIME message >https://www.rfc-editor.org/rfc/rfc2045.html#section-3 shows Mime-Version >must be present. Geez Ralph, didn't I quote that already once in this thread? :-) >And many MIME-extension-fields may be present. >https://www.rfc-editor.org/rfc/rfc2045.html#section-9 suggests that's a >header matching /^content-/i, including `Content-: foo', I presume, >unless some RFC says a header can't end in a `-'. Huh, that's a new one for me. RFC 5322 says: optional-field = field-name ":" unstructured CRLF field-name = 1*ftext ftext = %d33-57 / ; Printable US-ASCII %d59-126 ; characters not including ; ":". Sure seems like "Content-:" is valid. Hell, even "-:" is valid. >How much checking is mhbuild trying to do that the draft is valid, >I think that can become > >if -auto: >if Mime-Version: ># trust user has done mhbuild's work correctly >exit 0 > >if Mime-Version or Content-*: >gripe MIME headers found: ... >exit 1 > >mhbuild Seems reasonable to me. >The idea is nmh is either in complete control of putting MIME headers >in, or not at all. It doesn't remove any that are there as that >suggests the user has done something wrong. Yeah, I am TRYING to understand the reasoning for the deletion of the Content-Type header; it was clearly deliberate and existed way back in MH 6.8.3 (and earlier; the earliest version I can find of mhn.c had that behavior). But I can't come up with anything. The behavior you describe would at least solve the problem here where the user wasn't notified that the Content-Type header was being eaten, and my reading of RFC 2045 matches yours; we're allowed to match on "Content-.*". So I'll make that change. >BTW, mhbuild(1) doesn't have -auto's default in DEFAULTS. And I guess that should be fixed as well. --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
Hi Ken, > > I agree the earliest git commit checks both, but the RFC says C-T-E > > is optional. I think the only mandatory MIME header is the version > > so can't we ditch the other test? Otherwise it just leads to calls > > to extend the list. ... > I find it odd that it bails out on a Mime-Version header AND a CTE, > but it silently eats the Content-Type. ... > I don't think mhbuild can just ignore existing MIME headers. This is > what we have now: > > --+-+ > Header| -auto | -noauto > --+-+ > Content-Transfer-Encoding | exit(0) | exit(1) > Mime-Version | exit(0) | exit(1) > Content-Type | Remove | Remove Is this just in the email headers, not the part headers? https://www.rfc-editor.org/rfc/rfc2045.html#section-3 shows Mime-Version must be present. These four may be present once. Content-Type Content-Transfer-Encoding Content-ID Content-Description And many MIME-extension-fields may be present. https://www.rfc-editor.org/rfc/rfc2045.html#section-9 suggests that's a header matching /^content-/i, including `Content-: foo', I presume, unless some RFC says a header can't end in a `-'. How much checking is mhbuild trying to do that the draft is valid, e.g. there aren't two C-D when only one is allowed? How about making the logic simple and seeing if that meets needs? I don't think a table can state it unless the rows imply order. if -auto: if Mime-Version: return # trust user has done mhbuild's work correctly exit 0 if Content-*: gripe MIME headers found: ... exit 1 mhbuild else: if Mime-Version or Content-*: gripe MIME headers found: ... exit 1 mhbuild I think that can become if -auto: if Mime-Version: # trust user has done mhbuild's work correctly exit 0 if Mime-Version or Content-*: gripe MIME headers found: ... exit 1 mhbuild The idea is nmh is either in complete control of putting MIME headers in, or not at all. It doesn't remove any that are there as that suggests the user has done something wrong. BTW, mhbuild(1) doesn't have -auto's default in DEFAULTS. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
>> - If it was run on a message with a CTE or Mime-Version header, it would >> error out. >... >> Why that specific behavior? No idea! But it was very deliberate. > >I agree the earliest git commit checks both, but the RFC says C-T-E is >optional. I think the only mandatory MIME header is the version so >can't we ditch the other test? Otherwise it just leads to calls to >extend the list. Well, I wanted to provide some perspective and history, but I can't justify it after a closer inspection. I find it odd that it bails out on a Mime-Version header AND a CTE, but it silently eats the Content-Type. Perhaps you could help me by filling out the following matrix? Do you want the desired behavior for each box to be "exit(0)", "exit(1)", "Remove" (for remove header), or something else?. I don't think mhbuild can just ignore existing MIME headers. This is what we have now: +---+-+--+ | Header| -auto | -noauto | +---+-+--+ | Content-Transfer-Encoding | exit(0) | exit(1) | +---+-+--+ | Mime-Version | exit(0) | exit(1) | +---+-+--+ | Content-Type | Remove | Remove | +---+-+--+ --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
Hi Ken, > - If it was run on a message with a CTE or Mime-Version header, it would > error out. ... > Why that specific behavior? No idea! But it was very deliberate. I agree the earliest git commit checks both, but the RFC says C-T-E is optional. I think the only mandatory MIME header is the version so can't we ditch the other test? Otherwise it just leads to calls to extend the list. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
>Apparently, it depends on whether you define "MIME Message" as "Conforms >to RFC 2045 (Or whatever... op. cit. ref. "Steeenking Badges"), or >"Contains Readable Mime Data"... I guess if I were *generating* a "Mime >Message", I would use the former definition, whereas if I were trying to >*detect* a "Mime Message", I would use the latter... Here's my thinking on the subject. The goal of running mhbuild in send(1) is to generate a valid MIME message so that anything nmh sends out is conformant with the various RFCs. If mhbuild's job was to DISPLAY such messages, I might agree with you, but again, that's not it's job (and I would point out that if a MUA decided that a message that lacked a MIME-Version header was not, in fact, a valid MIME message, it would be perfectly correct to do so). So when it looks at a message, it has to decide if it is valid MIME or not. If it is valid MIME, then it will leave it untouched. If it's missing a required header, it's really impossible for it to guess how it should treat it. A message without a Mime-Version header isn't valid; it's not right for us to send that out. For reasons I do not understand, you do not want to leave a Mime-Version header in your messages; that's your right, but I don't think it's reasonable that you complain when that doesn't work since those messages don't meet the MIME standard. As to how we got this specific behavior ... well, I had to dig back in history a bit. Pre-1.6, we didn't run mhbuild (or it's precessor, mhn), all of the time at all; this was changed in 1.6 because nmh users kept sending out invalid MIME messages. But pre-1.6, mhbuild/mhn would do the following things: - If it was run on a message with a CTE or Mime-Version header, it would error out. - It would always silently swallow a Content-Type header. Why that specific behavior? No idea! But it was very deliberate. When I implemented the -auto flag for 1.6, I brought that specific logic forward, with a slight tweak; if -auto was set (send invokes mhbuild with -auto) and it saw either of those two headers, where it would before error out, it would silently exit. Thinking back, probably doing BOTH of those was a mistake, but I didn't really think about it at the time. The behavior of swallowing Content-Type was kept. --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
>>I didn't know forw had a -mime switch. Since this is something I'd find >>very helpful, I just tried it, but it completely failed to work for me. > >forw -mime doesn't have a wonderful interface; what it does is generate >a mhbuild directive and it puts it in the draft message. You then have >to run "mime" on the resulting draft for the right thing to happen. Thank you! I just tried that, and it worked perfectly. >This is actually all covered in the man page for forw(1); let me know if >it is unclear. No, it's clear enough; I just didn't think to read the man page until you pointed it out just now. >I'm not defending this practice; it's the way it's always worked and I am >unable to come up with a better solution at this time. Maybe someday ... That's okay; the two-step process is still much easier than what I'd been doing until now. - Steven -- ___ Steven Winikoff| "Sometimes I think we're alone in the Montreal, QC, Canada | universe, and sometimes I think we're s...@smwonline.ca | not. In either case, the idea is quite http://smwonline.ca| staggering." | - Arthur C. Clarke -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
>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 didn't know forw had a -mime switch. Since this is something I'd find very helpful, I just tried it, but it completely failed to work for me. The message I tried to forward is described as follows: # mhlist +wing 3943 msg part type/subtype size description 3943 multipart/mixed16M 1 text/plain 326 2 application/pdf 3836K a_night_at_the_ballet_2nd.pdf 3 application/pdf 1098K light_vibrations_2nd.pdf 4 application/pdf 2092K sinatra_in_concert_2nd.pdf 5 application/pdf 3629K a_night_at_the_ballet_3rd.pdf 6 application/pdf 1100K light_vibrations_3rd.pdf 7 application/pdf 389K sinatra_in_concert_3rd.pdf My test was invoked as follows: # forw -mime +wing 3943 The resulting message is 8<- cut here >8 From s...@smwonline.ca Thu May 9 13:06:39 2019 Return-Path: Received: from mort (localhost.localdomain [127.0.0.1]) by 206-248-137-116.dsl.teksavvy.com (8.15.2/8.15.2/Debian-10) with ESMTP id x49H6dIA003943 for ; Thu, 9 May 2019 13:06:39 -0400 To: smw Subject: testing /local/paths/forw -mime From: Steven Winikoff Reply-to: Steven Winikoff MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3941.1557421599.1@mort> Date: Thu, 09 May 2019 13:06:39 -0400 Message-ID: <3942.1557421599@mort> #forw [forwarded message] +/home/smw/Mail/wing 3943 8<- cut here >8 I wondered if this might be caused by a profile entry. # grep forw ~/.mh_profile forw: -filter .forwardfilter -form .forwardform ...but when I tried deleting this entry, the same thing happened: 8<- cut here >8 From s...@206-248-137-116.dsl.teksavvy.com Thu May 9 13:08:15 2019 Return-Path: Received: from mort (localhost.localdomain [127.0.0.1]) by 206-248-137-116.dsl.teksavvy.com (8.15.2/8.15.2/Debian-10) with ESMTP id x49H8F46004123 for ; Thu, 9 May 2019 13:08:15 -0400 From: Steven Winikoff To: smw Subject: Re: FW: A Night at the Ballet - 2 (fwd) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4121.1557421695.1@mort> Date: Thu, 09 May 2019 13:08:15 -0400 Message-ID: <4122.1557421695@mort> #forw [forwarded message] +/home/smw/Mail/wing 3943 8<- cut here >8 Here the only difference is the Subject: header; in my first test the default was empty, and in the second test I left the default value unchanged. Please let me know if there's any additional information I can supply about this. - Steven -- ___ Steven Winikoff| "I knew 'Enterprise Computing Systems' were Montreal, QC, Canada | evil before I touched an actual computer s...@smwonline.ca | for the first time, because I used to http://smwonline.ca| watch Kirk and Spock fighting for control | of it." - Anthony de Boer -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
Apparently, it depends on whether you define "MIME Message" as "Conforms to RFC 2045 (Or whatever... op. cit. ref. "Steeenking Badges"), or "Contains Readable Mime Data"... I guess if I were *generating* a "Mime Message", I would use the former definition, whereas if I were trying to *detect* a "Mime Message", I would use the latter... I'm not at all sure how I'd define "Bug", in this situation... However, since (apparently?) the presence of *either* the "Mime-Version" *or* the "Content-Transfer-Encoding" header will Trigger "mhbuild", shouldn't a "Content-type" header with "Boundary" flag (or maybe, just a "Content-type" of "mixed, or "alternative" trigger it likewise? I mean, that header pretty well guarantees that the message is MIME-formatted, even if it doesn't exactly conform to the RFC... Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, May 9, 2019 10:42 AM, Ken Hornstein wrote: > > 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. > > This is the problem, here, because that is NOT true. > > A MIME message needs a MIME-Version header, full stop, no exceptions; > this is unambiguous (see RFC 2045, §4). This is what we trigger on to > make mhbuild do the right thing. If we don't see a MIME-Version header, > we go on the assumption that the existing draft is NOT a MIME message, > and we MIME-ify the resulting draft, which I suspect ends up generating > a new Content-Type header for your message which does not contain a > boundary marker (because the message isn't a MIME message according to > the rules). > > So, I have to say that I don't see this as a nmh bug ... if you want > to feed a MIME message into mhbuild you should include a MIME-Version > header; it's not meaningless at all. If you are trying to send out a > message that does not contain a MIME-Version header, then that is not > valid according to the standards. > > --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
>I didn't know forw had a -mime switch. Since this is something I'd find >very helpful, I just tried it, but it completely failed to work for me. forw -mime doesn't have a wonderful interface; what it does is generate a mhbuild directive and it puts it in the draft message. You then have to run "mime" on the resulting draft for the right thing to happen. This is actually all covered in the man page for forw(1); let me know if it is unclear. I'm not defending this practice; it's the way it's always worked and I am unable to come up with a better solution at this time. Maybe someday ... --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
>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. This is the problem, here, because that is NOT true. A MIME message needs a MIME-Version header, full stop, no exceptions; this is unambiguous (see RFC 2045, §4). This is what we trigger on to make mhbuild do the right thing. If we don't see a MIME-Version header, we go on the assumption that the existing draft is NOT a MIME message, and we MIME-ify the resulting draft, which I suspect ends up generating a new Content-Type header for your message which does not contain a boundary marker (because the message isn't a MIME message according to the rules). So, I have to say that I don't see this as a nmh bug ... if you want to feed a MIME message into mhbuild you should include a MIME-Version header; it's not meaningless at all. If you are trying to send out a message that does not contain a MIME-Version header, then that is not valid according to the standards. --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Can't forward MIME-encoded message
(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 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
Re: [nmh-workers] Can't forward MIME-encoded message
>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 forwared 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
[nmh-workers] Can't forward MIME-encoded message
After upgrading to nmh v1.6, I can no longer forward a message with a content-type header. For instance, if the message header contains Content-Type: multipart/alternative; boundary="=_Part_1122334455" and the body of the message contains --=_Part_1122334455 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --=_Part_1122334455 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable nmh will completely remove the "Content-Type" in the header, so that the message is just garbage and cannot be read. (It leaves the two "Parts" in the body though.) 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. My nmh release came with Debian version 9. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
