User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 I can't send message if receiver contain certain Chinese character. When using Mozilla 1.1, it can send correctly. Reproducible: Always Steps to Reproduce: 1. Open compose window. 2. In To: field input "&#23431; <joe@numa.com.tw>" (Chinese Big5 encoding) 3. Send the message. (I'm using SMTP account) Actual Results: Error message: An error occurred while sending mail. The mail server responded: 5.1.1 <"e.<joe\"@numa.com.tw>"> User unknown. Please check the message recipients and try again. In step 2, delete the Chinese character then the mail can be sent correctly. Also, using other Chinese character is OK. Seems some character will cause mozilla to generate wrong recipient list. I've reported this bug under bug 163933, but it turn out they are different problem and nobody respond for that bug.

This is a one-line patch to fix the problem. Please commit.

Joe, I tried some recipient fields like XX <email address>, here XX stand s for Traditional Chinese characters, and I can send out the mail in Big5 either with the latest trunk build or 1.0 branch build. What characters did you use? could you post those characters to the bug report? Before posting, you need to change the encoding of the navigator window to Big 5 via View | Character Coding, otherwise the characters will be displayed garbled after the comments are submitted.

Comment on attachment 106371 [details] [diff] [review] Proposed patch. nhotta, can you review this?

I only know ¦t will cause the problem. Others characters are fine.

I just tried with this character, it works for me. I tried the following format ¦t <email address> "¦t" <email address> Both works. I'm on Windows XP. What exact format did you use? And what system are you on?

Xianglan,i believe that bug is logged for Linux.

I send message using ¦t <joe@xxx.xxx> I'm using mozilla 1.2b on RedHat 6.2.

It works for me with the latest 1.0 branch build on Red Hat 7.2. Let me try the trunk build

The problem is the email address will be changed to: user\"@xxx.xxx In my test, the receiver account is on the SMTP server, so the server will direct recject sending the email. Otherwise, the email will be sent and recjected by remote server because can't find the user.

Comment on attachment 106371 [details] [diff] [review] Proposed patch. The code that Joe is patching seems clearly wrong anyway. Requesting reviews.

I don't have this problem with 11/14 trunk build either on my RH7.2 The email address is not changed to user\"@xxx.xxx in my case. Joe, what server are you using? do you have this problem with other mail clients?

The SMTP server is sendmail-8.11.6-1.6.y on RH6.2 I think the problem is on the client side, because Mozilla 1.1 on RH6.2 works. And base on the trace log I have, the email address send out by mozilla is wrong. Maybe there are some different in GLIBC charset handling between RH6.2 and RH7.2 causing the problem?

Comment on attachment 106371 [details] [diff] [review] Proposed patch. R=ducarroz. I don't understand how this line could compile and what it really does and how it's related to this bug. But sure this is a typo error which must be fixed

setting bug status to New.

Comment on attachment 106371 [details] [diff] [review] Proposed patch. sr=sspitzer

whoops, this was my checkin for http://bugzilla.mozilla.org/show_bug.cgi?id=168269 see http://bugzilla.mozilla.org/attachment.cgi?id=99056&action=view looks like a copy and paste error. thanks for catching it, simon. as for why it compiles, see http://www.ssec.wisc.edu/~dglo/c_class/comma.html

Checked in. Joe, can you verify? Thank you for the patch!

I've tested the trunk and this problem is fixed. Is it possible to fix this problem in mozilla 1.2 branch?

I've requested approval from drivers for the 1.2 branch.

Comment on attachment 106371 [details] [diff] [review] Proposed patch. Please check into the 1.2 branch ASAP if you want this in 1.2

Checked into 1.2 branch. Marking verified per comment 18.