[Dovecot] Maildir format use question
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:
- have been moved there by the user.
- be recently read, and I think if it were innocent, would be handled within an hour
- 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 22:37 -0800, Asheesh Laroia wrote:
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
From what I've observed, SELECT does not - although EXAMINE might: snip of large logfile Everything still in new/ SELECT INBOX.Spam A00801 FETCH 7 UID A00802 UID FETCH 50681:* (FLAGS RFC822.SIZE INTERNALDATE BODY.PEEK[HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE)]) A00803 UID FETCH 50681 BODY.PEEK[] A00804 UID FETCH 50682 BODY.PEEK[] A00805 UID FETCH 50683 BODY.PEEK[] A00806 UID FETCH 50684 BODY.PEEK[] A00807 UID FETCH 50685 BODY.PEEK[] A00808 UID FETCH 50686 BODY.PEEK[] A00809 UID FETCH 50687 BODY.PEEK[] A00810 UID FETCH 50688 BODY.PEEK[] A00811 UID FETCH 50689 BODY.PEEK[] A00812 UID FETCH 50690 BODY.PEEK[] A00813 UID FETCH 50691 BODY.PEEK[] A00814 UID STORE 50689:50690 FLAGS.SILENT (\Deleted \Seen) A00815 UID STORE 50691 FLAGS.SILENT (\Seen) A00816 SELECT INBOX
Next is PHP, everything moved to cur/ - entire log
00000002 CAPABILITY 00000003 NOOP 00000004 EXAMINE INBOX.Spam 00000005 UID SEARCH ALL UNDELETED 00000006 STATUS INBOX.Spam (MESSAGES RECENT UNSEEN UIDNEXT UIDVALIDITY) 00000007 UID FETCH 50674 UID 00000008 UID FETCH 50675 UID 00000009 UID FETCH 50676 UID 0000000a UID FETCH 50677 UID 0000000b UID FETCH 50678 UID 0000000c UID FETCH 50679 UID 0000000d FETCH 1,2:6 (ENVELOPE BODY.PEEK[HEADER.FIELDS (Path Message-ID Content-MD5 Content-Disposition Content-Language Content-Location Newsgroups Followup-To References)] INTERNALDATE RFC822.SIZE FLAGS) 0000000e UID SEARCH ALL UNDELETED UNSEEN 0000000f GETQUOTAROOT INBOX.Spam 00000010 LOGOUT
For a minute I thought maybe FLAGS.SILENT might be it, but that's only occuring with the client that doesn't 'auto-move' from new/ to cur/ Maybe STATUS does it.
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.
Again this isn't what I see. These messages are being accessed by UID prior to being moved from new/ to cur/.
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!)
I don't think that's right. As I understand it, Deliver is primarily used to update the indexes - I don't think there any reason to break with Maildir standards and put new mail directly into cur/
Rick
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.
participants (3)
-
Asheesh Laroia
-
Rick Romero
-
Timo Sirainen