606967 - Forwarding an HTML-encoded email to a recipient that prefers HTML email can hang during SMTP delivery

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[James Craig Burley]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7
Build Identifier: 3.0.9

Forwarding a brief HTML-formatted message with no images (a shipped-order confirmation from Zazzle) to a specific recipient configured to prefer receiving email formatted as HTML and prefacing the message with "FYI." results in a hang during delivery of email.  Have to click "Cancel" and cancel out of the dialog about configuration possibly being wrong.

Watching the wire to the upstream SMTP server, the hang occurs after sending the final "</html>" in the forwarded message, but before the closing SMTP content tag.

Appending either a space or newline to the "FYI." results in delivery that is apparently successful, though the message is not formatted correctly -- the closing content tag in SMTP is missing.

Sending to another user, or temporarily changing the recipient's prefererence to receive mail format "Unknown", results in the appropriate closing content tag and successful delivery.

Correct:


010-10-25 10:33:17.835743500 26014 <   </tbody>
 010-10-25 10:33:17.835788500 26014 < </table>
 010-10-25 10:33:17.835833500 26014 < </body>
 010-10-25 10:33:17.835879500 26014 < </html>
 010-10-25 10:33:17.835923500 26014 < 
 010-10-25 10:33:17.835970500 26014 < --------------010403060704010103070304--
 010-10-25 10:33:17.836018500 26014 < .
2010-10-25 10:33:17.927838500 qmail-smtpd: 26014 ok 1288017197 qp 26017
 010-10-25 10:33:17.927930500 26014 > 250 ok 1288017197 qp 26017
 010-10-25 10:33:17.932613500 26014 < QUIT

Malformed but delivered (same recipient and prefs, slightly-modified preface text):

 010-10-25 09:44:16.770900500 25740 <   </tbody>
 010-10-25 09:44:16.770945500 25740 < </table>
 010-10-25 09:44:16.770990500 25740 < </body>
2010-10-25 09:44:16.771034500 25740 < </h+
 010-10-25 09:44:16.771366500 25740 < tml>
 010-10-25 09:44:16.771419500 25740 < .
2010-10-25 09:44:16.865631500 qmail-smtpd: 25740 ok 1288014256 qp 25743
 010-10-25 09:44:16.865721500 25740 > 250 ok 1288014256 qp 25743
 010-10-25 09:44:16.893750500 25740 < QUIT

Hang when recipient "wants" only HTML email and the preface text is entered only as "FYI.":


 010-10-25 10:34:13.747844500 26019 <   </tbody>
 010-10-25 10:34:13.747890500 26019 < </table>
 010-10-25 10:34:13.747935500 26019 < </body>
 010-10-25 10:34:13.747980500 26019 < </html>
2010-10-25 10:34:16.972001500 26019 < [EOF]
2010-10-25 10:34:16.972699500 tcpserver: end 26019 status 256

(Note that I let only a couple of seconds elapsed in that last case, but previously allowed the delivery attempt to go on for much longer.)

Watching the thunderbird-bin process via "top" showed that it maxed out at around 24% while Xorg was hitting 50% (drawing the "Delivering mail" dialog and progress bar and whatever else, like running top in a console window).

Reproducible: Always

Steps to Reproduce:
1.  Configure recipient to prefer to receive HTML emails.
2.  Forward a (specific?) HTML-encoded email to that recipient.
3.  Preface the forwarded message with just the text "FYI."
4.  Click Send.
Actual Results:  
The "Delivering mail..." dialog "progresses" indefinitely; the upstream SMTP server shows that the closing "</html>" tag has been sent, but not the closing content tag nor the "." on a line by itself to finish sending the SMTP message.

Expected Results:  
Successful delivery of a properly-formatted email.

Comment 1

[James Craig Burley]

So there doesn't seem to be a malformed-delivery issue here after all.  When the recipient "wants" HTML encoding, the entire message is composed as a single HTML document, so there's no need for the closing content tag.  Whereas, when the recipient wants "Unknown" encoding, a plaintext version of the message is formed along with the subsequent HTML version, requiring the encoding of both into a single SMTP message via the multiple-content mechanism.

Also, I was unable to reproduce using a different recipient (also configured to receive as HTML) until I made sure the recipient email address was the same length, including First, Last, and Display Names; then the repro (hang) "worked".

Comment 2

[Ludovic Hirlimann [:Usul]]

Can we get a stack trace ?

Comment 3

[Ludovic Hirlimann [:Usul]]

as described at https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report ...

Comment 4

[James Craig Burley]

Unfortunately, none of the techniques described on that page seem to work for me.  (Is there a "Generate Stack Trace" button in Thunderbird?  That would make things lots simpler.)

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> Unfortunately, none of the techniques described on that page seem to work for
> me.  (Is there a "Generate Stack Trace" button in Thunderbird?  That would make
> things lots simpler.)

James, There is nothing specific to linux other than what is linked to at https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report#Linux

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Hang when recipient "wants" only HTML email and the preface text is entered
only as "FYI.":
>(snip)
>  010-10-25 10:34:13.747980500 26019 < </html>
> 2010-10-25 10:34:16.972001500 26019 < [EOF]
> 2010-10-25 10:34:16.972699500 tcpserver: end 26019 status 256

From perspective of server, indicator of end of data(final ".[CRLF]") doesn't look arrived to SMTP server.
Same problem as bug 437494?
Check Mail size specified by Tb in "MAIL FROM:<[e-mail]> SIZE=nnnnnn" line.

Comment 7

[Wayne Mery (:wsmwk)]

James, bug 437494 is since fixed. does this work for you in version 9 or 10?

Comment 8

[James Craig Burley]

Cannot repro using Thunderbird 11 on Windows x64. Do you want me to try it on a Linux system? I could even get out the old Linux (Ubuntu) laptop I likely was using back then and try it on that if you like.