t...@uncon.org wrote: > Quoting Eric Shubert <e...@shubes.net>: > > >> 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. > > Depends on the scale of your mail server. See this entry from the ChangeLog: > > NOT BACKWARDS COMPATIBLE: Changed the graylist system to create a deeper > directory structure by creating folders for the senders' domain > names. This > will allow busy servers to use graylisting even when the number of sender > addresses could exceed the number of entries allowed in a folder. Thanks > to Trog for suggesting this one. > > My mail servers graylisting was hitting filesystem limits in less than > 24 hours.
Which limit(s) of which filesystem? > The qtp-prune-graylist script would take much longer than a > day to run on my mail server. Did you run it? In 'silent' mode? The first large server it ran on, it processed over 1.1M entries. I don't recall the run time, but I believe it was less than an hour. This was on a filesystem that had run out of inodes. > I'd basically have to run it > continuously on my server - it would certainly impact performance. How many graylist entries do you have? -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
