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