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

[Ken Hornstein]

>> Some experimenting leads me to believe that this _still_ would not
>> be accepted as an alias.  Specifically, the @ means it gets parsed
>> by the address parser and has a valid 'host' part so it doesn't get
>> processed by the alias parser.
>
>To: MrFoo?Bar?foo?bar.com?

Ok, I'm trying to understand how this is a _new_ problem.  I mean, if
you end up with this:

To: somelocalalias

That's _already_ going to cause a problem, without any character substitution.
I mean, I'm trying to understand how character replacement makes this a
new problem.

>> I'm fine with having the address parser reject addresses that
>> contain 8-bit characters; it doesn't seem like that's changing much,
>> and it would happen well before format output processing would take
>> place.  We do not do that now.
>
>So "reject addresses" would mean that the user gets an
>error message, and the editor doesn't open the draft?

Hm.  Well, that's not what happens now.  What happens now is inside of
your draft you get messages like this:

repl: bad addresses:
        Ken Hornstein <kenh@> -- no sub-domain in domain-part of address (>)
        Ken Hornstein <kenh@> -- no sub-domain in domain-part of address (>)

Getting back to the original issue ... I will note that there is
precedence for fixing up the name portion of an address.  If we get an
address like this:

        Mr Foo B. Bar <address@hidden>

which is invalid because the . without quotes is invalid, we silently add
quotes and fix it up.

--Ken