[Dovecot] where is subscribed list stored?
I'm using
$ /usr/sbin/dovecot --version 2.0.15
on
$ cat /etc/fedora-release Fedora release 14 (Laughlin)
and version 8 of Thunderbird.
I use dovecot locally for internal only access to my email archives, of which I have many gigs of email archives. Over time I end up subscribing to a couple dozen different IMAP email folders. Problem is that periodically my list of subscribed folders get zapped to none, and I have to go and re-subscribe to a dozen or two folders again.
Anyone seen this happen? It looks like the list of subscribed folders is here ~/Mail/.subscriptions and I can see in my daily backup that it reflects what appears in TBird. What might be zapping it? I use multiple email clients simultaneously on different hosts. (IOW I leave them open) Is this a problem? Does dovecot manage that in some way? Or is that my problem? I don't think this is the problem since this only occurs like a few times per year. If it were the problem I'd expect it to occur much more frequently.
Thanks for any clues Mike
On Sun, 22 Jan 2012 07:55:02 -0600, Michael Makuch wrote:
$ cat /etc/fedora-release Fedora release 14 (Laughlin)
and version 8 of Thunderbird.
can you use thunderbird 9 ?
does the account work with eg rouncube webmail ?
my own question is, is it a dovecot problem ?
do you modify files outside of imap protocol ?
if so you asked for it :-)
am 22.01.12 15:10 schrieb Benny Pedersen <me@junc.org>:
can you use thunderbird 9 ?
does the account work with eg rouncube webmail ?
I`ve TB9 AND Roundcube. No problems with Dovecot 2.017 here
my own question is, is it a dovecot problem ?
do you modify files outside of imap protocol ?
if so you asked for it :-)
-- Mit freundlichen Grüßen, with kind regards, Jim Knuth
Wahrhaftigkeit und Politik wohnen selten unter einem Dach. (Marie Antoinette)
On 1/22/2012 7:55 AM, Michael Makuch wrote:
Anyone seen this happen? It looks like the list of subscribed folders is here ~/Mail/.subscriptions and I can see in my daily backup that it reflects what appears in TBird. What might be zapping it? I use multiple email clients simultaneously on different hosts. (IOW I leave them open) Is this a problem? Does dovecot manage that in some way? Or is that my problem? I don't think this is the problem since this only occurs like a few times per year. If it were the problem I'd expect it to occur much more frequently.
What do your Dovecot logs and TB Activity Manager tell you, if anything? How about logging on the other MUAs?
You are a human being, and are thus limited to physical interaction with a single host at any point in time. How are you "using" multiple MUAs on multiple hosts simultaneously? Can you describe this workflow? I'm guessing you're performing some kind of automated tasks with each MUA, and that is likely the root of the problem. Please describe these automated tasks.
-- Stan
On 22.1.2012, at 15.55, Michael Makuch wrote:
I use dovecot locally for internal only access to my email archives, of which I have many gigs of email archives. Over time I end up subscribing to a couple dozen different IMAP email folders. Problem is that periodically my list of subscribed folders get zapped to none, and I have to go and re-subscribe to a dozen or two folders again.
Anyone seen this happen? It looks like the list of subscribed folders is here ~/Mail/.subscriptions and I can see in my daily backup that it reflects what appears in TBird. What might be zapping it? I use multiple email clients simultaneously on different hosts. (IOW I leave them open) Is this a problem? Does dovecot manage that in some way? Or is that my problem? I don't think this is the problem since this only occurs like a few times per year. If it were the problem I'd expect it to occur much more frequently.
No idea, but you could prevent it by making sure that it can't change the subscriptions:
mail_location = mbox:~/Mail:CONTROL=~/mail-subscriptions
mkdir ~/mail-subscriptions mv ~/Mail/.subscriptions ~/mail-subscriptions chmod 0500 ~/mail-subscriptions
I thought Dovecot would also log an error if client tried to change subscriptions, but looks like it doesn't. It only returns failure to client:
a unsubscribe INBOX a NO [NOPERM] No permission to modify subscriptions
participants (5)
-
Benny Pedersen
-
Jim Knuth
-
Michael Makuch
-
Stan Hoeppner
-
Timo Sirainen