Closed Bug 332509 Opened 18 years ago Closed 5 years ago

improperly requires case-preservation with IMAP. Needs pref to ignore case sentivity or automatically detected it and adjust.

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: acoliver, Unassigned)

Details

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

  Thunderbird will try and create "Sent

IMAP Spec (section 5.1)
"some server implementations
   are fully case-sensitive; others preserve case of a newly-created
   name but otherwise are case-insensitive; and yet others coerce names
   to a particular case.  Client implementations MUST interact with any
   of these. "

Reproducible: Always

Steps to Reproduce:
1.Send a mail to a case insensitive, non-case preserving (foldernames) mail server.
2.Thunderbird will try and create "Sent" folder with the CREATE command
3.Thunderbird will then LIST "" "Sent"
4. If server sends back -- * LIST "/" Sent --- then things work as expected (append).  However if the server sends back --- * LIST "/" SENT --- then Tbird begins loops back to the create stage.

Actual Results:  
TBird should either have a setting for whether folders are case sensitive and/or case preserving or should detect this.

Expected Results:  
TBird expects case preservation.

continue on with the append command and take the "SENT" foldername.
Version: unspecified → 1.5
ethereal dump:

No.     Time        Source                Destination           Protocol Info
 266170 63179.742805 127.0.0.1             127.0.0.1             IMAP     Request: 14 list "" "Sent"

Frame 266170 (75 bytes on wire, 75 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 60696 (60696), Dst Port: 9143 (9143), Seq: 601, Ack: 3310, Len: 19
Internet Message Access Protocol

No.     Time        Source                Destination           Protocol Info
 266267 63184.629020 127.0.0.1             127.0.0.1             IMAP     Response: * LIST () "/" SENT

Frame 266267 (98 bytes on wire, 98 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 9143 (9143), Dst Port: 60696 (60696), Seq: 3310, Ack: 620, Len: 42
Internet Message Access Protocol

No.     Time        Source                Destination           Protocol Info
 266268 63184.630494 127.0.0.1             127.0.0.1             IMAP     Request: 15 create "Sent"

Frame 266268 (74 bytes on wire, 74 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 60696 (60696), Dst Port: 9143 (9143), Seq: 620, Ack: 3352, Len: 18
Internet Message Access Protocol

No.     Time        Source                Destination           Protocol Info
 266871 63200.627868 127.0.0.1             127.0.0.1             IMAP     Response: * OK localhost IMAP4 Server (JBMAIL IMAP4rev1 Server version 0.1) 

Frame 266871 (124 bytes on wire, 124 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 9143 (9143), Dst Port: 60700 (60700), Seq: 1, Ack: 1, Len: 68
Internet Message Access Protocol

No.     Time        Source                Destination           Protocol Info
 266872 63200.628862 127.0.0.1             127.0.0.1             IMAP     Request: 1 login "andy" "testpwd"

Frame 266872 (82 bytes on wire, 82 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 60700 (60700), Dst Port: 9143 (9143), Seq: 1, Ack: 69, Len: 26
Internet Message Access Protocol

No.     Time        Source                Destination           Protocol Info
 266904 63200.677900 127.0.0.1             127.0.0.1             IMAP     Response: 1 OK LOGIN completed

Frame 266904 (78 bytes on wire, 78 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 9143 (9143), Dst Port: 60700 (60700), Seq: 69, Ack: 27, Len: 22
Internet Message Access Protocol

No.     Time        Source                Destination           Protocol Info
 266905 63200.679039 127.0.0.1             127.0.0.1             IMAP     Request: 2 list "" "Sent"

Frame 266905 (74 bytes on wire, 74 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 60700 (60700), Dst Port: 9143 (9143), Seq: 27, Ack: 91, Len: 18
Internet Message Access Protocol

No.     Time        Source                Destination           Protocol Info
 267663 63260.247722 127.0.0.1             127.0.0.1             IMAP     Response: * LIST () "/" SENT

Frame 267663 (97 bytes on wire, 97 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 9143 (9143), Dst Port: 60700 (60700), Seq: 91, Ack: 45, Len: 41
Internet Message Access Protocol

No.     Time        Source                Destination           Protocol Info
 267664 63260.261890 127.0.0.1             127.0.0.1             IMAP     Request: 3 create "Sent"

Frame 267664 (73 bytes on wire, 73 bytes captured)
Null/Loopback
Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 60700 (60700), Dst Port: 9143 (9143), Seq: 45, Ack: 132, Len: 17
Internet Message Access Protocol

In the successful version the list is followed by subscribe and append.
Duplicate of/related to bug 231095?
Ahh, I did search for it, I just didn't find it -- however it is mapped expired.  However, by my read of the spec this is non-compliant behavior on behalf of TBird.  The other bug suggests that you could go map the folders, but actually you can't because TBird (1.5) RETRIES creating the folder IMMEDIATELY after the list command....repeatedly.  Now since I'm writing IMAP code with TBird compatibility in mind, no problem, I'll just be case preserving...but it is errant behavior that is likely to pop up with other IMAP servers and hence should be corrected.  The spec is actually rather specific here (that the client has the responsibility to work with complete case insensitivity, lack of case preservation or with complete case sensitivity).

I can give you a normal/working (case preserving) behavior ethereal dump if it helps.

QA Contact: message-compose
version 3.0a2pre (2008062603) confr
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: Macintosh → All
Version: 1.5 → Trunk
Assignee: nobody → bienvenu
Component: Message Compose Window → Networking: IMAP
Product: Thunderbird → Core
QA Contact: message-compose → networking.imap
Product: Core → MailNews Core
Assignee: mozilla → nobody

Gene, do you believe tihs is still true?

Flags: needinfo?(gds)

I think this shows that the folder names in the list response are compared with case n/a since it uses PL_strncasecmp():

https://searchfox.org/comm-central/rev/cb9576cec8db2271362a937bc6d1703afa044433/mailnews/imap/src/nsImapServerResponseParser.cpp#850

From man page: "The strcasecmp() function compares the two strings s1 and s2, ignoring the case of the characters."

I haven't tried to duplicate the problem since I'm not sure which type of server has the behavior the reporter describes. Also, I would think that the problems would be reported quite often if there is really an issue with this.

Flags: needinfo?(gds)

Perhaps then we close this incomplete?

Summary: Thunderbird improperly requires case-preservation with IMAP. → improperly requires case-preservation with IMAP. Needs pref to ignore case sentivity or automatically detected it and adjust.

(In reply to Wayne Mery (:wsmwk) from comment #7)

Perhaps then we close this incomplete?

Either incomplete or invalid (due to code changes over the years) seem right to me.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.