2.20 KB, text/plain
1.32 KB, text/plain
4.70 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.3/mozilla-win32-1.3-installer.exe Problem sending mail to some SMTP servers. The SMTP gives long answers to ehlo command. Here is a hand-crafted example (telnetting to an SMTP port): ehlo 10.10.10.1 250-router.ost-poland.com.pl Hello [10.10.10.9], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-DELIVERBY 250 HELP This used to work allright with mozilla 1.2.1 I'm using currently, however, it fails with 1.3 final. I tried diagnosing the problem with a sniffer. I've found out, that the server response is splitted into two packets, witch 100 bytes lenght each. Reproducible: Always Steps to Reproduce: 1. Set up the SMTP server to produce long (multiline) responses to EHLO 2. Use the server as an outgoing server in MailNews 3. Send an email. Actual Results: Dialog that says the SMTP server is not responding. Expected Results: Accept the long EHLO answer and continue transimitting the message.
A much longer EHLO response was working fine for me when I worked on bug 151279. My build is hosed at the moment, can't test it right now.
Actually, WFM on trunk build 2003031808. I get the usual relaying denied message when trying that server which means it has passed the ehlo phase.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Well, installed Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030318 (on windows 2k). And the problem is still there. Probably this is a platform specific bug.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
The same with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030323. "The message could not be sent because connecting to SMTP server failed...".
Could you provide a complete sniffer log?
Created attachment 118283 [details] Faked SMTP server that reproduces the bug. This probram reproduces the bug. Start it, connecto to the 2025 port with MailNews and see what happens. See comments inside serve_client().
k, now I am able to provide more information. If server replies in one packet - there is no problem, no matter the size of the EHLO reply. If the server response comes splitted in two packets - MailNews says server is unable to answer. Run the test case attached (main.c). The correct behaviour of MailNews using this faked SMTP server is to hung up waiting for a reply to "MAIL TO:" request. However, if the EHLO reply is transmitted using two write() invocations (or splitted into multiple packets any other way), MailNews thinks the resver is not answering properly. Proper summary of the problem is: "Error when answer to EHLO comes in multiple packets."
Summary: Unable to send emails to SMTP servers that give long answers to EHLO. → Error when answer to EHLO comes in multiple packets.
Hi, as far as I can say, the bug is not only limited to the EHLO response. I've written a short perl-smtp server to verify this. Basically the script does: print SOCKET "220 my.host.name ready to speak ESMTP"; sleep 5; print SOCKET " at <some timestring here>",$crlf; So the break is in the first line from the SMTP-Server and mozilla reports an error as if the break is in the EHLO response. The sleep is important because some tcp-stacks might combine serveral write()'s into one packet if time between is short. If I comment out the sleep-line, sending the mail works fine. I suspect the function in mozilla that reads response lines from the SMTP-Server is buggy. Maybe doesn't wait until the CRLF at the end of the line comes in. I've tested my script (will attach it) against Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401 on SuSE 8.0.
That's a regression from patch of bug 189672. There was some code added to the global stream pump to prevent a listener to be called again and again although he doesn't read the data from the stream and so produce a infinite loop. The code just checks, if the called routine read at least one byte or not. If not, it stops the whole thing. The smtp linereader tests the presented input data for a \n as a indicator of a complete line. If there's no \n, no bytes will be read from the input. The routine will be left until new data arrives. And this behaviour of course collides with the loop check ... Two suggestions for a solution: 1. We always read the data available in the smtp line reader, regardless of it's a full smtp line or not, and concatenate the new bytes until we have a full line. 2. We add a flag in which the called listeners (e.g. the smtp code) can inform the anti-loop-code, that it didn't read the data by intention. So the anti-loop-code won't punish it for this behaviour.
Status: UNCONFIRMED → NEW
Ever confirmed: true
the "flag" in option #2 would be an explicit call to Suspend on the nsInputStreamPump.
i'll work on a patch...
Assignee: mscott → darin
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.4beta
Created attachment 122613 [details] [diff] [review] proposed patch This is absolutely different from what I wrote in comment #10. But it should solve our problem with less code. I just replaced SMTPs own ReadLine() function with the ReadNextLine() used by POP3, IMAP and NNTP protocol handler. This one doesn't wait if no complete line available but reads as much as is in the receivebuffer. So we won't be suspended by the InputStreamPump. I successfully tested this with Thorstens perlscript and a real server sending lines splitted across packets (see bug 204060). Since the ReadNextLine routine is in use for long time by the other protocol handlers I'd classify it as low risk patch. To this it fixes a regression from early 1.3a, saves code (as I wrote) and makes it more standard like. Enough point's for 1.4b?
if you do that, I think you need to fix the cram-md5 code not to subtract two bytes for the CRLF because the line reading code will eat the CRLF's, right? Otherwise, I think this is a good idea.
Yes, I need to remove this subtract - and I already did this in the patch: - m_responseText.Length() - 2 /* subtract CRLF */, nsnull); + m_responseText.Length(), nsnull);
Comment on attachment 122613 [details] [diff] [review] proposed patch sorry, my mistake, I looked for it and I still didn't see it the first time :-( looks good.
Attachment #122613 - Flags: review+
Comment on attachment 122613 [details] [diff] [review] proposed patch whoops, sorry, I don't see us freeing m_lineStreamBuffer, and we should.
Attachment #122613 - Flags: review+ → review-
Created attachment 122628 [details] [diff] [review] patch with delete of m_lineStreamBuffer Ok, this time you're right. Here it is.
Attachment #122613 - Attachment is obsolete: true
Comment on attachment 122628 [details] [diff] [review] patch with delete of m_lineStreamBuffer r=bienvenu, but please remove the null check before the delete - it's not needed since delete checks for null implicitly. Thx for fixing this!
Attachment #122628 - Flags: review+
Created attachment 122629 [details] [diff] [review] patch v3 Ok, without check now.
Attachment #122628 - Attachment is obsolete: true
I doubt there's any chance of this making it into 1.4b, correct?
correct, it will go into 1.4 final
Assignee: darin → ch.ey
Status: ASSIGNED → NEW
Comment on attachment 122629 [details] [diff] [review] patch v3 sr=bienvenu
Attachment #122629 - Flags: superreview+
Comment on attachment 122629 [details] [diff] [review] patch v3 r/a=sspitzer for 1.4 final
Status: NEW → ASSIGNED
Target Milestone: mozilla1.4beta → mozilla1.4final
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
email@example.com, can you verify that this is fixed for you?
*** Bug 205009 has been marked as a duplicate of this bug. ***
Yes, it is working for me. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030515 crashes for completely different reasons.
Verifying per comments from firstname.lastname@example.org, thanks.
Status: RESOLVED → VERIFIED
*** Bug 209938 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.