nmh-workers
[Top] [All Lists]

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

2013-06-27 11:15:06
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 <foo(_at_)bar(_dot_)com>

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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>