Bug 3484 - Add ability to specify IMAP folders in an account which are checked on startup
: Add ability to specify IMAP folders in an account which are checked on startup
Status: RESOLVED WONTFIX
Product: Email
General
: 5.0-beta2
: All other
: Low enhancement with 17 votes (vote)
: ---
Assigned To: unassigned
: modest-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2008-07-22 15:06 UTC by Al Sutton
Modified: 2012-03-24 11:43 UTC (History)
8 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Al Sutton (reporter) 2008-07-22 15:06:13 UTC
Please add the ability to refresh specified IMAP folders in the Email client.

I have an IMAP account with 450+MB of emails, over 250 folders, and all I need
to check is the inbox. I move everything into the folders manually, so there is
no need to check all 250 odd for new emails as I know it will never happen.

This feature would provide a significant speed up in terms of startup time for
myself and I would guess several other people who use their mailboxes in a
similar way.
Comment 1 Lucas Maneos 2009-02-26 21:51:17 UTC
Apparently this was silently fixed at some point - in 5.2008.43-7 modest only
shows/checks subscribed folders and is useable with my personal IMAP account
for the first time :-)  Folder subscriptions have to be set with another MUA
though.

Al, is this OK for you?
Comment 2 Al Sutton (reporter) 2009-02-26 22:34:50 UTC
I'd been wondering why my mail download was blisteringly quick recently.

It looks good to me :)
Comment 3 Lucas Maneos 2009-02-27 02:55:07 UTC
Hm, my previous comment was a bit premature.  It lists only subscribed folders
on a dovecot server but everything on cyrus.

I'll try to get some traces over the weekend and report back.
Comment 4 Lucas Maneos 2009-03-01 15:00:22 UTC
(pinging Philip)

Note: in the months since the last time I had tried this the dovecot server has
been upgraded from 0.99.x to 1.1.10 and that may have also had something to do
with the change in behaviour. I don't have a 0.99 box to test against anymore.

dovecot (1.1.10):

C: A00002 CAPABILITY\r\n
S: * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT
LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED
I18NLEVEL=1\r\nA00002 OK Capability completed.\r\n
C: A00003 NAMESPACE\r\n
S: * NAMESPACE (("" ".")) NIL NIL\r\nA00003 OK Namespace completed.\r\n
C: A00004 LIST (SUBSCRIBED) "" *\r\n

cyrus (2.3.9):

C: A00002 CAPABILITY\r\n
S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED 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\r\nA00002 OK Completed\r\n
C: A00003 NAMESPACE\r\n
S: * NAMESPACE (("INBOX." ".")) (("user." ".")) (("" "."))\r\nA00003 OK
Completed\r\n
C: A00004 LIST "INBOX" *\r\n
S: * LIST (\\HasChildren) "." "INBOX"\r\n[...]nA00004 OK Completed (0.010 secs
99 calls)\r\n
C: A00005 LSUB "INBOX" *\r\n
S: * LSUB (\\HasChildren) "." "INBOX"\r\n[...]nA00005 OK Completed (0.000 secs
34 calls)\r\n

There are two possibly significant variables here:

- The personal namespace prefix ("" vs "INBOX.")

- LIST extensions (LIST-EXTENDED vs LISTEXT)

It doesn't look like a prefix issue, but just to make sure, with dovecot
configured with personal namespace as "INBOX.":

C: A00002 CAPABILITY\r\n
S: * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT
LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED
I18NLEVEL=1\r\nA00002 OK Capability completed.\r\n
C: A00003 NAMESPACE\r\n
S: * NAMESPACE (("INBOX." ".")) NIL NIL\r\nA00003 OK Namespace completed.\r\n
C: A00004 LIST (SUBSCRIBED) "INBOX" *\r\n
S: A00004 OK List completed.\r\n
C: A00005 LIST (SUBSCRIBED) "INBOX." *\r\n

Although cyrus can handle "LIST (SUBSCRIBED)", it won't advertise 
LIST-EXTENDED capability until 2.4 (reference:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2875).

libtinymail-camel doesn't check for LISTEXT (fair enough, that was 
removed at the draft-ietf-imapext-list-extensions-13.txt stage and
didn't make it to RFC 5258) or LIST-SUBSCRIBED (also gone as of
draft-ietf-imapext-list-extensions-06.txt) and falls back to doing both
a LIST and an LSUB request (not sure why) and using the results of the
LIST.

In order to fully close this tinymail should also only list subscribed folders
on servers that don't support LIST-EXTENDED.  This is already what happens on
non-personal namespaces (cf bug 2537).

FWIW I'm personally ok with the current state as none of my cyrus-hosted
accounts have too many personal folders, but it would be nice to know if the
LIST (SUBSCRIBED) behaviour is intentional or is likely to go away in the
future.
Comment 5 Andre Klapper maemo.org 2009-06-22 23:43:29 UTC
Philip, can you comment on the timymail plans?
Comment 6 Andre Klapper maemo.org 2009-09-28 17:00:21 UTC
Sergio, are there plans to support this?
Comment 7 Sergio Villar Senin 2009-09-28 17:50:07 UTC
:m, there are no plans for the moment in modest to add an interface to do that.
Apart from that we have to make some changes in tinymail to gracefully deal
with accounts that does not support that like POP accounts
Comment 8 Andre Klapper maemo.org 2009-10-19 18:15:50 UTC
Also see bug 5553.
Comment 9 Andre Klapper maemo.org 2012-03-24 11:43:05 UTC
The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
enhancement/wishlist request. 
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)

Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).

There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates. 
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )