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

[Richard M Kreuter]

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

Okay, understood. (I can postprocess addr's output in some, maybe all,
of my use cases, so this isn't a big deal; I was mainly asking whether I
should expect to need to do that postprocessing.)

> 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?

I wasn't thinking of anything in particular; just asking what I ought to
expect. I'm okay with the answer that it's impossible or impractical to
extract the requested thing from an invalid header.

However, ISTM having addr output text that can be something other than
its documented "contract" (an mbox@host or host!mbox) is perhaps a bit
dodgy, even when the root issue is invalid (or unsupported) input. I
don't know how the formatting engine works, but couldn't addr
conceivably scan its own prospective output and error if it's not in the
right shape?  (This is idle speculation, not a request; and I've no idea
whether such a change would be an unwelcome incompatibility for other
folks. As I mentioned above, I think I can work around what addr appears
to do.)

> "." in the "phrase" (which is the part before the email address) is
> officially valid as part of the "obsolete" syntax in RFC 5322...

Oh, right; thanks. I regularly overlook the obs- productions.

> However, if you did get a RFC 2047-encoded From: header with an
> unencoded ".", THAT is unambiguously invalid.

I did indeed: that was, AFAICT, the only invalidity in the offending
header. Oh well.

> I realize that doesn't address your question unfortunately, and I
> don't have a good answer for you.

No problem. Thank you for the insights, and thank you for nmh!

Regards,
Richard