* Wolfgang Hennerbichler <wo...@wogri.com> [2009-06-28 08:28]:
> Hi,
>
> I recently put my first spamd installation into production and am quite
> impressed with the results, good work, folks. Nevertheless I have some
> questions:
> * it seems that when spamd scans it's database in /var/db/spamd (which
> is currently ~160MB of size) it doesn't accept any new requests on it's
> port (at least it let's the clients wait). That sucks. I see 2 spamd
> processes process states hanging in: biowait, pipewr - I understand that
> while the database is being scanned (and maybe locked) new requests maybe
> can't easily be written to the db, is there a plan to improve that (by
> creating a queue-log or something)?
> * Due to the fact that spamd only seems to insert pf-rules into the pf
> spamd-white table when doing a db-scan it seems that it creates some
> more delays than necessary in the greylisted mta's. Let's say I have 2
> mx'es - mx1 and mx2 - my client is connecting to mx1, get's greylisted,
> connects to mx2 (protected by the same spamd instance), still keeps being
> greylisted - so my client adds a penalty time of let's say 2x5 mins.
> After 10 minutes it connects to spamd again, tries mx1, still gets
> redirected to spamd, but spamd decides to whitelist that host, and writes
> that into the spamdb. After being refused for mx1, my client tries mx2,
> and due to the fact that maybe spamd didn't scan the spamdb yet the
> pf-rules aren't in place yet, so it get's redirected to spamd once again,
> creating quite some penalty time of let's say 2x10 minutes, which
> wouldn't be necessary if spamd would insert that ip directly into pf on
> writing the whitelist-entry into the database. Are there plans to improve
> that?
Not really, basically, yes, you can race the fact that you get
whitelisted
and be refused again before other machines know you have been whitelisted..
"Correcting" this would require every connected process to write lock the
database
and have access to pf, which is prohibitive and a security issue. I do not
want the process talking to the network to have enough privilege to manipulate
pf
tables, and making instantatneous messages becomes an issue with deadlock
and the spamdb database. So realisticly, no, there's no plan to "fix" this
because
it is simply not a major issue. Your mailer should simply retry.
-Bob
