User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 When I write an email in Korean, extra spaces are introduced every several letters. Reproducible: Always Steps to Reproduce: 1.put korean letters in an email, for example, "아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아" 2.send a mail 3.see the result Actual Results: 아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아 아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아 아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아 아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아 아아아아아아아아아아아아아아아아아아아아아아아아아아아아 Expected Results: The original string It happens all the time. It gives an embarrassing experience because TB makes the email writer unprofessional!! It seems to happen in other versions as well across different platforms (windows/linux/etc).

text/plain mail? text/html mail? If text/plain, which charset did you use? Which kind of header? (a) Content-Type: charset=EUC-KR (b) Content-Type: charset=utf-8; format=flowed Do you see such space with text/plain mail composed in EUC-KR by Tb? (Compose in EUC-KR, Send Later, check mail source of mail in Oubox) If (b), can you see such space when header is changed to next? (c) Content-Type: charset=utf-8; format=flowed; delsp=yes (Copy a mail in new mail folder, Edit file for mail folder, "Repair Folder" at Folder Properties/Geeral) When you change to mailnews.send_plaintext_flowed=false via Config Editor, what kind of header does your Tb generates by mail composition in UTF-8? Is such space generated? Is CRLF(0x0D0A) inserted around 76 bytes without space at next line? (hard line-break based on default wrap line length)

The same thing happens with Japanese, but isn't this a dupe of Bug 26734?

(In reply to comment #2) > isn't this a dupe of Bug 26734? No, not dup, although "format=flowed without delsp=yes" is relevant to observed phenomenon. The "inserted space" is originally generated by line wrap due to line length limitations. (1) Line length limitations. (1-a) 1000 bytes line limit of email(defined by SMTP) (1-b) line wrap length for HTML mode(default : 72 characters) (1-c) line wrap length for text mode(default : 72 bytes) (2) At text.html part. If very long line with no space with no new line char, HTML source text is split to multiple lines(CRLF is inserted) by line length limitations. (3) Upon text conversion for text/plain part by text converter. (3-1) Because a CRLF in HTML is equivalent to single space, inserted CRLF is represented as a space in text/plain part data. (3-2) Because line warp of HTML==characters but line wrap of text==bytes, additional CRLF is inserted in text/plain part data by line warp of text after text conversion, if used charset is multi-byte code. (3-3) If format=flowed is enabled, and line length is longer than 80 bytes, line is split at a space. (4) HTML part display as HTML by Tb 3.1. Tb 3.1 looks to remove or ignore inserted CRLF in HTML source at step (2). So, inserted CRLF is not exposed when text/html part exists and View/Message Body As/HTML is used. (5) Issue in HTML mail composition. Due to bug 414299, mail composed in HTML is sent in text/plain part only, if Tb considers the HTML mail is text only mail. So, excess space in text/plain part produced by step (2) and step (3) is always exposed to user and mail recipient. (6) format=flowed in text/plain part, and shown layout of text/plain part data. format=flowed is still internally disabled for Japanese charset(iso-2022-jp,Shift_JIS,EUC-JP), because format=flowed,delsp=yes is not supported yet in mail composition by Tb. If UTF-8(multi-byte code), format=flowed depends on mailnews.send_plaintext_flowed setting. I guess EUC-KR doesn't prohibit format=flowed, if actual result in comment #0 is obtained by EUC-KR or something instead of UTF-8. Above phenomenon is observed by next test. (0) Set mailnews.send_plaintext_flowed=true/false, according to your purpose. (1) By text editer, create two long lines; - a...a[CRLF] in ascii (2000 to 3000 bytes) - {Continuous CJK character(s)}[CRLF] in non-ascii (2000 to 3000 bytes) (2) Compose HTML mail, copy above two long lines, paste to mail. (3) Options/Character Encoding, choose appropriate charset for test. (4) Options/Format, Plain and Rich(HTML) text (bypass of bug 414299) (5) Send Later, view mail source in Outbox of "Local Folders". (6) View mail, with View/Message Body As/HTML and Plain Text. As text mail composition uses HTML internally in mail composition, similar phenomenon can occur on text mail composed in text mode, if line wrap of text=0 is intentionally set by user. Insert of space may occur by format=flowed in text mail composition. Possible solution of this kind of problem. - format=flowed,delsp=yes even for text/html part, and utilizes it upon line wrapping and line splitting due to line length limit. - format=flowed,delsp=yes for text/plain mail composition. However, this kind of problem is easily avoided by; - To know mail is never text file and line length limitation exists. - To put new line character at appropriate places, because it's mail. - If text only mail, use text mode composition since initial. - If HTML mail, bypass bug 414299(Options/Format/Plain and Rich(HTML) text).

The same happens to Chinese characters. It affects all CJK users in all.

@WADA I just test the method you mentioned to avoid such problem, but I'm a native Chinese speaker. I think manually add a new line break is really ugly. But TB seems still add some extra spaces. (I have no idea how to avoid TB to automatically add spaces) I have tried sending a text message in Gmail's web page, it works quite well. How does other email engine to handle such case of problem? thanks.

I attached test cases to see problem easily to bug 653342, and consolidated problem on all of C, j, K to that bug. There is no need to keep bugs for each C, J, K.