After composing a message then clicking send, a duplicate HELO/EHLO error dialog is returned. nsSmtpProtocol::SmtpResponse calls nsSmtpProtocol::ReadLine which is supposed to return a well formed response line to be decoded in SmtpResponse. Instead ReadLine sometimes returns incomplete lines which are misinterpreted by SmtpResponse and triggers a EHLO. When the true end of the responses come into SmtpResponse it triggers another EHLO. A Hack that seems to work is as follows: PRInt32 nsSmtpProtocol::ReadLine(nsIInputStream * inputStream, PRUint32 length, char ** line) { PRUint32 numBytesRead = 0; PRUint32 numBytesLastRead = 0; PRBool foundLine = FALSE; while (!foundLine) { inputStream->Read(m_dataBuf+numBytesRead,1,&numBytesLastRead); if(m_dataBuf[numBytesRead] == '\n') foundLine = TRUE; numBytesRead += numBytesLastRead; } m_dataBuf[numBytesRead] = '\0'; if (line) *line = m_dataBuf; return numBytesRead; } It just sits in a while loop until the whole line is retrieved. I also removed the code that strips the CRLF at the end. It didn't seem necessary.

This bug prevents all outbound mail through my ISP. I'd recommend giving it a higher priority, because I'm probably not the only one.

which build are you using?

I'm using Win32/2001050815 and Linux/.81, same problem present on both. If it helps, my SMTP server is smtp.nwlink.com. The failure occurs before MAIL FROM is sent, so I'm guessing you can just set your testing machines to use that as their SMTP server and you'll see what I mean, regardless of whether you have an nwlink.com address or not. I've used sniffit and confirmed that EHLO nwlink.com is indeed being sent twice by Mozilla.

moving to 0.9.2

This one is a show-stopper for me since like the others, I can't use the e-mail client because I can't send any messages through my ISP. I'd be happily using Mozilla now if it weren't for this one :-( -- IV

If one of you guys can take the time to get me an SMTP log showing the duplicate HELO/EHLO then I'll see if I can't sneak something in. instructions can be found here: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap just use SMTP:5 as the module name instead of IMAP:5

1024[80539d0]: SMTP Connecting to: mail.hal-pc.org 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 220-mail.hal-pc.org ESMTP Ready Thu May 17 00:34:56 2001 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 220-Pleased to meet you, unless you are a 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: SPAMer. 1024[80539d0]: SMTP entering state: 14 1024[80539d0]: SMTP Send: EHLO hal-pc.org 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 220 Mail relayed for members on local dialups only. 1024[80539d0]: SMTP entering state: 14 1024[80539d0]: SMTP Send: EHLO hal-pc.org 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-mail.hal-pc.org Hello 206.180.129.190.dial-ip.hal-pc.org [206.180.129.190], pleased to meet you 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-EXPN 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-VERB 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-8BITMIME 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-SIZE 2000000 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-DSN 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-ONEX 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-ETRN 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250-XUSR 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 250 HELP 1024[80539d0]: SMTP entering state: 15 1024[80539d0]: SMTP entering state: 21 1024[80539d0]: SMTP entering state: 4 1024[80539d0]: SMTP Send: MAIL FROM:<ollie@hal-pc.org> 1024[80539d0]: SMTP entering state: 0 1024[80539d0]: SMTP Response: 503 mail.hal-pc.org Duplicate HELO/EHLO 1024[80539d0]: SMTP entering state: 6 1024[80539d0]: SMTP entering state: 12 1024[80539d0]: SMTP entering state: 13 nsSmtpProtocol::SmtpResponse expects a line starting with a number followed by a dash (ie 220-) which means more to follow or a number followed by a space which means last line of, in this case, a comment. nsSmtpProtocol::ReadLine enters a loop to read single bytes until a CR(LF) is encountered or the length of the buffer/available bytes has been read. The hack, in my initial post, loops until a full line is retrieved which may end up in an infinite loop if bytes stop flowing. The more elegant solution would be to make nsSmtpResponse more intelligent in decoding lines and know that a line was incomplete (maybe) and call ReadLine again.

this patch causes us to wait (without spinning the UI thread) until we have a complete line from the SMTP server. It fixes the problem for me when sending to mail@hal-pc.org. Ollie, can you give this patch a try if you use a debug build just to double verify?

Works fine for linux, but do not have VC++ to compile on my windows partition. Looking at the code, I believe it should resolve the problem for all platforms though.

Can this be fixed in 0.9.1 instead of 0.9.2? I won't be able to use Moz otherwise as I can't send e-mail.

Rats, just saw that it is probably frozen for 0.9.1 by the roadmap. Sorry.

adding PDT+. Please get this in to the trunk as soon as possible.

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

fix checked into the TIP.

Reproduced this problem using 2001060506 builds on mac, win98, linux. I did see the HELO/EHLO error dialog when trying to send mail with setting mail@hal-pc.org as my outgoing smtp server. Verified on mac,win98,linux on 2001061808 builds using the same as above I was able to send mail successfully without the above error.