Re: [nznog] [Fwd: Re: [Fwd: [Computer-support] Greylisting - one day after]
-------- Original Message -------- Subject: Re: [nznog] [Fwd: [Computer-support] Greylisting - one day after] Date: Thu, 16 Nov 2006 14:08:46 +1300 From: Jasper Bryant-Greene
Organisation: Album Limited To: Richard CC: Russell Fulton , nznog(a)list.waikato.ac.nz References: <2.1.1-1800921-393-A-OEWW(a)222.154.242.106> Question around this - we are currently looking at implementing it, but we have three mail servers behind a load balancer. The software we're looking at is postgrey (as we use Postfix), but it uses BDB database files...
Which means each server has an individual greylisting database, and mail could potentially (worst case) be bounced three times before getting through. Has anyone solved this problem already?
With BDB database files you really don't have a lot (any?) options. You could put the file on a NFS share and let all 3 servers use it, but locking issues and overall BDB speed would probably impact your performance greatly. The best solution in this case would be to bring a new server that will run a real database (MySQL, Oracle). If you use a greylisting package that supports these databases (gld does), you can have all servers point to this server and use one central greylisting database. Of course, this way you have a single point of failure (while gld will allow e-mails to flow if the database is not available, you loose greylisting, of course). We at the moment have local MySQL databases on each server. This means that the greylisting delay could be longer, but as we don't have real load balancer but use DNS only, so far this hasn't been the case. As far as I can see, actually, remote MTAs always came back to exactly the same server they were originally greylisted on, probably due to DNS caching on their side. Bojan
Russell Fulton wrote: [snip]
The best solution in this case would be to bring a new server that will run a real database (MySQL, Oracle). If you use a greylisting package that supports these databases (gld does), you can have all servers point to this server and use one central greylisting database. Of course, this way you have a single point of failure (while gld will allow e-mails to flow if the database is not available, you loose greylisting, of course).
We've gone with SQLGrey [1], which is a fork of postgrey that stores its data in SQLite, MySQL or PostgreSQL. We're using MySQL as that's what our mail data (SpamAssassin bayesian learning data, domain routing, etc) is already in. We've got two MySQL servers doing master/slave replication (SpamAssassin seems to break with multi-master due to a few design flaws involving inserting unique values at the same time on different servers...) with scripted failover and failback, so there's a bit of redundancy there. [1] http://sqlgrey.sf.net/ -- Jasper Bryant-Greene Director Album Limited jasper(a)albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/
participants (2)
-
Jasper Bryant-Greene
-
Russell Fulton