[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Hornstein
Subject: Re: [nmh-workers] Can't forward MIME-encoded message
Date: Thu, 09 May 2019 22:00:01 -0400

>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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]