[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: |
Fri, 10 May 2019 12:58:22 -0400 |
>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] Can't forward MIME-encoded message, DuaneTime, 2019/05/09
- Re: [nmh-workers] Can't forward MIME-encoded message, Ken Hornstein, 2019/05/09
- Re: [nmh-workers] Can't forward MIME-encoded message, DuaneTime, 2019/05/09
- Re: [nmh-workers] Can't forward MIME-encoded message, Ken Hornstein, 2019/05/09
- Re: [nmh-workers] Can't forward MIME-encoded message, DuaneTime, 2019/05/09
- Re: [nmh-workers] Can't forward MIME-encoded message, Ken Hornstein, 2019/05/09
- Re: [nmh-workers] Can't forward MIME-encoded message, Ralph Corderoy, 2019/05/10
- Re: [nmh-workers] Can't forward MIME-encoded message, Ken Hornstein, 2019/05/10
- Re: [nmh-workers] Can't forward MIME-encoded message, Ralph Corderoy, 2019/05/10
- Re: [nmh-workers] Can't forward MIME-encoded message,
Ken Hornstein <=
- Re: [nmh-workers] Can't forward MIME-encoded message, Valdis Klētnieks, 2019/05/10
- Re: [nmh-workers] Can't forward MIME-encoded message, Ralph Corderoy, 2019/05/10
- Re: [nmh-workers] Can't forward MIME-encoded message, Ken Hornstein, 2019/05/10
- Re: [nmh-workers] Can't forward MIME-encoded message, Valdis Klētnieks, 2019/05/11
- Re: [nmh-workers] Can't forward MIME-encoded message, Ralph Corderoy, 2019/05/10
Re: [nmh-workers] Can't forward MIME-encoded message, Steven Winikoff, 2019/05/09