On Wed, 18 Nov 2009 10:12:54 -0800 "R-Elists" <list...@abbacomm.net> wrote:
> > looking for theoretical and practical insight on general multi domain > email hosting type servers... > > Q1) on high volume email servers, is it wise to expire more than once > a day, or is once a day the "right" amount so that once is not always > in some form of expiring ??? > ... > Q2) on a low, or much lower volume volume email server, is it best to > expire once a day or should it be done less frequently so that there > is a better set of data for bayes? I think it's worth reading the sa-learn manpage on this - paying particular attention to the EXPIRE LOGIC (particularly 'the definition of "wierd"') and the ESTIMATION PASS LOGIC. The expiry logic really should be very simple: we want to reduce the token count to 75% of nominal and then convert the token reduction to a new atime cutoff. It's actually quite straightforward to simply compute an accurate estimate of the atime cutoff; unfortunately SA doesn't do that that, it uses an overcomplicated and unreliable two stage process. The first stage is an estimate based on the previous expiry, if this result fails the aforementioned "weird" test then a crude estimate based on powers of two multiples of 12hours (up to 256 days) is used instead. The second stage is unpredictable, and can remove huge numbers of tokens, so you want to avoid it. One of the definitions of weird is that the tokens to be expired are between 2/3 and 3/2 of the previous expiry count, so you should be looking to expire roughly the same amount on each call. If you expire too often the first stage will never "lock-on", and you will get big swings in the token counts. I'd suggest about 20% of the nominal size on each call. All of this is really optimised for autoexpire. I wonder if it's possible to turn-off autoexpire and then run something like sa-learn --cf='autoexpire 1' from crontab instead of --force-expire
