I have an account 'address@domain-1', the server imap4 for that account is 'mail.domain-2'. My connection is done with an imap account with ssl/tls on port 993 and normal password. I upgraded from thunderbird 9.0.1 to 10.0 and when i go on the inbox imap folder, thunderbird refuses connection with 'account address@domain-1 is not an imap4 server'. I tried to downgrade to version 9.0.1 and the problem disappeared, i have this problem only with version 10.0. I tried with tb10.0 and a new profile and problem remain. I have no problem with tb10.0 and 'normal' imap account on port 143 (STARTTLS or no security).

I have the same identical problem with tb10.0 on WinXP. tb9.x.x works fine on both win and linux.

i confirm the problem if the domain address is not the same of the domain of imap server (probably problems about the certificate?).

Moving to IMAP component, though this may be an NSS issue if a regression based on any change there. Does SSL/TLS-based SMTP (port 465) to the provider work? Also, what's the exact error message received when the connection fails?

(In reply to rsx11m from comment #3) > Also, what's the exact error message received when the connection fails? Sorry, I've missed that in your opening post: > 'account address@domain-1 is not an imap4 server'. Stefano, do you get the same message?

An imap log could be useful https://wiki.mozilla.org/MailNews:Logging#Generating_a_Protocol_Log

(In reply to rsx11m from comment #4) > (In reply to rsx11m from comment #3) > > Also, what's the exact error message received when the connection fails? > > Sorry, I've missed that in your opening post: > > 'account address@domain-1 is not an imap4 server'. > > Stefano, do you get the same message? Yes , I receive the same message

(In reply to rsx11m from comment #3) > Moving to IMAP component, though this may be an NSS issue if a regression > based on any change there. Does SSL/TLS-based SMTP (port 465) to the > provider work? > > Also, what's the exact error message received when the connection fails? For me, SSL/TLS-based SMTP (port 465) don't work. Works fine on tb 9.x.x.

(In reply to rsx11m from comment #3) > Moving to IMAP component, though this may be an NSS issue if a regression > based on any change there. Does SSL/TLS-based SMTP (port 465) to the > provider work? > > Also, what's the exact error message received when the connection fails? The exact error message receive on an SSL/TLS-based SMTP (port 465) based session is: "5.5.1 Command unrecognized: "HLO [xxx.xxx.xxx.xxx]" ..."

I'm having the same problems for all users that have upgraded to TB10 turning off SSL in TB resolves the problem not that doing that is a fix. Here is my servers IMAP and SMTP com logs: ---------IMAP LOG-------- IP.AD.DRE.SS [0154] 03:35:14 Connected IP.AD.DRE.SS [0154] 03:35:14 >>> * OK COMPANY, Inc. Mail Server IMAP4rev1 Thu, 02 Feb 2012 03:35:14 -0500 IP.AD.DRE.SS [0154] 03:35:14 >>> BAD No such command as "1" IP.AD.DRE.SS [0154] 03:35:14 <<< capability IP.AD.DRE.SS [0154] 03:35:14 >>> BAD Command unknown IP.AD.DRE.SS [0154] 03:35:14 >>> BAD Command unknown IP.AD.DRE.SS [0154] 03:35:14 Disconnected ---------SMTP LOG-------- IP.AD.DRE.SS [049C] 03:17:47 Connected, local IP=IP.AD.DRE.SS IP.AD.DRE.SS [049C] 03:17:52 >>> 220 mail.DOMAIN.com ESMTP -------, Inc. Mail Server; Thu, 02 Feb 2012 03:17:52 -0500 IP.AD.DRE.SS [049C] 03:17:52 >>> 500 5.5.1 Command unrecognized: "" IP.AD.DRE.SS [049C] 03:17:52 <<< HLO [10.60.100.104] IP.AD.DRE.SS [049C] 03:17:52 >>> 500 5.5.1 Command unrecognized: "HLO [10.60.100.104]" IP.AD.DRE.SS [049C] 03:17:54 >>> 500 5.5.1 Command unrecognized: "" IP.AD.DRE.SS [049C] 03:17:54 <<< ELO [10.60.100.104] IP.AD.DRE.SS [049C] 03:17:54 >>> 500 5.5.1 Command unrecognized: "ELO [10.60.100.104]" IP.AD.DRE.SS [049C] 03:17:56 *** <> <> 0 0 00:00:00 INCOMPLETE-SESSION IP.AD.DRE.SS [049C] 03:17:56 Disconnected

Tony what kind of server and what version are you running ?

Tony, any antiviruses you running on this machine?

I'm running Merk IceWarp version 10.3.5. Has always been reliable and worked with Thunderbird in the past and continues to work with all other e-mail clients with SSL/TLS enabled. The server processes all messages through a Kaspersky antivirus engine built in to the server software.

these are the logs for imap connection with tb10.0 e tb9.0.1 **** TB10.0 **** -1583350928[9e6d4530]: ImapThreadMainLoop entering [this=9fecbc00] -1223649488[b6f3c1c0]: 9fecbc00:DOMAIN-2.toscana.it:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN -1583350928[9e6d4530]: 9fecbc00:DOMAIN-2.toscana.it:NA:ProcessCurrentURL: entering -1583350928[9e6d4530]: 9fecbc00:DOMAIN-2.toscana.it:NA:ProcessCurrentURL:imap://****%2E****%40DOMAIN-1%2Etoscana%2Eit@DOMAIN-2.toscana.it:993/select%3E/INBOX: = currentUrl -1583350928[9e6d4530]: ReadNextLine [stream=9e6d0028 nb=74 needmore=0] -1583350928[9e6d4530]: 9fecbc00:DOMAIN-2.toscana.it:NA:CreateNewLineFromSocket: * OK SERVER-NAME IMAP4rev1 Thu, 02 Feb 2012 11:05:33 +0100^M -1583350928[9e6d4530]: 9fecbc00:DOMAIN-2.toscana.it:NA:SendData: 1 capability^M -1583350928[9e6d4530]: ReadNextLine [stream=9e6d0028 nb=29 needmore=0] -1583350928[9e6d4530]: 9fecbc00:DOMAIN-2.toscana.it:NA:CreateNewLineFromSocket: BAD No such command as "1"^M -1583350928[9e6d4530]: 9fecbc00:DOMAIN-2.toscana.it:NA:ProcessCurrentURL: aborting queued urls -1583350928[9e6d4530]: 9fecbc00:DOMAIN-2.toscana.it:NA:TellThreadToDie: close socket connection -1583350928[9e6d4530]: ImapThreadMainLoop leaving [this=9fecbc00] **** TB9.0.1 **** -1551893648[a4f8ac90]: ImapThreadMainLoop entering [this=a4324800] -1223923920[b6e3c1c0]: a4324800:DOMAIN-2.toscana.it:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN -1551893648[a4f8ac90]: a4324800:DOMAIN-2.toscana.it:NA:ProcessCurrentURL: entering -1551893648[a4f8ac90]: a4324800:DOMAIN-2.toscana.it:NA:ProcessCurrentURL:imap://****%2E****%40DOMAIN-1%2Etoscana%2Eit@DOMAIN-2.toscana.it:993/select%3E/INBOX: = currentUrl -1551893648[a4f8ac90]: ReadNextLine [stream=a381b208 nb=74 needmore=0] -1551893648[a4f8ac90]: a4324800:DOMAIN-2.toscana.it:NA:CreateNewLineFromSocket: * OK SERVER-NAME IMAP4rev1 Thu, 02 Feb 2012 11:03:46 +0100^M -1551893648[a4f8ac90]: a4324800:DOMAIN-2.toscana.it:NA:SendData: 1 capability^M -1551893648[a4f8ac90]: ReadNextLine [stream=a381b208 nb=235 needmore=0] -1551893648[a4f8ac90]: a4324800:DOMAIN-2.toscana.it:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=GSSAPI SORT THREAD=ORDEREDSUBJECT UIDPLUS QUOTA ACL NAMESPACE CHILDREN IDLE ID UNSELECT METADATA X-ICEWARP-SERVER X-MOVE MSEARCH XLIST CREATE-SPECIAL-USE^M -1551893648[a4f8ac90]: ReadNextLine [stream=a381b208 nb=27 needmore=0] -1551893648[a4f8ac90]: a4324800:DOMAIN-2.toscana.it:NA:CreateNewLineFromSocket: 1 OK CAPABILITY Completed^M -1551893648[a4f8ac90]: try to log in

(In reply to Tony from comment #9) > I'm having the same problems for all users that have upgraded to TB10 > turning off SSL in TB resolves the problem not that doing that is a fix. > > Here is my servers IMAP and SMTP com logs: > > ---------IMAP LOG-------- > IP.AD.DRE.SS [0154] 03:35:14 Connected > IP.AD.DRE.SS [0154] 03:35:14 >>> * OK COMPANY, Inc. Mail Server IMAP4rev1 > Thu, 02 Feb 2012 03:35:14 -0500 > IP.AD.DRE.SS [0154] 03:35:14 >>> BAD No such command as "1" > IP.AD.DRE.SS [0154] 03:35:14 <<< capability > IP.AD.DRE.SS [0154] 03:35:14 >>> BAD Command unknown > IP.AD.DRE.SS [0154] 03:35:14 >>> BAD Command unknown > IP.AD.DRE.SS [0154] 03:35:14 Disconnected > > > ---------SMTP LOG-------- > IP.AD.DRE.SS [049C] 03:17:47 Connected, local IP=IP.AD.DRE.SS > IP.AD.DRE.SS [049C] 03:17:52 >>> 220 mail.DOMAIN.com ESMTP -------, Inc. > Mail Server; Thu, 02 Feb 2012 03:17:52 -0500 > IP.AD.DRE.SS [049C] 03:17:52 >>> 500 5.5.1 Command unrecognized: "" > IP.AD.DRE.SS [049C] 03:17:52 <<< HLO [10.60.100.104] > IP.AD.DRE.SS [049C] 03:17:52 >>> 500 5.5.1 Command unrecognized: "HLO > [10.60.100.104]" > IP.AD.DRE.SS [049C] 03:17:54 >>> 500 5.5.1 Command unrecognized: "" > IP.AD.DRE.SS [049C] 03:17:54 <<< ELO [10.60.100.104] > IP.AD.DRE.SS [049C] 03:17:54 >>> 500 5.5.1 Command unrecognized: "ELO > [10.60.100.104]" > IP.AD.DRE.SS [049C] 03:17:56 *** <> <> 0 0 00:00:00 INCOMPLETE-SESSION > IP.AD.DRE.SS [049C] 03:17:56 Disconnected I confirm "BAD No such command as "1"" on IMAPS session and ">>> 500 5.5.1 Command unrecognized: "" <<< capability " on SMTPS session on my own Icewarp 10.3.4 server (linux version).

Can the people seeing this problem try installing a 10.0 beta 4 build from here: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/10.0b4-candidates/build1/ and seeing if that fixes the issue or not. We changed some things in 10.0b5 wrt ssl, so I want to eliminate the chance that these caused it.

(In reply to Mark Banner (:standard8) from comment #15) > Can the people seeing this problem try installing a 10.0 beta 4 build from > here: > > and seeing if that fixes the issue or not. We changed some things in 10.0b5 > wrt ssl, so I want to eliminate the chance that these caused it. sorry, i have the same problem with tb10.0 beta 4.

(In reply to leo from comment #16) > (In reply to Mark Banner (:standard8) from comment #15) > > Can the people seeing this problem try installing a 10.0 beta 4 build from > > here: > > > > and seeing if that fixes the issue or not. We changed some things in 10.0b5 > > wrt ssl, so I want to eliminate the chance that these caused it. > > sorry, i have the same problem with tb10.0 beta 4. same problem with tb10.0 beta 4 on both imaps and smtps session.

Confirming based on multiple comments.

We are also running Merak IceWarp (10.3.3) and having this issue. We went back to no SSL and port 143 to mitigate it. One other note, we also saw a similar issue on outbound SMTP port 465 with SSL/TLS. The error was "An error occurred sending mail: SMTP server error. The server responded: 5.5.1 Command unrecognized: "HLO [192.168.x.x]" Contact your mail administrator for assistance." We had to go back to port 25 with no security to get outbound to work.

Brian, could this be bug 702111?

Just for the record. I have also tried 10.0 beta 4 as well as the current release of EaryBird and both show the same problem.

Hmm.. just an idea but, could be related to bug 665814. Try setting NSS_SSL_CBC_RANDOM_IV=0 in your env and check again. Also see bug 702111 that, when confirmed with the above, we will duplicate this one to.

(In reply to Honza Bambas (:mayhemer) from comment #22) > Hmm.. just an idea but, could be related to bug 665814. > > Try setting NSS_SSL_CBC_RANDOM_IV=0 in your env and check again. > > > Also see bug 702111 that, when confirmed with the above, we will duplicate > this one to. With NSS_SSL_CBC_RANDOM_IV=0 tb10.0-b4 and tb10.0 works correctly on both imaps and smtps sessions. -

Duplicate of bug 702111 as confirmed by comment 23.

Confirming TB10.0 IMAP/SMTP works correctly with SSL and Merak IceWarp when NSS_SSL_CBC_RANDOM_IV=0.

I think we should let bug 702111 be about Gecko in general, and leave this bug open for dealing with mail servers. We may need to do something different than "WONTFIX" for mail servers, which is basically what bug 702111 is gravitating to for HTTP servers. Putting NSS_SSL_CBC_RANDOM_IV=0 in the environment is a much better workaround for this issue than disabling SSL. I highly recommend that the people who disabled SSL re-enable it again after setting NSS_SSL_CBC_RANDOM_IV=0 in the environment. (Remember to check back in a couple of months to remove that environment variable.)

(In reply to Brian Smith (:bsmith) from comment #26) > I think we should let bug 702111 be about Gecko in general, and leave this > bug open for dealing with mail servers. We may need to do something > different than "WONTFIX" for mail servers, which is basically what bug > 702111 is gravitating to for HTTP servers. Is there some sort of evangelism needed for mail server authors/maintainers for this issue? And/or is it possible that it's actually the Kaspersky code that's broken? Is there a code fix that Thunderbird can make to do the equivalent of that environment variable when making SSL connections to mail servers?

Hi David, Can I ask what makes you think Kaspersky might be the problem? I could be wrong but my understanding is that Kaspersky in Icewarp is processing messages after they have been sucessfully handed off to the server.

(In reply to Tony from comment #28) > Hi David, > > Can I ask what makes you think Kaspersky might be the problem? > > I could be wrong but my understanding is that Kaspersky in Icewarp is > processing messages after they have been sucessfully handed off to the > server. I really don't know how Kaspersky inserts itself into the process, so I was just asking...just didn't want to assume it was the server at fault.

We've opened a ticket with Merak, will advise.

Thanks David, I guess my assumption was that the problem has to be TB10 since Merk/Icewarp continues to work with SSL on all other clients.

(In reply to David :Bienvenu from comment #27) > (In reply to Brian Smith (:bsmith) from comment #26) > > I think we should let bug 702111 be about Gecko in general, and leave this > > bug open for dealing with mail servers. We may need to do something > > different than "WONTFIX" for mail servers, which is basically what bug > > 702111 is gravitating to for HTTP servers. > > Is there some sort of evangelism needed for mail server authors/maintainers > for this issue? And/or is it possible that it's actually the Kaspersky code > that's broken? Yes to both. (In reply to David :Bienvenu from comment #27) > Is there a code fix that Thunderbird can make to do the equivalent of that > environment variable when making SSL connections to mail servers? SSL_OptionSet(fd, SSL_CBC_RANDOM_IV, PR_FALSE); Many software vendors have already fixed the bugs in their servers so it is often just a matter of getting the site to update to a version with the fix. However, especially for non-HTTP servers (e.g. mail servers), I bet there are still a few unfixed server implementations, and probably quite a few servers that need to be updated. The change we made to our SSL/TLS implementation in bug 665814 is compliant with all versions of the SSL/TLS protocols and it is compatible with OpenSSL and other SSL implementations. However, many products have bugs in their SMTP, IMAP, POP, LDAP, and/or HTTP code in how they parse what the client sends them, that were previously accidentally masked, but which this fix makes evident. For example, let's say the server is waiting for the client to say "Hello." Prior to Thunderbird 10, Thunderbird would send "Hello" all in one part. In Thunderbird 10 and later, we will send "H" and "ello" in separate parts. Servers are supposed to combine them on their own to get "Hello" again, but some servers are written in a kind of simple way where they do not always do that when they should. So, to resolve this issue, users should: 1. Ask their system administrator to ask the server software/appliance vendor for an update that fixes the issue. 2. Temporarily put NSS_SSL_CBC_RANDOM_IV=0 in the environment on their local machine. (The best way to do this would be to create a batch file that sets NSS_SSL_CBC_RANDOM_IV=0 and then runs Thunderbird, because this limits the scope of the workaround to just Thunderbird. However, if that is too difficult, you can change the environment for all software you run. On Windows 7 (and probably Vista), you can do this through the UI you can find by typing "Edit environment variables for your account" into the Start Menu's search box.

(In reply to Tony from comment #31) > Thanks David, I guess my assumption was that the problem has to be TB10 > since Merak/Icewarp continues to work with SSL on all other clients. Please point the developers at Merak to: https://bugzilla.mozilla.org/show_bug.cgi?id=723109#c32 https://bugzilla.mozilla.org/show_bug.cgi?id=702111 https://bugzilla.mozilla.org/show_bug.cgi?id=665814 These links should give them EXACTLY the information they need to fix any problem they may have in their product.

(In reply to Brian Smith (:bsmith) from comment #32) > SSL_OptionSet(fd, SSL_CBC_RANDOM_IV, PR_FALSE); Knowing how safe it is to use this workaround permanently and/or to provide an option for using it in Thunderbird depends on an analysis of each protocol (SMTP, IMAP, POP, LDAP, NNTP, etc.) and a particular analysis of Thunderbird's specific use of each protocol. In the case of HTTP, we didn't find the SSL_CBC_RANDOM_IV to be necessary as far as the *current* state of Firefox was concerned, but we left it on anyway as somewhat of an insurance policy. I would be happy to talk to somebody who is well-versed in SMTP, IMAP, POP, LDAP, NNTP, and/or any other protocol that Thunderbird implements, to determine how important the 1/(n-1) record splitting is for each protocol. It would take multiple working days to get a definitive long-term answer.

IceWarp SMTP flowchart attached, looks like AV is being used later in the connection process. I think we can rule out the AV.

(In reply to Brian Smith (:bsmith) from comment #34) > (In reply to Brian Smith (:bsmith) from comment #32) > > SSL_OptionSet(fd, SSL_CBC_RANDOM_IV, PR_FALSE); > > Knowing how safe it is to use this workaround permanently and/or to provide > an option for using it in Thunderbird depends on an analysis of each > protocol (SMTP, IMAP, POP, LDAP, NNTP, etc.) and a particular analysis of > Thunderbird's specific use of each protocol. In the case of HTTP, we didn't > find the SSL_CBC_RANDOM_IV to be necessary as far as the *current* state of > Firefox was concerned, but we left it on anyway as somewhat of an insurance > policy. I would be happy to talk to somebody who is well-versed in SMTP, > IMAP, POP, LDAP, NNTP, and/or any other protocol that Thunderbird > implements, to determine how important the 1/(n-1) record splitting is for > each protocol. It would take multiple working days to get a definitive > long-term answer. I'm happy to talk to you about those protocols, except for LDAP, which I'm not that familiar with. I do believe that LDAP is a binary protocol, so it's fairly different from the others.

See also bug 702111 comment c37, reproduced here: Brad Wetmore wrote: > Over the last two months, I have chased several escalations with exactly > these problems, generally falling into one of two patterns. It's amazing > how much code either doesn't check return values: > > read(fd, buf, size); // assume we get "size" bytes (!) > > or expects size to be a full read: > > retval = read(fd, buf, size); > if (retval != size) { > // fail...short read > } > > Note that TCP layer could also decide to segment packets, code like the > above will fail.

Looks like we have at least 1 instance of this bug in Get Satisfaction so adding the tag url to the URL field

Merak says one customer running 10.3.5 is reporting this issue isn't showing up. Based on what I read here, that's not correct. We are still on 10.3.3, so can someone running IceWarp 10.3.5 confirm the issue exists on that version? I think Merak is confused, and I'd like to get them started on a patch, rather than wasting time waiting until we can prove 10.3.5 is still broken after the upgrade this weekend. Merak is also asking for RDP access to the mail server, which we can't do b/c of corporate policy. If anyone can, please contact Merak support. Thx.

I'll be happy to do that in a couple of hours when I get back to my desk.

Per Merak, in the mgmt tool, navigate to File->API Console, search on "denytelnet" and make sure the option mail.security.protocols.denytelnet is set to false. (I believe the default for the setting is true.) I did this on IceWarp 10.3.3 and after a few minutes, it allowed me to SSL/TLS IMAP and SMTP in TB 10.0 without the environment variable and had no issues. So maybe Merak doesn't have a flawed SSL/TLS implementation, rather they need to re-work their "telnet detection" algorithm to ignore the NSS record splitting.

Thanks a lot TML. Got Icewarp 10.3.5, and had this problem also with POP3 in SSL. Works perfect after the denytelnet change.

FYI, Merak says they can't make the denytelnet feature compatible with the NSS fix because: "TB 10 is not sending the SMTP commands as complete strings like all other email clients. Its sending one character at a time which is how telnet performs..." As I understand it, the fix is 1/(n-1) not 1/1/1/1... and I pointed that out to them in my reply. I reminded them that IMAP is affected too, not just SMTP. I suggested that simply waiting for a second single byte before flagging the session as "telnet" might fix the detection algo. Honestly, I'm not sure how valuable the denytelnet feature is anyway from a security perspective. Obviously, it can't prevent the initial telnet connect, just terminate the session when it thinks the other end is using telnet. We use telnet to test the mail server ports are listening, but we don't actually try to issue commands. Anyone out there have an opinion if this feature is worth pushing them to fix?

David ?

Ludo, this is extremely well-understood as a server issue, isn't it? What do you want from me?

Merak still investigating whether to accomodate this or not. I think it's safe to close this issue at this point.

Apparently older versions of Microsoft Exchange Server 2010 have the SSL issue https://getsatisfaction.com/mozilla_messaging/topics/cant_send_email_with_thunderbird_10_0_2#reply_8174859 I have asked the user to upgrade to Microsoft Exchange Server 2010 SP2 (my guess he is running SP1 or older version) to see if that fixes the problem, hopefully it does!

And as per bug 723551 , comment 16: https://bugzilla.mozilla.org/show_bug.cgi?id=723551#c16 the same SSL problem will occur with TB 10 and Mail Server Providers using Microsoft Exchange until the Server OS is updated with the following Microsoft patch: MS12-006 aka KB2643584 aka KB2585542: http://support.microsoft.com/kb/2643584

(In reply to TML from comment #47) Seems to be solved on IceWarp 10.4.5, i.e. TB 17.0.8 can connect via SSL/TLS