>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
