On Nov 29, 2012, at 9:22 AM, Todd Lyons <tlyons@???> wrote:
> In my system, I don't yet know the homedir/maildir because it's part
> of the SQL lookup in the router. I can however construct it because I
> know how it's built, but I'd prefer the results from the lookup to be
> used. I dunno if that's easy at this point. Beginning testing...
I actually went ahead and enabled embedded Perl and am building on some of your ideas. In our environment we already get all the users info from the database in a prior lookup, so we have the homedir path, and we pass that in to the Perl sub and we're also going to do our idle check there (as we've done in a previous router that is no obsolete).
So our router will look something like:
pg_mdircheck:
driver = redirect
allow_fail
allow_defer
domains = +db_domains
fail_verify = true
data = ${perl{{mdir_check}\
{${extract{homedir}{Q_LUSER}}}\
{${extract{quota}{Q_LUSER}}}\
{IDLE_TIME}\
}fail}
more = false
local_part_suffix = +*
local_part_suffix_optional
The logic in the script will first test for the presence and freshness of a last_login file, if that fails, we:
return ':fail: Inactive Mailbox';
We'll next have some logic in checking the quota, without processing the maildirsize file each and every time. So on very busy systems it won't have to force this for each and every RCPT. My thinking is to cache it or have something to back it off. So if nothing has changed, no need in checking it again. My thought maybe is to create a ".overquota" file in the homedir and compare that mod date vs the mod date of the maildirsize file.. If the maildirsize file has changed then it's not due to delivering mail on Exim's part since it should be rejecting.. so go ahead and run the quota calc again.
Also there is a reason for us passing in the quota on the check here, rather than relying on the one in maildirsize. One of the actions may be for someone to actually increase a users quota, so the value in maildirsize is no longer valid. (this will be updated the next time Exim delivers a mail). Logic will be tricky but i think it should work out well.
--
Robert Blayzor
INOC, LLC
rblayzor@???
http://www.inoc.net/~rblayzor/
