Hey all, I've got a couple servers using Maildir format. As I understand it from a simple perspective, 'new' contains newly delivered messages, and 'cur' contains messages that have been 'handled'. I like to keep things simple for users, so rather than have 'Spam', 'Junk' 'ToLearn' and other possibly confusing folders, what I thought I would do is scan their .Spam/cur folder for mail that was older than an hour (based on file atime(?) stamp) and feed that through SpamAssassin. The idea being that anything in 'cur' would: 1. have been moved there by the user. 2. be recently read, and I think if it were innocent, would be handled within an hour 3. Not contain newly delivered, unread mail. This is actually what I see when I view my Spam folder through Evolution. If I use a PHP webclient - either Horde or Roundcube (I've captured the debugs if you'd like them), then a simple view of the Spam folder causes the files to be moved from new/ to cur/. They are updated with the :2, - but since nothing was actually done, no flags are added. So I'm left with a quandry. I guess the simple question is, Should mail in cur, EVER not have a flag? I suppose if it were marked as UNSEEN after being SEEN, that's possible. So I just answered myself there :) Is it possible to have Dovecot NOT move a file from new/ to cur/ until a flag has been assigned to the mail? Just from a, possible, performance standpoint - it seems when accessing an INBOX from a PHP webmail system with MANY new mails, there is an unnecessary(?) mass move of these files to another folder. Thoughts? Rick
On Sun, 1 Mar 2009, Rick Romero wrote:> So I'm left with a quandry. I guess the simple question is, Should mail > in cur, EVER not have a flag? I suppose if it were marked as UNSEEN > after being SEEN, that's possible. So I just answered myself there :)Just SELECTing a mailbox causes Dovecot to> Is it possible to have Dovecot NOT move a file from new/ to cur/ until a > flag has been assigned to the mail? Just from a, possible, performance > standpoint - it seems when accessing an INBOX from a PHP webmail system > with MANY new mails, there is an unnecessary(?) mass move of these files > to another folder.No, (as I understand it) because the time when they are moved to cur/ is when they are assigned UIDs. You can avoid this performance loss (as I understand it) by using Dovecot deliver to deliver the messages straight into cur/. (Others including Timo, correct me if I misunderstand!) -- Asheesh. -- Many pages make a thick book, except for pocket Bibles which are on very very thin paper.
On Sun, 2009-03-01 at 12:41 -0600, Rick Romero wrote:> I've got a couple servers using Maildir format. As I understand it from > a simple perspective, 'new' contains newly delivered messages, and 'cur' > contains messages that have been 'handled'.I'm not sure if there's anything official, but typically messages are moved from new/ to cur/ the first time they're seen by a MUA. Dovecot adds \Recent flag to that session which managed to move the message to cur/.> Is it possible to have Dovecot NOT move a file from new/ to cur/ until a > flag has been assigned to the mail?By changing the code, sure. I'm not really interested in implementing that.> Just from a, possible, performance > standpoint - it seems when accessing an INBOX from a PHP webmail system > with MANY new mails, there is an unnecessary(?) mass move of these files > to another folder.You could try dbox format for better performance. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20090302/0f8332f8/attachment-0002.bin>