Re: %(addr{<component>}) and RFC-invalid headers

[Ken Hornstein]

>1. Could (should?) %(addr{<component>}) be expected to be able to
>   extract the addr-spec part out of an invalid message header?

Ummm .... no?

If the address parser fails, well ... we're kind of stuck.  Internally
that's what makes all of the format engine address functions work.  I'm
not even sure what makes sense here; are you thinking if address parsing
fails we should shift to some other, backup address parser?  And if that
one fails, what next?

>2. Has anybody got general tips on dealing with slightly-invalid
>   messages in nmh? They seem somewhat unavoidable.

Sigh.  I hate to say it, but ... we get this wrong.

"." in the "phrase" (which is the part before the email address) is
officially valid as part of the "obsolete" syntax in RFC 5322.  However,
if you did get a RFC 2047-encoded From: header with an unencoded ".",
THAT is unambiguously invalid.  But it doesn't really solve the core
issue here, in that we should be more accepting of "." in phrases
and we aren't.  Sigh.  I realize that doesn't address your question
unfortunately, and I don't have a good answer for you.

--Ken