382912 - Send does not complete. "Copying message to Sent folder" when folder create fails - case sensitivity?

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[Scott Lamb]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/419 (KHTML, like Gecko) Safari/419.3
Build Identifier: version 2.0.0.0 (20070326)

I am connecting via IMAP to an MS Exchange server with a folder called "INBOX.sent". Out of the box, the "Sending Messages" dialog hangs on "Copying message to Sent folder". I've used Ethereal to inspect the packets on the wire. This fragment is interesting:

    2137 list "" "Sent"
    * 24636 EXISTS
    * 218 RECENT
    * LIST (\Marked \HasNoChildren) "/" sent
    2137 OK LIST completed.
    2138 create "Sent"
    2138 NO An object by the same name was found.
    2139 IDLE
    + IDLE accepted, awaiting DONE command.

I'm not sure which party is right on the case sensitivity, but Thunderbird should definitely report error rather than waiting for successful completion (which will never happen).

Reproducible: Always

Steps to Reproduce:
1. create a folder "INBOX.sent" on an MS Exchange server
2. connect to it via IMAP
3. attempt to send an email
Actual Results:  
The send hangs indefinitely; message is not copied to the sent folder. Cancel does work at least.

Expected Results:  
It completes successfully or at least reports an error like "unable to create 'INBOX.Sent': An object by the same name was found".

bug 378735 and bug 380238 may be related, but definitely not exactly the same problem. In both cases, they reported that the message was successfully added to the sent folder. In my case, it was definitely not.

Comment 1

[Scott Lamb]

Correction. In steps to reproduce, #1, my folder is apparently named "sent" rather than "INBOX.sent".

Comment 2

[WADA:World Anti-bad-Duping Agency]

Folder name in IMAP is case sensitive, except "INBOX". So it's apparently fault of your MS Exchange server, although Tb is better to report to you about different folder name problem by stupid IMAP server in response to '2137 list "" "Sent"' command issued by Tb.

To Scott Lamb(bug opener):
Do you still have problem?
Does the "sent" folder(in lower case) is listed as "sent" in subscribe menu or folder pane of Tb?
If yes, you can bypass your problem by;
  At Account Settings/Copies&Folders, at setting for "Sent", "Others:",
  select the "sent" folder.

Comment 3

[Scott Lamb]

I managed to work around the problem, and in fact now no longer even have access to an MS Exchange server, so I'd be unable to verify a fix.

Comment 4

[WADA:World Anti-bad-Duping Agency]

Adding "MS Exchange" and "IMAP" in bug summary, for ease of search.

Comment 5

[Scott Lamb]

Where does IMAP actually say that mailbox names are case-sensitive? All I see in RFC 2060 is this:

5.1.    Mailbox Naming

   The interpretation of mailbox names is implementation-dependent.
   However, the case-insensitive mailbox name INBOX is a special name
   reserved to mean "the primary mailbox for this user on this server".

It does say that INBOX is case-insensitive, but it seems to be explicitly NOT saying anything about any other mailbox name.

Comment 6

[WADA:World Anti-bad-Duping Agency]

You are right. Sorry for my mis-understanding of RFC.

Current IMAP is IMAP4rev1, and is defined by RFC 3501.
> http://www.faqs.org/rfcs/rfc3501.html
And RFC 3501 also says:
> 5.1.    Mailbox Naming
>(snip)
>  The case-insensitive mailbox name INBOX is a special name reserved to
>  mean "the primary mailbox for this user on this server".  The
>  interpretation of all other names is implementation-dependent.

Problem can be said as;
  Thunderbird can't afford IMAP server of case-insensitive folder name.
  Thunderbird should tolerant with "sent" in response to 'list "Sent"'.
This issue is possibly reported already. Have you searched bugzilla.mozilla.org for it?

Comment 7

[Scott Lamb]

I searched for similar problems before reporting this bug back in May 2007, yes.

Comment 8

[Wayne Mery (:wsmwk)]

wada, is this still legit, or better defined in another bug?  do we need more info?

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #8)

