Menu

#543 personalized recip should be MIMEed

2.1 beta
closed-fixed
nobody
5
2002-09-17
2002-08-28
No

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.

Discussion

  • Tokio Kikuchi

    Tokio Kikuchi - 2002-08-28

    SMTPDirect.py.diff

     
  • Barry Warsaw

    Barry Warsaw - 2002-09-13

    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?

     
  • Simone Piunno

    Simone Piunno - 2002-09-13

    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.

     
  • Barry Warsaw

    Barry Warsaw - 2002-09-17
    • status: open --> closed-fixed
     
  • Barry Warsaw

    Barry Warsaw - 2002-09-17

    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.

     

Log in to post a comment.