t...@uncon.org wrote:
> Quoting David Milholen <dmilho...@wletc.com>:
> 
>>  I just a need a little primer to understand which method of graylisting
>> i need to use.
> 
>> I just dont want those huge graylist entries lingering around.
> 
> Graylist pruning has always been a problem with spamdyke. You have a  
> few options:
> 
> 1. Use 'find' to delete old entries, as detailed in the FAQ.
>        Problems: I/O Intensive, very slow
> 
> 2. Delete your whole graylist history and start again.
>        Problems: (usually) I/O Intensive, slow, lose graylist history
> 
> 3. Use a loopback filesystem to host your graylist directory, and  
> umount/format it to clear history
>        Problems: lose graylist history, requires manual intervention  
> (unless you don't mind formatting filesystems from a script)
> 
> 4. There is a mysql patch (I believe), haven't tested it.
> 
> I quickly moved from doing option 1 to option 3, but I got a bit bored  
> with doing that after a while, so started thinking of alternative  
> schemes that don't require a spamdyke daemon to be running.
> 
> I finally came up with the following answer: add a new option to  
> spamdyke (graylist-weeks) and rotate the graylist directories on a  
> weekly basis, with automatic migration, so that old entries  
> automatically age.
> 
> So if you have graylist-weeks=3, you end up with a directory structure like:
> 
> graylist_dir/my.do.main/201009
> graylist_dir/my.do.main/201010
> graylist_dir/my.do.main/201011   <-- current week dir
> 
> all three of these directories will be checked for entries, and if  
> found, migrated to the current week directory if required. On the  
> fourth week you'll get a structure like:
> 
> graylist_dir/my.do.main/201009   <-- expired entries
> graylist_dir/my.do.main/201010
> graylist_dir/my.do.main/201011
> graylist_dir/my.do.main/201012   <-- current week dir
> 
> You can then simply delete the whole directory containing the expired  
> entries. I wrote a small program that prints out the directories that  
> need to be removed, which can be fed to rm with xargs.
> 
> If anyone's interested, I can post the patch.
> 
> Thanks,
> -trog

I think this is more complicated than it needs to be, and not any more 
efficient than the qtp-prune-graylist script 
(http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist). The 
script is admittedly a little i/o intensive, but a) some of it is 
typically cached, and b) it's not all that slow. Besides which, what's 
the problem? It's typically run once a day, and I don't see it impacting 
the performance of anything else.

To each his own though.
-- 
-Eric 'shubes'

_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to