I don't know whether next description permits  '* LIST (snip) sent' response to '2137 list "" "Sent"' or not.
> The interpretation of all other names is implementation-dependent.
It's slightly different from "create Sent"+"NO already exists" and "* LIST ... sent" to "list *" case.

I don't know who(IMAP server, or IMAP client, or user of IMAP client) should address issues due to "implementation-dependent interpretation of name".
In this case, even if server uses case insensitive file system(file name for Sent,sent,sEnt,seNt,senT,...=="sent"), if server returns  '* LIST (snip) Sent' to 'list "" "Sent"', no problem will occur.
And, if user select "sent" at UI to set "folder to save sent mail", no problem will occur.

I believe "request to addesss by an IMAP client" itself is never not-legit absolutely. It's up to triage team and developers of Tb.

Comment 10

[Scott Lamb]

Regardless of the interoperability/protocol interpretation issue, Thunderbird's error handling is clearly broken (to be precise, missing entirely). This sequence:

    2138 create "Sent"
    2138 NO An object by the same name was found.

should produce an error message rather than a beachball spinning forever. There are many reasons that the server might produce a NO response and Thunderbird should accept that.

Comment 11

[WADA:World Anti-bad-Duping Agency]

Problem when "create Sent/NO same name was found" is already reported bug(It's the reason why I wrote about the case in previous comment). Search bugzill.mozilla.org, please. I don't remember whether phenomenon reported was "a beachball spinning forever" or not.
Tb latest-trunk has "a beachball spinning forever" problem too?
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
> Test with new profile to avoid corruption of daily use profile.
> If test POP3, don't forget to check "Leave Messages on Server".

Comment 12

[Scott Lamb]

I don't see where you "wrote about the case in previous comment", but I don't understand several of your sentences in comment #9. If there is another bug for the same problem, I didn't see it when I searched prior to filing this bug, and I still do not see it now. I've gone to some effort here to make a good bug report, so humor me: if you have seen another relevant bug, please just post the bug number rather than wasting everyone's time.

I haven't tested latest trunk and don't intend to. I've seen a low success rate in getting Mozilla bugs fixed despite a lot of effort on the part of the bug reporters, so it doesn't seem worthwhile to periodically recheck all the bugs I've filed for years afterward without any reason to believe they've been fixed. As I mentioned in comment #3, I no longer have access to the server to reproduce this two-year-old bug, so I would have to construct a new test environment. If I were to put in that much effort, I'd rather do so fixing the code myself and writing a unit test. I have my doubts that even that would be successful. In fact, I think the most logical course of action for me is to stop participating in this conversation; it's hopeless. Goodbye.

Comment 13

[Wayne Mery (:wsmwk)]

bienvenu, others, can you comment as to whether this likely still exists on trunk and there's an imap fix opportunity here (ref: comment 10 and comment 11)?  And whether other "beach ball bugs" are applicable (though not necessarily directly related to this)? I know they exist, but like wada I don't know them off the top of my head. And I know they are also hard to search for.

Scott, I would characterize a volunteer helping in a bug as hopeful rather than hopeless. It seems to me this is moving forward.  And your bug track record is far from bad or unexpected in an open source endeavor - 3 non-enh bugs: one fixed within 6 months, one WFM within 1 month, and this one, well, languished.  That would be frustrating, but it's better than average for mozilla.  Yes, this is an excellent bug report. And talent such as yours is quite welcome. 

Steve and Jay have an interest in exchange, so ccing them

Comment 14

[David :Bienvenu]

I don't know if this exists on the trunk - it depends on how we search for folder URI's. I don't believe we propagate the create folder error back because there are cases where we try to create folders like Trash on startup but don't want to annoy the user every time if it fails. But errors creating the Sent folder should be propagated back, I agree.

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to comment #14)
> I don't know if this exists on the trunk - it depends on how we search for
> folder URI's. *I don't believe we propagate the create folder error back* because
> there are cases where we try to create folders like Trash on startup but don't
> want to annoy the user every time if it fails. But errors creating the Sent
> folder should be propagated back, I agree.

confirming based on that.  feel free to do a dup if there's a bug that better covers this issue.

Comment 16

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.