If the list delivery is personalized, user's name is
placed in To: header. When the user choose to register
non-ascii character in the name, To: header contain
non-ascii and breaks RFC(number?Idontknow).
A quick and dirty patch is included. I hope Barry can
inspect and revise it.
SMTPDirect.py.diff
Logged In: YES
user_id=12800
Ouch, this is a tougher problem because you don't really
know what character set the name is in. It may not be the
charset for the user's preferred language at all.
I can see three approaches. First, you should never have
funny characters in the real name component (use the encoded
name instead). Second, there could be a a second entry box
under the name asking for the charset of the name. It would
default to us-ascii (or maybe just empty). I fear however
that most people will be entirely clueless as to what the
proper value would be. Third, if there are non-ascii
characters in the name, I think we could just encode with
utf-8 and be done with it -- you can't really guess much
more about the proper encoding. I'm not sure the latter
will work or will even be cross platform.
Ideas?
Logged In: YES
user_id=227443
If the address is coming from a web browser I
believe you should be able to guess the encoding
from the HTTP headers (at least for POST).
If the address is coming from the command line you
could try to check KBCHARSET or you could just
add an optional parameter (the list admin shouldn't
be so clueless)
If the address is coming from an email you could
allow non-ASCII only if properly encoded (so that
you can deduce the encoding from the email)
In any case you should store the encoding
valuesomewhere in the list database file, for later
use.
Logged In: YES
user_id=12800
This was a fun one! The quick and dirty patch wasn't really
enough. Now we essentially keep non-ascii names as unicode
in the member database and then do output encoding as
necessary for the context. MM 2.1b4 should have all the
code for this.