307114 - IMAP4 vs. SSL - Wrong error message

Status: RESOLVED WORKSFORME

(Thunderbird :: Preferences, enhancement)

Description

[u97006]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

When trying to connect to an Imap Server, which only accepts SSL and not having
SSL enabled (as is default after going through the account wizard) the followig
error is displayed when trying to fetch mails:

"Mail Server xy is not an IMAP4 mail server."

Reproducible: Always

Steps to Reproduce:
1. set up new account with the account wizard
2. try to fetch mail from imap-ssl server
Actual Results:  

"Mail Server xy is not an IMAP4 mail server."

Expected Results:  
Display error message on probably missing SSL.

Comment 1

[Scott Lamb]

I received this message today while just browsing a thread. My mailserver is certainly an IMAP4 mail server. If Thunderbird thinks it is not speaking the protocol correctly, it should present some evidence...

Here's the server in question:

    $ telnet 172.16.0.9 imap
    Trying 172.16.0.9...
    Connected to 172.16.0.9.
    Escape character is '^]'.
    * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS] hobbes.slamb.org Cyrus IMAP4 v2.3.7-Invoca-RPM-2.3.7-4.centos4.slamb server ready

Comment 2

[Scott Lamb]

Note that I'm not using SSL or TLS for this connection.

Comment 3

[Scott Lamb]

I saw a thing on enabling logging. Mozilla *IS* receiving the line I said from the server. When I have a thread expanded and hit the left arrow on some message, it seems to open a new session and say this:

47645696[172379a0]: 2d6fe00:mail.slamb.org:NA:ProcessCurrentURL:imap://[e-mail]:993/fetch%3EUID%3E.INBOX%3E69975:  = currentUrl
47645696[172379a0]: ReadNextLine [stream=172d27c8 nb=148 needmore=0]
47645696[172379a0]: 2d6fe00:mail.slamb.org:NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=PLAIN SASL-IR] hobbes.slamb.org Cyrus IMAP4 v2.3.7-Invoca-RP
M-2.3.7-4.centos4.slamb server ready
<<<<<DIALOG BOX POPS UP NOW>>>>>
47645696[172379a0]: 2d6fe00:mail.slamb.org:NA:SendData: 1 capability
47331840[17447af0]: 2cdfe00:mail.slamb.org:NA:ProcessCurrentURL: aborting queued urls
47331840[17447af0]: ImapThreadMainLoop leaving [this=2cdfe00]
47645696[172379a0]: ReadNextLine [stream=172d27c8 nb=310 needmore=0]
47645696[172379a0]: 2d6fe00:mail.slamb.org:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=PLAIN SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH

and then it must incorrectly take this path in nsImapProtocol::ProcessCurrentURL():

1345       if ( !(GetServerStateParser().GetCapabilityFlag() & (kIMAP4Capability | kIMAP4rev1Capability |
1346              kIMAP4other) ) )
1347       {
1348         AlertUserEventUsingId(IMAP_SERVER_NOT_IMAP4);
1349 
1350         SetConnectionStatus(-1);        // stop netlib
1351       }

Comment 4

[Wayne Mery (:wsmwk)]

Scott, good report, but is it same problem as reporter's?  See also bug 363039, bug 408861

Comment 5

[Nikolay Shopik]

even 2.x build show you correct erros, same with 3.x trunks.
"You cannot log in to mail.example.com because the server has disabled login. you may need to connect via SSL or TLS. Please check the account settings for your mail server."
To make this works IMAP server should advertise LOGINDISALED in CAPABILITY command. If server doesn't respond on 143 port TB usually just tell you Connection Refused (if we receive RST packet) or Connection Timeout (if we don't receive anything after 30 sec I suppose).
I suggest mark this as INCOMPLETE

Comment 6

[Nikolay Shopik]

marking as INCOMPLETE until hear from original submitter for db consistency sake

Comment 7

[Wayne Mery (:wsmwk)]

Nikolay, if the message you cite in comment 5 is correct, then isn't the correct resolution for the reporter's issue is WORKSFORME. Or are you suggesting the user might still not get the message being requested?

Comment 8

[Nikolay Shopik]

Wayne, I do agree WORKSFORME suit better in such case.

Comment 9

[Wayne Mery (:wsmwk)]

WFM per Nikolay comment 5.
Matthias, if you disagree, please comment in bug.