Last Comment Bug 723109 - Broken implementation of mail protocols on certain servers (e.g. IceWarp 10.3.5) don't work in TB 10 and later (BAD No such command as "1" to "1 capability" if IMAPS, 500 5.5.1 Command unrecognized: to "EHLO" if SMTPS, after fix of bug 665814)
: Broken implementation of mail protocols on certain servers (e.g. IceWarp 10.3...
Status: NEW
[see comments 32 & 33 for specific de...
: regression
Product: MailNews Core
Classification: Components
Component: Networking: IMAP (show other bugs)
: 10
: All All
: -- major with 4 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://getsatisfaction.com/mozilla_me...
: 733725 788577 (view as bug list)
Depends on: 702111
Blocks: 723741 698787 788577
  Show dependency treegraph
 
Reported: 2012-02-01 07:30 PST by leo
Modified: 2016-09-04 06:55 PDT (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
IceWarp SMTP FlowChart (196.67 KB, image/png)
2012-02-02 12:32 PST, TML
no flags Details

Description leo 2012-02-01 07:30:32 PST
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).
Comment 1 Stefano Terenzi 2012-02-01 08:48:04 PST
I have the same identical problem with tb10.0 on WinXP. tb9.x.x works fine on both win and linux.
Comment 2 leo 2012-02-01 10:30:56 PST
i confirm the problem if the domain address is not the same of the domain of imap server (probably problems about the certificate?).
Comment 3 rsx11m 2012-02-01 20:54:40 PST
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?
Comment 4 rsx11m 2012-02-01 20:59:17 PST
(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?
Comment 5 Magnus Melin 2012-02-01 23:12:56 PST
An imap log could be useful
https://wiki.mozilla.org/MailNews:Logging#Generating_a_Protocol_Log
Comment 6 Stefano Terenzi 2012-02-01 23:51:30 PST
(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
Comment 7 Stefano Terenzi 2012-02-01 23:55:20 PST
(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.
Comment 8 Stefano Terenzi 2012-02-02 00:04:26 PST
(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]" ..."
Comment 9 Tony 2012-02-02 00:37:03 PST
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
Comment 10 Ludovic Hirlimann [:Usul] 2012-02-02 00:39:20 PST
Tony what kind of server and what version are you running ?
Comment 11 Nikolay Shopik 2012-02-02 00:40:29 PST
Tony, any antiviruses you running on this machine?
Comment 12 Tony 2012-02-02 00:45:40 PST
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.
Comment 13 leo 2012-02-02 02:16:11 PST
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
Comment 14 Stefano Terenzi 2012-02-02 02:21:03 PST
(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).
Comment 15 Mark Banner (:standard8, limited time in Dec) 2012-02-02 02:37:35 PST
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.
Comment 16 leo 2012-02-02 02:43:53 PST
(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.
Comment 17 Stefano Terenzi 2012-02-02 03:05:42 PST
(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.
Comment 18 Magnus Melin 2012-02-02 04:17:01 PST
Confirming based on multiple comments.
Comment 19 TML 2012-02-02 06:29:20 PST
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.
Comment 20 David :Bienvenu 2012-02-02 08:38:04 PST
Brian, could this be bug 702111?
Comment 21 Tony 2012-02-02 08:41:24 PST
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.
Comment 22 Honza Bambas (:mayhemer) 2012-02-02 08:54:55 PST
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.
Comment 23 Stefano Terenzi 2012-02-02 09:14:07 PST
(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.

-
Comment 24 Honza Bambas (:mayhemer) 2012-02-02 09:19:14 PST
Duplicate of bug 702111 as confirmed by comment 23.

*** This bug has been marked as a duplicate of bug 702111 ***
Comment 25 TML 2012-02-02 09:28:24 PST
Confirming TB10.0 IMAP/SMTP works correctly with SSL and Merak IceWarp when NSS_SSL_CBC_RANDOM_IV=0.
Comment 26 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-02-02 11:41:54 PST
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.)
Comment 27 David :Bienvenu 2012-02-02 11:49:31 PST
(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?
Comment 28 Tony 2012-02-02 11:54:48 PST
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.
Comment 29 David :Bienvenu 2012-02-02 11:57:33 PST
(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.
Comment 30 TML 2012-02-02 12:00:17 PST
We've opened a ticket with Merak, will advise.
Comment 31 Tony 2012-02-02 12:02:33 PST
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.
Comment 32 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-02-02 12:08:05 PST
(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.
Comment 33 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-02-02 12:11:17 PST
(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.
Comment 34 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-02-02 12:18:32 PST
(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.
Comment 35 TML 2012-02-02 12:32:29 PST
Created attachment 593941 [details]
IceWarp SMTP FlowChart

IceWarp SMTP flowchart attached, looks like AV is being used later in the connection process.  I think we can rule out the AV.
Comment 36 David :Bienvenu 2012-02-02 12:38:26 PST
(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.
Comment 37 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-02-02 12:42:48 PST
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.
Comment 38 Roland Tanglao :rolandtanglao 2012-02-02 16:08:40 PST
Looks like we have at least 1 instance of this bug in Get Satisfaction so adding the tag url to the URL field
Comment 39 TML 2012-02-03 06:35:58 PST
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.
Comment 40 Mark Banner (:standard8, limited time in Dec) 2012-02-03 07:35:33 PST
I'll be happy to do that in a couple of hours when I get back to my desk.
Comment 41 TML 2012-02-03 09:15:09 PST
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.
Comment 42 Gonzalo 2012-02-08 02:42:55 PST
Thanks a lot TML.
Got Icewarp 10.3.5, and had this problem also with POP3 in SSL.
Works perfect after the denytelnet change.
Comment 43 WADA 2012-02-08 07:50:10 PST
*** Bug 723741 has been marked as a duplicate of this bug. ***
Comment 44 TML 2012-02-08 08:12:11 PST
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?
Comment 45 Ludovic Hirlimann [:Usul] 2012-02-28 08:55:43 PST
David ?
Comment 46 David :Bienvenu 2012-02-28 08:59:55 PST
Ludo, this is extremely well-understood as a server issue, isn't it? What do you want from me?
Comment 47 TML 2012-02-28 10:20:35 PST
Merak still investigating whether to accomodate this or not.

I think it's safe to close this issue at this point.
Comment 48 Roland Tanglao :rolandtanglao 2012-02-29 11:59:51 PST
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!
Comment 49 Roland Tanglao :rolandtanglao 2012-02-29 14:46:47 PST
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
Comment 50 James Carey 2012-03-07 10:24:25 PST
*** Bug 733725 has been marked as a duplicate of this bug. ***
Comment 51 pavel.zahradnik 2013-08-30 06:25:38 PDT
(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
Comment 52 Wayne Mery (:wsmwk, NI for questions) 2016-09-04 06:55:25 PDT
*** Bug 788577 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.