On Thu, 23 Sep 2010, Wietse Venema wrote:
One possibility is to have postscreen listen on multiple IP addresses
with different MX preferences, and to require that clients don't
connect to the secondary port before the primary.
The problem I see with this is that a site with multiple MX hosts
would need to share the postscreen database. I'm concerned that a
networked SQL database would introduce unacceptable latencies and
that it the postscreen database would become a single point of
failure for multuple MX hosts.
The latency and shared-fate issues will also exist for an eventual
greylisting implementation, particularly in the case of multiple hosts
behind a load balancer. Fortunately, the dnsblog service already solves
this problem for another latency-sensitive task, so there's certainly
precedent for moving the heavy lifting to another service; a local result
cache would be appropriate here as well, along with graceful failure
handling in postscreen.
Writable SQL maps would be necessary for this (and potentially have other
uses -- I've been thinking about implementing it for at least the SQLite
code for a while now), along with some flexibility in exactly how to apply
the various policy bits, but it certainly seems like a lot of tests
relating to client connection behavior could be handled by a service like
this. The real question, though, is whether it's actually worth doing all
the work, when the existing policy service mechanism is probably good
enough. (I don't have any particularly strong feelings on the matter, but
my greylisting policy server has also never been very high on any list of
reasons to buy more hardware...)
Perhaps something to consider for a future iteration?
-Rob
