Wietse Venema wrote:
Roderick A. Anderson:
Also, would postscreen_cache_map work with a mysql backend?
postscreen needs very low latency (I put in explicit tests for
this). Also, postscreen requires read, write, iterate support
which is implemented only for file-based databases.
If table access requires 10ms, then postscreen can handle only 100
connection requests per second. You would be better off not using
postscreen and instead turning up the number of smtpd processes.
That makes sense. I was just looking for a way to provide some "shared
knowledge" among the servers in the cluster.
Run a cron job that checks for changes in the RDBMS and then rebuilds
the postscreen_cache_map "files" if needed.
That implies shared access to the postscreen_cache_map _file_,
and is not supported.
My bad. I was thinking how I keep the relay and transport maps up to
date on MX servers. The data is in a MSSQL table and each spool
rebuilds it's (hashed) maps when told to.
\\||/
Rod
--
