User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030721 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030721 Mozilla 1.4a, 1.4b, 1.4 and 1.5a and Thunderbird 0.6 fail to store outgoing e-mail to the Sent folder under a particular configuration, explained below. However, Mozilla 1.3 works perfectly fine under exactly the same configuration. Configuration: - Cyrus IMAP server or other IMAP server that stores user folders as subfolders of INBOX - at Mail & News Account Settings -> Server Settings -> Advanced, set IMAP server directory as "INBOX" - at Mail & News Account Settings -> Copies & Folders, use either "Sent" folder on: or Other: -setting specifying the the Sent subfolder of INBOX. Reproducible: Always Steps to Reproduce: 1. Use Cyrus IMAP server as your mail server (or probably any other IMAP server that supports subfolders) 2. Configure the Mail Account to use the "INBOX" server directory (mail.server.serverX.server_sub_directory = "INBOX") 3. Configure the Mail Account to store copies of outgoing messages to "INBOX.Sent" (mail.identity.idX.fcc_folder = "imap://account@host/INBOX/Sent") 4. Try to send e-mail. Actual Results: Mozilla sends the e-mail out correctly. However, instead of storing the message at INBOX.Sent, Mozilla comes with the following error message: The current command did not succeed. The mail server responded: Mailbox does not exist. Expected Results: Instead of complaining, Mozilla should store the message at INBOX.Sent.
Playing around more I found an interesting work around for this: At Mail & News Account Settings -> Server Settings -> Advanced..., - deselect Allow server to override these namespaces (mail.server.serverX.override_namespaces = false) - make sure that Personal namespace: is empty, i.e. that it DOES NOT contain "INBOX.". (mail.server.serverX.namespace.personal is not set) Only if Personal namespace: contains "INBOX.", which is does if one allows the Cyrus IMAP server to set up these fields, the bug appears.
Severity: normal → minor
Still more exploration revealed that while disallowing the server to set the personal namespace and clearing out the personal namespace name allows outgoing mail to be filed fine to INBOX.Sent, such a configuration has a side effect: All other folder operations start to fail. I am returning back to Mozilla 1.3 now.
Severity: minor → normal
I faced a similar problem recently. Am using an email service known as Fastmail, which uses the Cyrus IMAP server. My problem, and the solution can be found at this EmailDiscussions forum thread -- http://www.emailaddresses.com/forum/showthread.php?s=&threadid=14572. Please comment if this is the same problem you face; in which case we can change the bug status to NEW.
could you try a recent 1.5 trunk build? I made some changes on 7/27 that might help. Also, are you really setting the IMAP server directory as "INBOX", and not "INBOX."? I have to say this all works for me, on both FastMail and Cyrus servers, with IMAP server directory left blank, or set to "INBOX.", without overriding the server's personal namespace.
Status: UNCONFIRMED → NEW
Ever confirmed: true
David, currently I am using Thunderbird 0.1 (released 28/JUL). Would that be including your 27/JUL changes? In any case, I don't know how to reproduce the problem, coz I don't know what the cause of the problem is. :-) Things weren't working --> I removed INBOX. (directory field) --> shutdown Thunderbird --> restarted Thunderbird --> added INBOX. (directory field) --> things began working. My personal guess is this: before testing/ finding out that the subfolders aren't accessible, I had moved and renamed some of my folders around. So possibly Thunderbird had an older "view" of things, and doing the steps above sort of caused it to look again and see how the folders actually are. But that is strange coz I was able to move/ copy/ see mails etc in all my folders through the usual panes; its just that while trying to save an FCC into some sub-folders, things failed. How can it be that folders are accessible from one view, but not from another? :-/
David, I haven't had the time to test the latest builds yet; I will try to have time tomorrow (its late here). Yes, I am using "INBOX" not "INBOX." Everything works for me if I leave the server directory blank. However, that is not an option for me. I have some 200+ subfolders, and if I leave the server directory blank, they are stored as subdirectories under the INBOX.sbd. Unfortunately due to other bugs in Mozilla (related to offline working), I every now and then have to remove the cached INBOX. If the other folders are stored in INBOX.sbd, they all are then invalidated too, causing my laptop to download 200+Mb of mail on the next download/sync. Not nice, especially if I happen to be travelling. Hence, the only option is to set the used subdirectory so that all my folders get stored directly under ImapMail/hostname, not under ImapMail/hostname/INBOX.sdb. Rakish, Mozilla seems to react to some of the discussed settings only when it is restarted. Therefore it is important to quit mozilla and launch it again to really see if things works. What is even stranger is that at least once everything seemed to work for a while, and then stopped working after a restart. I don't remember any more which combination/change that was.
David (Comment 4) does oine have to set the server directory field to "INBOX." or "INBOX"? I thought the former was the correct one (atleast that's the one that works for me). Pekka, you seem to have misunderstood me. Things work for me now (after I did the steps mentioned in Comment 5 as per a discussion in my email provider's forum (linked in Comment 3)). Things weren't working --> I removed INBOX. (directory field) --> shutdown Thunderbird --> restarted Thunderbird --> added INBOX. (directory field) --> things began working.
I now tested this with 20030801 Mach-O build. Based on my minimal testing so far, everything seems to work if I set the directory as INBOX. (with the trailing period). If I set the directory as INBOX (without the trailing period), FCC does not work but otherwise everything seems to work. Hence, it looks like this bug renders into a minor inconsistency in using the directory wrt FCC vs. all other folder operations. Or at least so in the newer builds. Hence, I am changing severity to minor; there is a workaround.
Severity: normal → minor
Which of these is the correct one for the directory field -- "INBOX" or "INBOX."? I had always used (and thought correct) the latter.
I have no idea whether "INBOX" or "INBOX." is the right one. I had used "INBOX" until this discussion on this bug. From a human factors point of view, "INBOX" would make more sense to me. Anyway, the field name is "directory", not "path" or "prefix". If the name of the field was "directory path" or "name prefix" or something like that, a name with a trailing separator would make more sense. However, when it is just "directory", to me a name without a trailing separator makes more sense. That is just more consistent with how I use directory or folder names in most other contexts.
Yes, "INBOX." is what works. I don't know if "INBOX" used to work, but even the personal namespace as returned by the server in this case is "INBOX.", not "INBOX"
I would suggest that you change the field GUI label from "IMAP server directory: " to "IMAP server namespace: " and mark the bug fixed. Changing the field label would clear the confusion, IMHO.
Created attachment 143310 [details] [diff] [review] proposed fix If you don't set the online server directory, it looks to me like we weren't creating the sent folder (or drafts or templates).
Comment on attachment 143310 [details] [diff] [review] proposed fix we went to all the trouble of figuring out the folder resource with the personal namespace, but then we weren't using it!
Attachment #143310 - Flags: superreview?(mscott)
Attachment #143310 - Flags: superreview?(mscott) → superreview+
I keep getting updates on this bug. How do I turn off auto notification? (notifications being sent to email@example.com)
fix checked in.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.