[Dovecot] Dovecot LDA munging INBOX access times?

[Steven F Siirila]

OK, I have some more sane thoughts after we discussed our local situation.
See inline comments.

On Wed, Jun 13, 2007 at 10:51:02PM -0500, Steven F Siirila wrote:
> On Thu, Jun 14, 2007 at 06:22:45AM +0300, Timo Sirainen wrote:
> > On Wed, 2007-06-13 at 17:52 -0500, Steven F Siirila wrote:
> > > We are running Dovecot 1.0.0 using mbox format (currently in the midst
> > > of conversion from UW IMAP).  We discovered today that the Dovecot LDA
> > > is accessing the user's INBOX at delivery time!
> > 
> > Well, there are two things:
> > 
> > 1) It always makes sure that the mbox file ends with "\n". I guess this
> > isn't all that important, but I'm not really interested in just removing
> > the code.
> 
> If that were the only reason for opening in read mode I'd lobby for this
> to be changed.  :)
> 
> > 2) If index files are fully synced, Dovecot writes X-UID: header. It
> > also updates nextuid field in X-IMAP: / X-IMAPbase: header of the first
> > message, which causes Dovecot to read() the file. The nextuid update
> > isn't really required, but I think some other bug shows up if it isn't
> > done.
> 
> Do these operations apply to Deliver or just IMAP/POP?
> 
> Not knowing enough about how the indexes work.... Question: Is it possible
> for Deliver to append a message w/o writing an X-UID header, leaving that
> operation to the IMAP/POP client code, and still maintain an updated index?

This is still an open question, but not as important to be answered now.

> If not, are there any options I can provide to Dovecot LDA to make it
> function without index file updating?

To answer my own question, one could probably use a very large value for
'mbox_min_index_size'.

> > It would be possible to check the atime before any reading is done and
> > then later after message is saved it could be updated back. Hmm. Well,
> > attached a patch that seems to work. I'm not sure if I want to add it to
> > v1.0.1.
> 
> Hmm.  I wonder how much of a timing window is left; this could be a viable
> option for us.  However, I would like to consider our future options for
> mailbox formats other than mbox (we will eventually migrate I'm sure).

For the mbox case (our immediate concern) your patch seems perfect, provided
that it is performing the read of the access time and the re-setting of the
access time during the time that the INBOX is locked.  Timo, is this the case?

> What we have is a daemon called "mailattrd" on our mail servers which runs
> on a TCP port and simply does a stat() on a user's mailbox and returns the
> atime, mtime, ctime values of said mailbox.  That "service" is used by a
> variety of our applications.  We were thinking of another possibility:
> changing Dovecot IMAP/POP to update the last access time (open in READ)
> of a specific file other than the user's INBOX.  However, we'd rather not
> maintain local modifications unless absolutely necessary.  Any thoughts on
> alternatives which might be mailbox-format-independent?

What we are considering doing is updating our local "mailattrd" to lock
using the same mechanism Dovecot is before reading the access time:

	lock /var/mail/user	(open RDONLY, fcntl SETLKW)
	stat /var/mail/user	(to get last access time)
	unlock /var/mail/user	(close)

Unfortunately, it is more overhead.  But it should be 100% accurate.
This should give us an accurate "last time the user accessed their INBOX".
I'm not sure how this would work with other mailbox formats, but we'll cross
that bridge when we get there.

> Thanks Timo for your super and timely support -- it is greatly appreciated!!

-- 

Steven F. Siirila			Office: Lind Hall, Room 130B
Internet Services			E-mail: sfs at umn.edu
Office of Information Technology	Voice: (612) 626-0244
University of Minnesota			Fax: (612) 626-7593