Christian Balzer wrote: >> Philip wrote:
>>
>> The documentation makes it clear that this is
>> only possible for single-file mailboxes.
>>
> Any plans on making this work with maildir? I know it's a fairly
> complex mess, but it would be a nice thing to have, at the least
> (I/O) expense
> of course.
Maybe an option of setting an expandable string that defines a file to check
the read time of to determine the last account access time? You'd have to
then get support in the POP3/IMAP program to touch the file every time the
account is checked, but it would be a start at least? Besides, if it's an
expandable string, you could just make a wrapper program that could scan a
directory for the newest read time on a file or something - would suck for
performance but you'd have the ability to use the quota retry stuff. Or
heck, you could store something in a database and retrieve that for the last
access time.
>
> I know that the maildirsize gets rewritten every 15 minutes if the
> mailbox is full, as a re-count is enforced. So it's not the correct
> place to base a decision on, aside from the little detail that it's
> optional to boot. If there was a way (maybe with an additional helper
> file) to record the fact that nothing actually changed (used
> space/number of files) for whatever period of time, exim could base
> it's decision on that.
>
> Failing that, the newest file in "maildir/new" would be a valid
> choice, because obviously nobody looked at this mailbox with a client
> since that date.
That would cost a bit of time - exponentially more based on how many files
they have in there that would need scanning.
>
> If there are no files in "new", I guess things get hairy. One could of
> course apply the same logic for "cur", but mails might have been moved
> to other folders from there and to be sure exim would need to check
> all the files in all the "folders". And I quote folders, because of
> course exim doesn't really know for sure what kind of helper
> directories/files
> a specific imap/pop server might create in/below the "maildir" and if
> any of those are potentially (and periodically) being updated w/o the
> user ever logging in.
Yep, which is why it's probably not feasable to do this - having support
from all the email daemons (POP, IMAP, SMTP etc...) to all use one method of
determining the last access time would be best. I think giving Exim the
flexibility to allow us to determine what that is would be easiest. You
wouldn't need to change it around for something better in the future. Just
one expandable variable that expects a timestamp or something could work?
Then we could pick how we want to retrieve that value - scanning files on
disk, retrieving a value from a db, etc... So long as the POP/IMAP or
whatever else servers can give you similar functionality (to update a db,
touch a file, etc...) it would work.
Oh and and to add to my previous email on this subject about having an
expandable string for setting the quota size in Exim - I failed to realize
you'd want to have either 2 variables, or one that can take 2 returned
numbers or something because you'd need one to specify the quota limit, and
one to specify the current used disk space so that Exim doesn't need to know
how to calculate either values.
