Michael Papet wrote:
- in the end easy to configure with a web frontend
The web front end is totally separate from qpsmtpd. My grand scheme was to use
Drupal+LDAP modules to do the web frontend. I've worked with Drupal enough to
do this, just never taken the time to do it. Maybe someone else has other
suggestions for a web frontend?
As a FYI, I put my qpsmtpd config files into PostgreSQL, and manipulate
them by a fairly ad-hoc set of perl libraries underneath a CGI front
end. Not fancy. Each config file is a database object (I'm not doing
per-entry). I make changes to the configuration, and hit a "push"
button that replicates the changes to each of the qpsmtpd front ends
(currently 5, at one point 11) via rsync, and then use ssh to instruct
the qpsmtpd engines to restart.
All qpsmtpd configuration under qpsmtpd/config. Tho there are a few
other files elsewhere (eg: SA local.cf).
The directory (downloaded when it changes from central corporate
database) is rsync'd into each qpsmtpd's config.
Use much the same mechanism to replicate our combined DNSBL zone to
rbldnsd instances co-resident with the qpsmtpd servers.
The PostgreSQL database also manages logs, per-user quarantine (end user
accessible) and reporting.
(personal config in the
database)
I'm nothing special as a coder, so I'm certain you can do it. LDAP isn't as popular a database to connect to as PostgreSQL/whatever, but works for me.
LDAP is easy enough with the right perl libraries, and I don't do
personal configuration.
If I were, I'd have the data in the spam filtering database (along with
the server config), and push it out periodically/ondemand as a
predigested database of some sort for qpsmtpd to have a copy of locally.
Possibly as an extension to the user directory flat file.
Since our users already visit the control server for viewing quarantine
etc., it's the logical place to maintain the per-user config.
I don't want the qpsmtpd instances to interact with more non-resident
services than absolutely necessary, especially per-message even if
cached. Both for performance and robustness reasons. Even DNS and
rbldnsd is co-resident now. At my loads (10s of millions of spam per
day), I was periodically overloading the corporate DNS infrastructure,
and I was warned not to rely on our LDAP anywhere near that level.
Yes, PostgreSQL can keep up with the logs/quarantine management. But it
ain't simple.
