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