message send sometimes spins

RESOLVED FIXED

Status

RESOLVED FIXED
15 years ago
10 years ago

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Tracking

({fixed1.7})

Trunk
x86
Windows 2000
fixed1.7

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

15 years ago
I managed to get myself in a state where I couldn't send a message - it spun
sending the message. I tracked it down to the temp message constructed not
ending with CRLF, so we weren't sending a CRLF.CRLF to the smtp server. 

To get myself in this state, I sent myself a message with some chars > 0x80, and
in my prefs, I specified using quoted printable. It turned out to use base 64
bit encoding for the message body when I replied to the original message, but
didn't terminate the message body with a CRLF. Proposed fix upcoming.
(Assignee)

Comment 1

15 years ago
Created attachment 147753 [details] [diff] [review]
proposed fix

I really don't know if this is the right thing, but it seems like we should end
with a CRLF...maybe only in the case that it's the message body?
(Assignee)

Comment 2

15 years ago
Comment on attachment 147753 [details] [diff] [review]
proposed fix

review, or advice welcomed!
Attachment #147753 - Flags: review?(mozilla)
(Assignee)

Comment 3

15 years ago
Created attachment 147762 [details] [diff] [review]
proposed fix

after talking with JF, he suggested this fix as being safer, and it works
Attachment #147753 - Attachment is obsolete: true
(Assignee)

Comment 4

15 years ago
Comment on attachment 147762 [details] [diff] [review]
proposed fix

r=ducarroz over aim
Attachment #147762 - Flags: superreview?(mscott)
Attachment #147762 - Flags: review+

Updated

15 years ago
Attachment #147762 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 5

15 years ago
Comment on attachment 147762 [details] [diff] [review]
proposed fix

fairly safe fix - I reproduced this problem in 1.7...
Attachment #147762 - Flags: approval1.7?

Comment 6

15 years ago
Comment on attachment 147762 [details] [diff] [review]
proposed fix

a=mkaply
Attachment #147762 - Flags: approval1.7? → approval1.7+
(Assignee)

Comment 7

15 years ago
fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Assignee)

Updated

15 years ago
Keywords: fixed1.7
Is this the same problem that caused problems with MAPI send?
(Assignee)

Comment 9

15 years ago
same underlying failure, but two separate problems. The contract with the stmp
service is that the message sent ends with a CRLF, and it's up to the caller to
make sure that's true. It would be nice to fix it in the smtp code too but it's
not trivial.

Comment 10

15 years ago
Comment on attachment 147762 [details] [diff] [review]
proposed fix

>@@ -762,6 +763,7 @@
>   {
>     status = MIME_EncoderDestroy(m_encoder_data, PR_FALSE);
>     m_encoder_data = nsnull;
>+    needToWriteCRLFAfterEncodedBody = !m_parent;
>     if (status < 0)
>       goto FAIL;
>   }
Won't (status < 0) fail on 64-bit machines?

Comment 11

15 years ago
David, I just stumpled over this bug.
Would you please have a look at bug 237828? It looks to me as this is the same
problem and the now patched function is one of the guessed in comment #29.
(Assignee)

Comment 12

15 years ago
*** Bug 237828 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

15 years ago
Good catch, that function should be an int function, and not an nsresult - or
should be switched to return nsresults. This patch doesn't change anything about
that, though...
Product: MailNews → Core

Updated

13 years ago
Attachment #147753 - Flags: review?(ducarroz)
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.