Closed Bug 213570 Opened 21 years ago Closed 20 years ago

Failure to store mail on IMAP:INBOX.Sent folder at Cyrus IMAP server; works on Mozilla 1.3

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pekka.nikander, Assigned: Bienvenu)

Details

Attachments

(1 file)

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.
Attached patch proposed fixSplinter Review
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 ben@peikes.com)
fix checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: