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

[David Levine]

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

Do we do any character replacement now, other than the
insertion of quotes around the display name that you mention
below?  If not, character substitution could introduce bad
behavior that we don't have now.

> >> 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 (>)

OK, I'm fine with that.

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

It's obvious what needs to be done in that case to go from
an invalid address to a valid one.  And the delivery address
isn't being modified, just the display name.

David