[Dovecot] inetd corrupt environment
Hello. I'm having the following problem with dovecot 1.0.12 and above, on a FreeBSD 7.0 system - I'm trying to run pop3-login from inetd and I keep getting this error after authentication: May 25 09:46:19 charlie dovecot: POP3(gelu): /libexec/ld-elf.so.1: environment corrupt; missing value for no-nuls oe-ns-eoh The problem persists if I uncomment the lines with no-nuls oe-ns-eoh in dovecot.conf. I've also tried running pop3-login from tcpserver/ucspi-tcp and I still get the same error. Version 1.0.1 works fine on a similar setup. Please reply if you have any idea regarding a fix for this error. I need to run dovecot under a tcp wrapper of some kind (preferably inetd) as the standalone daemon doesn't allow any method to restrict access by IP. The allow_nets extra field doesn't help much as I'm using PAM and do not want to maintain yet another passdb. Restricting access via firewall rules is not an option. Until I find a way to restrict access by IP address, dovecot will only listen on the private IP address (192.168.100.1). My dovecot configuration follows: # 1.0.13: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: pop3 listen: 192.168.100.1 ssl_cipher_list: ALL:!LOW disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/pop3-login login_greeting: login_process_size: 32 login_max_processes_count: 32 login_max_connections: 128 max_mail_processes: 128 verbose_proctitle: yes first_valid_uid: 1000 mail_privileged_group: mail mail_location: mbox:~/Mail/:INBOX=/var/mail/%u mail_executable: /usr/local/libexec/dovecot/pop3 mail_plugin_dir: /usr/local/lib/dovecot/pop3 pop3_uidl_format: %08Xu%08Xv pop3_client_workarounds: outlook-no-nuls oe-ns-eoh auth default: mechanisms: plain login process_size: 64 passdb: driver: pam userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix -- Finally - A spam blocker that actually works. http://www.bluebottle.com/tag/4
Re: [Dovecot] Error while set mailQuota=0 with mbox and LDAP backend
Timo Sirainen wrote: On May 25, 2008, at 5:40 AM, Zhang Huangbin wrote: Timo Sirainen wrote: 0 means the user has 0 bytes quota, not unlimited. Maybe this should be changed.. You could always work around it by just returning a very large value. Hope to see this change. :) It actually already works like that in v1.1. I won't change it in v1.0 anymore though. I have added a line about this in the wiki, since it took me some time to figure out by trial and error, and then you got me concerned anyway with the first statement above. http://wiki.dovecot.org/Quota/New Cheers, Anders.
Re: [Dovecot] inetd corrupt environment
On Sun, 2008-05-25 at 10:21 +0300, Gelu G. Lupas wrote: Hello. I'm having the following problem with dovecot 1.0.12 and above, on a FreeBSD 7.0 system - I'm trying to run pop3-login from inetd and I keep getting this error after authentication: May 25 09:46:19 charlie dovecot: POP3(gelu): /libexec/ld-elf.so.1: environment corrupt; missing value for no-nuls oe-ns-eoh The problem persists if I uncomment the lines with no-nuls oe-ns-eoh in dovecot.conf. uncomment? What if you comment them? Does it at least change the error message? I've looked at this error before, but I don't see any obvious reason why it would happen. Does it work if you run it directly instead of via inetd? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Wrong message information
On Sun, 2008-05-25 at 13:02 +0200, Anders wrote: Timo Sirainen wrote: On Fri, 2008-05-23 at 11:12 +0200, Anders wrote: Timo Sirainen wrote: Right, that helped me to reproduce it. Fixed: http://hg.dovecot.org/dovecot-1.1/rev/cb1c6c942768 Hi again. That fixed my testcase as well, but now I just got another report of a mail with an epoch date. It turns out that I can still get in trouble if running the send_fetch_test script concurrently, with eventual output like this: 2008-05-23 10:54:27.123649 Got valid RFC822.SIZE 1104: 1 (UID 1255 FLAGS () INTERNALDATE 01-Jan-1970 00:00:00 + RFC822.SIZE 1104) Right.. This should help: http://hg.dovecot.org/dovecot-1.1/rev/d920ec986c34 That does not seem to change anything. I have been cherry picking patches since 1.1.rc4, can you think of other recent changes that I need? I am waiting for rc6 for a complete upgrade. Nothing else should be needed. Note that the size is actually correct now, most of the time, so it is not exactly the same issue as initially. I could yesterday also reproduce the broken INTERNALDATE pretty easily, but I can't anymore after that patch.. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Wrong message information
Timo Sirainen wrote: On Fri, 2008-05-23 at 11:12 +0200, Anders wrote: Timo Sirainen wrote: Right, that helped me to reproduce it. Fixed: http://hg.dovecot.org/dovecot-1.1/rev/cb1c6c942768 Hi again. That fixed my testcase as well, but now I just got another report of a mail with an epoch date. It turns out that I can still get in trouble if running the send_fetch_test script concurrently, with eventual output like this: 2008-05-23 10:54:27.123649 Got valid RFC822.SIZE 1104: 1 (UID 1255 FLAGS () INTERNALDATE 01-Jan-1970 00:00:00 + RFC822.SIZE 1104) Right.. This should help: http://hg.dovecot.org/dovecot-1.1/rev/d920ec986c34 That does not seem to change anything. I have been cherry picking patches since 1.1.rc4, can you think of other recent changes that I need? I am waiting for rc6 for a complete upgrade. Note that the size is actually correct now, most of the time, so it is not exactly the same issue as initially. Also, I set up the test account wrongly, and then actually had this issue with Dovecot deliver as well. It triggers most easily by removing the Maildir completely, and then running send_fetch_test.py twice at the same time. Regards, Anders.
Re: [Dovecot] no bookeeping using public folders
On Mon, 2008-05-19 at 09:17 +0200, Claude Frantz wrote: The problem, while using Thunderbird: The read only user can delete messages or mark then read. But after a new session, all the messages are still new. Of course, only baratin is the owner. The problem, while using mutt and IMAP: mutt refuse to change any flag because the folder is read only. Of course, this is correct. My question: Why is no bookkeeping maintained for other users, although every one has his/her own control and index structure ? So you'd want all users to be able to have their own private flags? If you create dovecot-shared file, the seen flag will be private, but others will still be shared. This is currently hard coded, but it's pretty easy to change from sources if you really want to: src/lib-storage/index/maildir/maildir-storage.c around line 544: mbox-private_flags_mask = MAIL_SEEN; Change that to: mbox-private_flags_mask = MAIL_FLAGS_MASK; signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Domain variable in checkpassword
On Sun, 2008-05-18 at 18:48 +0300, sawyer x wrote: I'm using the checkpassword method but I don't get the domain a user inputs. I can't cross check per virtual domains if I'm not getting one, which means it renders all my efforts useless. Domain is part of the username. If you're not getting it, either the client isn't sending it or you have some kind of a configuration problem (show dovecot -n output). 'DOVECOT_VERSION' = '1.0.rc15', Would be a good idea to upgrade to a post-v1.0.0 release. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Error while set mailQuota=0 with mbox and LDAP backend
Hi, Timo. Timo Sirainen wrote: homeDirectory=home,mailMessageStore=dirsize:mail,mailQuota=quota=dirsize:storage Also what is mailMessageStore=dirsize:mail? I don't think it does anything. After some test, i think 'mailMessageStore=dirsize:mail' is an optional parameter for LDAP backend. mail_location in dovecot.conf: mail_location = mbox:/%Lh/%Ld/%Ln:INBOX=/%Lh/%Ld/%Ln/inbox:INDEX=/%Lh/%Ld/%Ln/indexes Below is sieve log file without 'mailMessageStore=dirsize:mail': deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: Loading modules from directory: /usr/lib64/dovecot/lda deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: Module loaded: /usr/lib64/dovecot/lda/lib10_quota_plugin.so deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: Module loaded: /usr/lib64/dovecot/lda/lib90_cmusieve_plugin.so deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: auth input: [EMAIL PROTECTED] deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: auth input: home=/home/vmail deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: auth input: quota=dirsize:storage=10240 deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: auth input: uid=2000 deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: auth input: gid=2000 deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: mbox: data=//home/vmail/a.cn/www:INBOX=//home/vmail/a.cn/www/inbox:INDEX=//home/vmail/a.cn/www/indexes deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: mbox: root=//home/vmail/a.cn/www, index=//home/vmail/a.cn/www/indexes, inbox=//home/vmail/a.cn/www/inbox deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: dirsize quota limit = 10240kB deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: cmusieve: Using sieve path: /home/vmail/.sieve.rule deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: cmusieve: Executing script /home/vmail/.sieve.rulec deliver([EMAIL PROTECTED]): May 25 12:10:09 Info: msgid=[EMAIL PROTECTED]: saved mail to INBOX And below is sieve log with 'mailMessageStore=dirsize:mail': deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: Loading modules from directory: /usr/lib64/dovecot/lda deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: Module loaded: /usr/lib64/dovecot/lda/lib10_quota_plugin.so deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: Module loaded: /usr/lib64/dovecot/lda/lib90_cmusieve_plugin.so deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: auth input: [EMAIL PROTECTED] deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: auth input: home=/home/vmail deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: auth input: dirsize:mail=a.cn/www deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: auth input: quota=dirsize:storage=10240 deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: auth input: uid=2000 deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: auth input: gid=2000 deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: mbox: data=//home/vmail/a.cn/www:INBOX=//home/vmail/a.cn/www/inbox:INDEX=//home/vmail/a.cn/www/indexes deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: mbox: root=//home/vmail/a.cn/www, index=//home/vmail/a.cn/www/indexes, inbox=//home/vmail/a.cn/www/inbox deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: dirsize quota limit = 10240kB deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: cmusieve: Using sieve path: /home/vmail/.sieve.rule deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: cmusieve: Executing script /home/vmail/.sieve.rulec deliver([EMAIL PROTECTED]): May 25 12:11:43 Info: msgid=[EMAIL PROTECTED]: saved mail to INBOX -- Best Regards. Zhang Huangbin - Mail Server Solution for Red Hat(R) Enterprise Linux CentOS 5.x: http://rhms.googlecode.com/
Re: [Dovecot] singe system user for all virtual users
hi, thank you. Timo Sirainen wrote: On Sun, 2008-05-25 at 02:27 +0100, Wojtek Bogusz wrote: Error: Error in configuration file /usr/local/etc/dovecot.conf line 909: Unknown setting: userdb .. auth_userdb = What's this? Remove it. see the bottom of http://wiki.dovecot.org/VirtualUsers the section static userdb that is where it comes from. -- W
Re: [Dovecot] Vanishing maildirsize files with 1.0.7 using 'deliver' via postfix
On Wed, 2008-05-21 at 12:21 -1000, Jason Forester wrote: We have 3 RH5.1 boxes running the stock Postfix 2.3.3, but due to issues with the stock Dovecot 1.0rc15, Redhat supplied us with the version of Dovecot 1.0.7 that will be in Redhat 5.2. There is one change to Maildir++ quota since v1.0.7: http://hg.dovecot.org/dovecot-1.0/rev/288fd70ac258 But that's mostly an optimization and doesn't cause files to be deleted. However almost immediately a maildirsize folder vanished. Soon after another, then another, and now we're missing nearly 40 of them. Maildir++ quota recalculation works like: Go through all files and sum up their sizes. Keep track of the highest directory mtime. Once everything is calculated, again go through all directories and find the highest mtime. If the highest mtime had increased, something had changed, so delete maildirsize file. So could it be simply that the recalculation is slow enough that the maildir changes during it and causes the file to be deleted? Another possibility is that some error happens, but then Dovecot should have logged something. Do you keep your quota limits stored only in the maildirsize file? If not, having the files deleted shouldn't affect functionality, but of course the performance is worse. The rebuild performance could be improved if maildir filenames contain ,S=xxx containing the file's size so stat() calls can be avoided. But you can't really change existing filenames without having them show up as new mails. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] singe system user for all virtual users
On Sun, 2008-05-25 at 13:21 +0100, Wojtek Bogusz wrote: hi, thank you. Timo Sirainen wrote: On Sun, 2008-05-25 at 02:27 +0100, Wojtek Bogusz wrote: Error: Error in configuration file /usr/local/etc/dovecot.conf line 909: Unknown setting: userdb .. auth_userdb = What's this? Remove it. see the bottom of http://wiki.dovecot.org/VirtualUsers the section static userdb that is where it comes from. Thanks, that was an accidental mistake in there. I removed it now. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Searching the Archives (was: Re: dovecot developer documentation)
On Wed, 2008-05-21 at 23:49 -0400, John Simpson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2008-05-15, at 0645, Karsten Bräckelmann wrote: Also, dovecot.org offers list access by IMAP. :) See http://dovecot.org/mailinglists.html how would somebody who has an existing mailing list (managed by ezmlm- idx) set up IMAP access to their list archives like this? Just wrote this: http://wiki.dovecot.org/HowTo/ReadOnlyArchive signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Wrong message information
Timo Sirainen wrote: I could yesterday also reproduce the broken INTERNALDATE pretty easily, but I can't anymore after that patch.. So what can I do to help you reproduce it? I am still getting it quite often, though I am unable to create a scenario where it always shows up. Anders.
Re: [Dovecot] Sort output of dovecot -n alphabetically?
On 5/24/2008, Timo Sirainen ([EMAIL PROTECTED]) wrote: Is there a way? Postfix does this by default, and it makes it much less likely to miss/overlook a setting... If there is no way, any chance to modify it so that it does? I'd rather not touch that code until it gets rewritten with v2.0. Also I kind of like it that the current way lists them in the same order as they're in dovecot-example.conf. I can definitely see the value in both, and didn't mean to suggest that the current behavior be replaced... so, maybe in 2.0, make the default the way it is now, and add a sort switch (dovecot -ns?) to sort them alphabetically? It really does make it easier to find a specific setting, and/or make sure you're not missing something. -- Best regards, Charles
[Dovecot] 1.1rc5 Panic: mailbox-tree.c: line 171 (mailbox_tree_iterate_set_next_node)
Hi, I do hope this hasn't been covered. I googled and looked in the archives but didn't see anything related, so hopefully I am not covering old ground. I recently upgraded from 1.0.10 to 1.1rc5. I am seeing this error from clients: May 25 11:01:54 finity dovecot: Panic: IMAP([EMAIL PROTECTED]): file mailbox-tree.c: line 171 (mailbox_tree_iterate_set_next_node): assertion failed: (len = ctx-parent_pos) May 25 10:21:19 finity dovecot: IMAP([EMAIL PROTECTED]): Raw backtrace: imap [0x80ced44] - imap [0x80ce99a] - imap [0x80a0c63] - imap(maildir_list_iter_next+0x33) [0x806ba53] - imap [0x805c49b] - imap(cmd_list_full+0x4b2) [0x805d1d2] - imap(cmd_lsub+0x1a) [0x805d55a] - imap [0x805f83c] - imap [0x805f8e5] - imap [0x80600c5] - imap(client_input+0x5e) [0x80602ce] - imap(io_loop_handler_run+0x110) [0x80d6ad0] - imap(io_loop_run+0x28) [0x80d5d28] - imap(main+0x4a1) [0x8067e71] - /lib/libc.so.6(__libc_start_main+0xe0) [0xb7de6450] - imap [0x8059d61] ## In my old install, I did have mail_extra_groups = vmail I commented that out and put in: mail_access_groups = vmail mail_privileged_group = vmail The documentation on these parameters is a bit light, so I'm not sure which (or both) to use. Can someone clarify? All the maildirs are owned by group vmail. ### dovecot -n # 1.1.rc5: /etc/dovecot/dovecot.conf ssl_cert_file: /etc/dovecot/ssl/certs/dovecot_cert.pem ssl_key_file: /etc/dovecot/ssl/private/dovecot_key.pem ssl_cipher_list: ALL:!LOW login_dir: /usr/local/var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login login_greeting: IMAP ready. login_process_per_connection: no login_processes_count: 1 mail_access_groups: vmail mail_location: maildir:/home/vmail/%u maildir_copy_preserve_filename: yes mail_process_size: 70 auth default: mechanisms: plain cram-md5 login passdb: driver: sql args: /etc/dovecot/dovecot-mysql.cnf userdb: driver: passwd userdb: driver: static args: uid=5000 gid=5000 home=/home/vmail/%u/home socket: type: listen client: path: /var/spool/postfix/private/dovecot-auth-client mode: 432 user: postfix group: postfix
Re: [Dovecot] 1.1rc5 Panic: mailbox-tree.c: line 171 (mailbox_tree_iterate_set_next_node)
On May 25, 2008, at 8:30 PM, Jeffrey Rice wrote: I am seeing this error from clients: May 25 11:01:54 finity dovecot: Panic: IMAP([EMAIL PROTECTED]): file mailbox-tree.c: line 171 (mailbox_tree_iterate_set_next_node): assertion failed: (len = ctx-parent_pos) Any idea how to reproduce this? Could you find out the exact LSUB command that causes this? For example enable rawlog for the user: http://wiki.dovecot.org/Debugging/Rawlog Also send me the user's subscriptions file. It most likely has to do with what kind of a mailbox hierarchy is used.. I commented that out and put in: mail_access_groups = vmail mail_privileged_group = vmail The documentation on these parameters is a bit light, so I'm not sure which (or both) to use. Can someone clarify? All the maildirs are owned by group vmail. You shouldn't need the above settings at all. userdb: driver: static args: uid=5000 gid=5000 home=/home/vmail/%u/home I assume gid=5000 is the vmail? That already gives vmail group access to the process. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] 1.1rc5 Panic: mailbox-tree.c: line 171 (mailbox_tree_iterate_set_next_node)
Timo Sirainen wrote: On May 25, 2008, at 8:30 PM, Jeffrey Rice wrote: I am seeing this error from clients: May 25 11:01:54 finity dovecot: Panic: IMAP([EMAIL PROTECTED]): file mailbox-tree.c: line 171 (mailbox_tree_iterate_set_next_node): assertion failed: (len = ctx-parent_pos) The command in question seems to be: 3 lsub * ## subscriptions Phil's Email.Beekeeping Phil's Email.Family Mail Phil's Email.Kaiperm Credit Union Phil's Email.Kiva Phil's Email.Rob and Jill INBOX.Sent INBOX.Trash INBOX.Drafts INBOX.Children International Phil's Email Sent Drafts Phil's Email.Kalamazoo College Phil's Email.New York Times Phil's Email.True Majority Trash .Sent.Sent-Dec-2006 .Sent.Sent-Jan-2007 .Sent.Sent-Feb-2007 .Sent.Sent-Mar-2007 Phil's Email.PayPal Phil's Email.Receipts Phil's Email.Amazon Phil's Email.Ancestry Sent.Sent-Dec-2007 ##EOF Could it be the mailboxes with the dot prefix? I have another user who does not generate a crash with the same command, and does not have any such mailboxes. I commented that out and put in: mail_access_groups = vmail mail_privileged_group = vmail The documentation on these parameters is a bit light, so I'm not sure which (or both) to use. Can someone clarify? All the maildirs are owned by group vmail. You shouldn't need the above settings at all. OK, so the gid parameter below will give dovecot rw access to the maildirs owned by vmail? userdb: driver: static args: uid=5000 gid=5000 home=/home/vmail/%u/home I assume gid=5000 is the vmail? That already gives vmail group access to the process. Yes. I did wonder if I had an error here, because home=/home/vmail/%u. I don't know where the last /home came from. Removing it didn't seem to change the error. Jeff
Re: [Dovecot] 1.1rc5 Panic: mailbox-tree.c: line 171 (mailbox_tree_iterate_set_next_node)
On May 25, 2008, at 9:23 PM, Jeffrey Rice wrote: .Sent.Sent-Dec-2006 .Sent.Sent-Jan-2007 .Sent.Sent-Feb-2007 .Sent.Sent-Mar-2007 .. Could it be the mailboxes with the dot prefix? I have another user who does not generate a crash with the same command, and does not have any such mailboxes. Yes, it's the dot prefix that causes the crashes. How did they get there? It shouldn't be possible to subscribe to mailboxes beginning with a dot. Did you do some kind of a migration that generated them? Anyway I'll fix the crash. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Vanishing maildirsize files with 1.0.7 using 'deliver' via postfix
Hi Timo, thanks for replying. My comments are inline: On Sun, May 25, 2008 at 2:25 AM, Timo Sirainen [EMAIL PROTECTED] wrote: snip However almost immediately a maildirsize folder vanished. Soon after another, then another, and now we're missing nearly 40 of them. Maildir++ quota recalculation works like: Go through all files and sum up their sizes. Keep track of the highest directory mtime. Once everything is calculated, again go through all directories and find the highest mtime. If the highest mtime had increased, something had changed, so delete maildirsize file. So could it be simply that the recalculation is slow enough that the maildir changes during it and causes the file to be deleted? Another possibility is that some error happens, but then Dovecot should have logged something. I'm not seeing anything in my logs. It's certainly possible that multiple mails are delivered during a recalculation. I'm not quite sure I understand the mtime explanation above, are you saying that if dovecot thinks that the maildirsize file is inaccurate it deletes it and goes on? Do you keep your quota limits stored only in the maildirsize file? If not, having the files deleted shouldn't affect functionality, but of course the performance is worse. Basically yes, we have many users with different quotas and as such we cannot use a single quota in the config file. So, it sounds like I'm the only person who has encountered this problem? If it's really just a consequence of the maildir changing, wouldn't it be more common? Thanks again Timo, - jason
Re: [Dovecot] Vanishing maildirsize files with 1.0.7 using 'deliver' via postfix
On May 25, 2008, at 10:09 PM, Jason Forester wrote: Maildir++ quota recalculation works like: Go through all files and sum up their sizes. Keep track of the highest directory mtime. Once everything is calculated, again go through all directories and find the highest mtime. If the highest mtime had increased, something had changed, so delete maildirsize file. So could it be simply that the recalculation is slow enough that the maildir changes during it and causes the file to be deleted? Another possibility is that some error happens, but then Dovecot should have logged something. I'm not seeing anything in my logs. It's certainly possible that multiple mails are delivered during a recalculation. I'm not quite sure I understand the mtime explanation above, are you saying that if dovecot thinks that the maildirsize file is inaccurate it deletes it and goes on? Pretty much, yes. If any mailbox's new/ or cur/ directory changes in some way (flag changes also cause this..) during recalculation, the result is just discarded. Do you keep your quota limits stored only in the maildirsize file? If not, having the files deleted shouldn't affect functionality, but of course the performance is worse. Basically yes, we have many users with different quotas and as such we cannot use a single quota in the config file. That's a bug in v1.0 actually, it shouldn't be deleting the file if it can't be regenerated. v1.1 doesn't delete it and just hopes it gets eventually recalculated and fixed. So, it sounds like I'm the only person who has encountered this problem? If it's really just a consequence of the maildir changing, wouldn't it be more common? I think there are two issues: 1) Your recalculation is probably quite slow, assuming you don't have the S=sizes in filenames. deliver adds these to new mails, but it doesn't help for old ones. 2) Most people specify the limits in Dovecot's userdb, so this isn't an issue. What userdb do you use? PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Wrong message information
Timo Sirainen [EMAIL PROTECTED] writes: I could yesterday also reproduce the broken INTERNALDATE pretty easily, but I can't anymore after that patch.. I can now reproduce one problem quite easily, with: $ A=6 ; ./send_fetch_test.py [EMAIL PROTECTED] pw file sleep $A; ./send_fetch_test.py [EMAIL PROTECTED] pw file The A sleep value is the runtime of the script. If I have the mailbox open and in IDLE, 2 seems to work out. So the trick is to have the second instance expunge the mailbox just as the first instance is about to receive its message. That gives me output like this (with the two processes mixed): ['./send_fetch_test.py', '[EMAIL PROTECTED]', 'pw', 'file'] 2008-05-26 00:06:13.190925 Sent 30 bytes to [EMAIL PROTECTED] 2008-05-26 00:06:13.191258 No messages in INBOX. Waiting... 2008-05-26 00:06:14.191755 No messages in INBOX. Waiting... 2008-05-26 00:06:15.192545 No messages in INBOX. Waiting... 2008-05-26 00:06:16.193528 No messages in INBOX. Waiting... 2008-05-26 00:06:17.194486 No messages in INBOX. Waiting... 2008-05-26 00:06:18.198344 No messages in INBOX. Waiting... ['./send_fetch_test.py', '[EMAIL PROTECTED]', 'pw', 'file'] 2008-05-26 00:06:19.188813 Sent 30 bytes to [EMAIL PROTECTED] 2008-05-26 00:06:19.189098 No messages in INBOX. Waiting... 2008-05-26 00:06:19.198841 ERROR: Got invalid RFC822.SIZE 0: 1 (UID 1368 FLAGS (\Recent) INTERNALDATE 01-Jan-1970 00:00:00 + RFC822.SIZE 0) 2008-05-26 00:06:20.189559 No messages in INBOX. Waiting... 2008-05-26 00:06:20.199554 ERROR: Got invalid RFC822.SIZE 0: 1 (UID 1368 FLAGS (\Deleted \Recent) INTERNALDATE 01-Jan-1970 00:00:00 + RFC822.SIZE 0) 2008-05-26 00:06:21.190381 No messages in INBOX. Waiting... 2008-05-26 00:06:21.200448 ERROR: Got invalid RFC822.SIZE 0: 1 (UID 1368 FLAGS (\Deleted \Recent) INTERNALDATE 01-Jan-1970 00:00:00 + RFC822.SIZE 0) 2008-05-26 00:06:22.191418 No messages in INBOX. Waiting... 2008-05-26 00:06:22.201470 ERROR: Got invalid RFC822.SIZE 0: 1 (UID 1368 FLAGS (\Deleted \Recent) INTERNALDATE 01-Jan-1970 00:00:00 + RFC822.SIZE 0) 2008-05-26 00:06:23.192353 No messages in INBOX. Waiting... 2008-05-26 00:06:23.207362 ERROR: Got invalid RFC822.SIZE 0: 1 (UID 1368 FLAGS (\Deleted \Recent) INTERNALDATE 01-Jan-1970 00:00:00 + RFC822.SIZE 0) 2008-05-26 00:06:24.193537 No messages in INBOX. Waiting... 2008-05-26 00:06:24.208543 Got valid RFC822.SIZE 1104: 2 (UID 1369 FLAGS (\Recent) INTERNALDATE 26-May-2008 00:06:19 +0200 RFC822.SIZE 1104) 2008-05-26 00:06:25.194555 Got valid RFC822.SIZE 1104: 1 (UID 1369 FLAGS () INTERNALDATE 26-May-2008 00:06:19 +0200 RFC822.SIZE 1104) I can only get this with Procmail delivery, not Dovecot deliver. Anders.
Re: [Dovecot] Vanishing maildirsize files with 1.0.7 using 'deliver' via postfix
On Sun, May 25, 2008 at 9:18 AM, Timo Sirainen [EMAIL PROTECTED] wrote: snip I think there are two issues: 1) Your recalculation is probably quite slow, assuming you don't have the S=sizes in filenames. deliver adds these to new mails, but it doesn't help for old ones. We just changed to Deliver, so that's probably true. 2) Most people specify the limits in Dovecot's userdb, so this isn't an issue. What userdb do you use? We are using ldap for auth/user. I will take a look at specifying it there so that the quotas don't vanish, but won't reporting still fail? The main reason the customer wants IMAP quotas instead of filesystem quotas is for reporting quota utilization via mail client and webmail. If I can't get stable reporting I'll probably just go back to fs quotas and be done with it. Thanks, - jason
Re: [Dovecot] Vanishing maildirsize files with 1.0.7 using 'deliver' via postfix
On May 26, 2008, at 4:30 AM, Jason Forester wrote: 2) Most people specify the limits in Dovecot's userdb, so this isn't an issue. What userdb do you use? We are using ldap for auth/user. I will take a look at specifying it there so that the quotas don't vanish, but won't reporting still fail? It doesn't fail, it still reports the calculated quota size, but it just doesn't remember it for future calculations. The main reason the customer wants IMAP quotas instead of filesystem quotas is for reporting quota utilization via mail client and webmail. If I can't get stable reporting I'll probably just go back to fs quotas and be done with it. Filesystem quota can be reported just as well. Although for NFS RPC quota you'd have to use a separate plugin with v1.0: http://dovecot.org/patches/1.0/quota-rquotad.c PGP.sig Description: This is a digitally signed message part
