234597 - with non-ascii charcters in the mail body and 'quoted-printable' checked, can't send a message

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[Jungshik Shin]

When 'use quoted-printable for 8bit characters' is set, I can't send a message
with non-ASCII characters in the message body. Without non-ASCII characters, it
works fine. Without 'use quoted-printable for 8bit characters', it works well, too.

I took a look at the log file of my sendmail and it seems like Thunderbird gets
into a loop and doesn't send any data to the mail server after the initial
negotiation. Strange is that Mozilla 1.6 works flawlessly.

This problem was reported by a Korean user according to whom the problem was
also present in TB 0.4 so that it's not a recent regression.

Comment 1

[Petr Altman]

I have same problem. I'll add some details:

I can't send a message ONLY in this case:
1) when 'use quoted-printable for 8bit char' is set
2) I send mail in plaintext (or plaintext+html)
3) mail contain 8bit characters

(If I use only html - everything is ok)

I looked what TB realy send by Ethereal:
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: base64

dGVzdOy56Pi+DQo=.

Why it's coded with base64??
It seems that endof message is coded wrong (smtp server does'n detect end of
message body).

(Tested on TB 0.4 CZ, TB 0.5 US)

Comment 2

[Jungshik Shin]

> Why it's coded with base64??

  I think TB uses either Base64 or QP depending on which one leads to a shorter
representation.

> It seems that endof message is coded wrong 
> (smtp server does'n detect end of message body).

You're right. Ethereal is a great tool !. I'm still wondering why TB has that
problem while Mozilla-mail doesn't. Can you do the same experiment with
Mozilla-mail? Mozilla-mail might always use 'QP', which can explain the difference.

Comment 3

[Jungshik Shin]

> Mozilla-mail might always use 'QP', which can explain the difference.

I just ran ethereal and it seems to be the case. So, there are two ways to fix
this. One is to make TB always use 'QP' as Mozilla does. The other is to insert
'CRLF' at the end of Base64-encoded message body before sending '.'. 

Comment 4

[Jungshik Shin]

Petr, can you run ethereal  and see what's 'emitted' by TB for a plaintext +
html message? This may help me pin down where to look to fix this bug.

Comment 5

[Petr Altman]

Attachment: ethereal

Ethreal oot for msg sent in plaintext and plaintext+html

Comment 6

[Petr Altman]

> Petr, can you run ethereal  and see what's 'emitted' by TB for a plaintext +
> html message? This may help me pin down where to look to fix this bug.

You can see ethereal output in attachment.

Now it behaves different, I don't know why - I still have TB0.5US.

If msg is sent in plaintext+html, then plaintext part should be coded in bese64
(it's in head), but it's in 8bit. Message is then sent ok, but plaintext part is
then of course unreadable...

Comment 7

[Jungshik Shin]

Thanks for the ethereal dump.

> If msg is sent in plaintext+html, then plaintext part should be coded in bese64
> (it's in head), but it's in 8bit

I confirmed this behavior in Mozilla with the trunk source. For this, I filed
bug 238165. Phew, this makes it even harder to fix this bug. 

Firstly, I don't understand why TB and Mozilla-mail behave differently for plain
text only case. As far as I can tell, both uses the same mechanism to determine
which C-T-E to use, QP or Base64, but mozilla-mail uses QP even when base64 is
more efficient length-wise while TB uses base64 in that case. 

Secondly, I haven't yet figured out where I can safely insert 'CRLF'. 

Comment 8

[Troodon]

*** Bug 235841 has been marked as a duplicate of this bug. ***

Comment 9

[Jungshik Shin]

TB 0.6 doesn't work but TB 0.7rc works for me. Somehow, this bug seems to have
been 'fixed'. Petr, can you try TB 0.7rc and see if it works for you, too? 

Comment 10

[Petr Altman]

(In reply to comment #9)
> TB 0.6 doesn't work but TB 0.7rc works for me. Somehow, this bug seems to have
> been 'fixed'. Petr, can you try TB 0.7rc and see if it works for you, too? 
> 
Yes, in TB 0.7rc it seems good. It works in base64 and qouted-printable too.

Comment 11

[Jungshik Shin]

Thanks for testing. Resolving as WFM in TB 0.7rc. This could have been rather
major. I'm relieved that it's somehow 'self-fixed' although it'd better to know
what  change fixed this.

Comment 12

[Troodon]

Just confirmirng that I tested with some of the last Mozilla Suite nightly
builds and it seems to be gone (I had this problem with Mozilla - see bug 235841
). :-)