Re: [Nmh-workers] Weird behavior with non-ascii code in headers

[Doug Wellington]

> I'm all for that ... but it just brings up some sticky issues.  Like if
> you have a header which is not valid, then what, exactly, should you
> do about it?

Well, my thought is to present errors to the user for manual
intervention.  After all, if a person is smart enough to use nmh,
they're smart enough to figure out how to fix a header line, right?  :D

Off the cuff, I'd guess that there would be three cases, 1)
envelope-related headers such as From, To, Return-Path, Subject,
Message-ID and Date, 2) content-related headers like Content-Type and
Content-Transfer-Encoding, and 3) delivery/other information headers
like Received and X-*.  (I'm sure there are more appropriate terms for
these categories, but I can't think of them now.)  We'd need to validate
that From, To and Return-Path are addresses and that Subject and
Message-ID are appropriate strings.  I think that Date would probably be
the hardest envelope-related header to automatically correct.

Validating content-related headers would be interesting.  If we validate
the header lines themselves, shouldn't we make sure that they represent
the actual content?  (Cue MIME discussion.)  As for the other headers,
wouldn't we just have to ensure that they're appropriately encoded
strings?  Maybe prepend "X-Malformed-Header:" to a line we couldn't
automatically fix?  And of course, we should validate continuations for
all lines.  I'll look into it when I get a chance, but I find it
fascinating that scan couldn't figure out the proper date or subject
when it ran into invalid continuations.

> I'm looking at inc.c and I'm not seeing the code you mention; can you point
> me to it?

Part of a commented out function called cpymsg near line 980.  Not much
there, actually...  (Ah, wait, I was using the 1.5 release tarball
source.  I just cloned the git repository and that part is gone.)

> David Levine already wrote mhfixmsg; it occurs to me that this might be
> a good candidate for that.

Ah, thanks, I'll check that out...

> I have not yet seen a message/global MIME type in the wild.  When we start
> seeing them I think we should care.  Are people seeing these messages?

I'm not actually seeing anything like this yet, but I'm always
interested in trying to take the future into account when planning
changes...

Regards,
Doug