[Dovecot] dovecot.index mtime

[Matt]

> > >> I guess the issues I still think are important:
> > >>
> > >> 1. You shouldn't use dovecot.index as your marker file.
> > >
> > > I gave up trying to use dovecot.index.  Instead I look at each users
> > > ./new directory.  If there are any messages over 6 months old I put
> > > there email address in file that tells exim to reject any new
> > > messages.  Run the script in cron.daily so if they start using it
> > > again it will reactivate in 24 hours or less.  Having to look at all
> > > messages in the ./new folders is significantly more CPU and I/O load
> > > though.  Having run the script last night it seems to work fine.
> > > Audited some of email addresses it added to be blocked and none look
> > > out of place.
> >
> > Glad to hear you've got something that's working for you.
> >
> > For what it's worth, I'd look at the newest message in the ./cur folder,
> > rather than the oldest in the ./new. (You want the last time the user
>
> But most of my user POP3 and do not leave messages on server.  I just
> check if there is a message over 6 months old in new.
>
> > looked at a message, not the first time the user got mail after being
> > logged in.) The actual difference in times probably isn't an important
> > detail when you're talking O(6 months).
> >
> > But, the benefit is that you can get the timestamp for the last time the
> > user read/deleted a message in ./cur simply by checking the change time of
> > the ./cur directory. (rather than going through all its files)
>
> Light bulb.  Wish I had thought of that.
>
> > e.g.
> > $ stat -c '%z (=%Z)' ~/Maildir/cur
> > 2007-11-14 15:26:09.000000000 -0500 (=1195071992)
> > $ stat -c '%z (=%Z)' ~/Maildir/cur/* | sort | tail -n 1
> > 2007-11-14 15:26:09.000000000 -0500 (=1195071992)
> >
> > Should make it fast enough to run in cron.hourly, depending on your number
> > of users/mailboxes.
>
> I am going to have to try this.  I used find with -mtime to find all
> messages over 6 months old in all the ./new directorys.  If this way
> works it would be far more efficient.

A flaw though.  If the account is checked daily but never receives any
new mail (such as the email account that goes to my fax machine and I
am sure there are a few others) the ctime on the cur will not be
updated.  It would not automagically start working again either since
it cannot receive new messages when suspended and thus cannot update
./cur.  Someone just might email my fax machine some day rather then
call.

This might be a good preliminary check then only then double check
that there are messages in ./new.  Of course it makes my simple perl
script a little more involved.  Is there a low overhead way to check
that ./new is not empty?

Another annoying thing about Exim is it checks if a user is over
quotta after it has accepted a message.  It then trys to write the
message to the users ./new directory and at that point generates a
bounce.  Meaning over quotta accounts generate alot of bounces to junk
mail that have invalid source email addresses from the start.  One of
the reasons I want to auto suspend unused email accounts.

Thanks.

Matt