>Clear out the postgrey pass list? - I believe this expires after some time >limit, but I'm unsure what that is.
90+% of greylist passed records will be passed again very quickly. > >... I think I might have a file > > >>have a what? > >I was thinking I had a file with some type of lock, as the server seamed to >be running slow with a very low load ... I've rebooted the server and it >doesn't seam like an issue, it's back to normal. any errors in maillog? if the SAV .db file is type hash: and hits 1.1 GB, postfix almost dies. > >as a lot of spam is getting by IMGate in the last two days. Any > >other files I should remove and let rebuild? > > >>The only file that used to need zeroing was the SAV hash: .db file >because it blew up at about 1.1 GB physical size, but now everyone >should use the btree: file type for SAV .db file, which is good to >about 4 GB. Also, the negative cache time should be a couple of >hours to avoid too much accumulation of random forged senders. > >Were is that time limit set? see the postfix README for ADDRESS_VERIFY apart from the slowness, if you're receiving a big increase in spam, you should look at the maillog to figure out where it's coming from. SAV and postgrey are very good at blocking At one high-volume site, we are seeing 1000 new domains PER HOUR added to the list of domains that are responding to SAV probes. I haven't looked yet, but I bet these are throw-away spammer domains (used for a couple hours and never again) where the spammer's MX is verifying EVERY sender. It's hard to believe there are 1000+ new LEGIT domains being added to the SAV list of domains when we started with 200K domains harvested from previous 10 days. We will probably zero the list of SAVable domains once per week to clear out the one-time domains. Len
