Maildir format use question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Maildir format use question

Rick Romero-2

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


Reply | Threaded
Open this post in threaded view
|

Re: Maildir format use question

Asheesh Laroia
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.
Reply | Threaded
Open this post in threaded view
|

Re: Maildir format use question

Rick Romero-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Maildir format use question

Timo Sirainen
In reply to this post by Rick Romero-2
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.

signature.asc (204 bytes) Download Attachment