Closed Bug 204060 Opened 22 years ago Closed 22 years ago

Unable to send messages when multiple 220 responses are received on SMTP connect

Categories

(MailNews Core :: Networking: SMTP, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: thomas.swan, Assigned: mscott)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030429 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030429 Mozilla either drops or hangs the connection to an SMTP server that delivers multiple 220 responses for a single connection. A connection with the response of the following will cause Mozilla to be unable to send. 220 Such and such extra header v1.0 220 ESMTP Foobar Server; Mozilla cannot connect to me; v1.0 Mozilla apparently expects a single line response before sending its request or connecting and therefore doesn't know what is happening.... A single line response of 220 ESMTP Foobar Server; Mozilla can connect to me; v1.0 will work. Reproducible: Always Steps to Reproduce: 1. Set up an SMTP server to deliver (2) 220 response on connect (multiline) 2. Try to send mail throught it 3. Mozilla hangs (but drops connection) Actual Results: No mail sent Expected Results: Send the mail
.
Component: Mail Back End → Networking: SMTP
QA Contact: esther → nbaca
This was reproduceable on Mozilla 1.3, 1.3.1RC, Moz 1.4a and nightlies including and up to
What do you mean with in step 3 with "Mozilla hangs"? The application freezes? That would be bad and has to be fixed. But IMO the server is buggy. Multiple lines for one state are allowed in general. But all except the last line must have a "-" between response code and text (e.g. "220-Such and such extra header v1.0") to signal more will follow. Mozilla isn't greedy and doesn't empty the whole buffer when parsing a state. So it only gets one 220, answers EHLO, reads next 220 and answers again EHLO. But the server is already in the next state after the first EHLO and answers with 250 and his abilities. I think it doesn't expect to receive another EHLO and hangs up or answers with an error code that causes Mozilla to hang up. I've no bogus SMTP server here, just a little script simulating two 220, thus I don't see what a (or better your) server does after the second EHLO from Mozilla. Can we get a client-side POP3 protocol log from you? Here's how to: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap If it's a official server connected to the internet that produces this two 220, would you be so kind to post it's address please?
The 220 headers are correct, with the 220-... on all but the last line. When sending, all I get is the following. "Sending of message failed. The message could not be sent because connecting to SMTP server smtp.wild.net failed..." The log file does not reveal anything interesting. 0[2741d0]: SMTP Connecting to: smtp.wild.net 0[2741d0]: SMTP entering state: 0 0[2741d0]: SMTP Connecting to: smtp.wild.net 0[2741d0]: SMTP entering state: 0
Using Debug level 10... Email addresses and server IP masked with ??? 0[2741d8]: SMTP Connecting to: smtp.wild.net 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 220-InterScan Version 3.0.1A $Date: 1999/10/29 18:07:45 $: Ready 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 220 ???.wild.net ESMTP Sendmail 8.10.1/8.10.1; Mon, 5 May 2003 09:59:58 -0500 0[2741d8]: SMTP entering state: 14 0[2741d8]: SMTP Send: EHLO wild.net 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250-???.wild.net Hello localhost [???.???.???.???], pleased to meet you 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250-ENHANCEDSTATUSCODES 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250-8BITMIME 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250-SIZE 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250-DSN 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250-ONEX 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250-ETRN 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250-XUSR 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250 HELP 0[2741d8]: SMTP entering state: 15 0[2741d8]: SMTP entering state: 21 0[2741d8]: SMTP entering state: 4 0[2741d8]: SMTP Send: MAIL FROM:<????@????.???> 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250 2.1.0 <????@????.???>... Sender ok 0[2741d8]: SMTP entering state: 6 0[2741d8]: SMTP Send: RCPT TO:<????@????.???> 0[2741d8]: SMTP entering state: 0 0[2741d8]: SMTP Response: 250 2.1.5 <????@????.???>... Recipient ok 0[2741d8]: SMTP entering state: 7 0[2741d8]: SMTP Send: DATA 0[2741d8]: SMTP entering state: 0
Er, Thomas, what does this mean? It works now? It works only with debug level 10?
No, Mozilla doesn't work regardless of the debug level. After Moz enters state 0 after the DATA command, it drops the network connection. I was verifying that I could send by telnetting to port 25 and doing the same data sequence manually. And the problem lies with Mozilla dropping the connection and not proceeding to deliver the message to the server. Mozilla works with other SMTP servers and continues on the 354 response. In the case that I'm having problems with, Mozilla is not acknowledging the 354 response. So, I'm wonder why Mozilla refuses to send the message.
Christian, I sent an email offline to you <ch.ey 4t gmx d0t net> with an address to test with if you wanted to go through that server.
Ah, ok, so an interesting case. Currently I can't test the sending process because I'm getting a splitted 220 response: The first tcp packet contains "220", another one with "-InterScan Version" a.s.o. At this point bug 198573 knocks the connection down (see comment 10 there). That seems what caused what you post in comment 4 here. Strange server with different moods ...
Fixed by checkin for bug 198573
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Oh, great, thanks.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.