Thanks Daniel. I will look into the check_recipient_access option.
Regarding your comment:
or configure Postfix to only run your valid users through
dspam (which is the correct method).
I thought this was how I had it set up - at least this is how I meant it to
be set up. Are you able to determine from my configs whether this is what I
curently have configured. The intention is that postifix will look at the
mysql domain / users table from posfixadmin and only allow the domains /
user configured there. Those tables only contain valid users/domains.
Thanks.
----- Original Message -----
From: "Daniel L. Miller" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, April 22, 2007 5:26 PM
Subject: Re: [dspam-users] Non-local virtual users and performance
Derrick Shields wrote:
I have dspam configured with postfix, cyrus, mysql and amavisd/clamav on
FC4 using virtual domains and postfixadmin. This has been running for
almost 2 years without any problems. Recently though dspam is hanging
due to what appears to be mysql performance issues. Looking at the dspam
tables, I'm seeing a lot of usernames in the dspam_virtual_uids which
aren't valid users - many aren't even valid domains. Checking the
/var/dspam folder, I see the same non-local entries all over the place
for <user>.stats and <user>.log files. The only .mbox files in that
folder are for actual users, so it seems that dspam is only quarantining
for valid accounts. My question is whether dpsam is suppose to be
tracking stats and virtual uids for non-local users. I wonder if these
additional uids are causing some performance issues. My current
dspam_virtual_uids table is showing 3587 users, with only about 50 of
these valid. My dspam_token_data table is showing about 2.5 million
records and I have a cron script which purges old records from that
table. I just did a mysql OPTIMIZE TABLE and will see what happens.
Any ideas about all the non-local virtual users? Any ideas about the
sudden mysql performance drop? Any suggestions for debugging what dspam
is doing to determine the exact nature of the hanging?
While I admit I ddin't parse your config that closely, this is typically
the result of running "everything" through dspam. Because your dspam
config specifies opt-out, dspam will by default process everything you run
through it. If it was working before, and now broke, either you hit a
magical maximum of mysql - or you changed/upgraded your Postfix and/or
dspam and something's different now. Either switch dspam to opt-in and
create the opt-in files for all your users (this is the less recommended
option) - or configure Postfix to only run your valid users through dspam
(which is the correct method).
Your smtpd_recipient_restrictions are listed in the wrong order (list your
blocks first unless you have good reason otherwise). Spend some time on
the Postfix website reading the docs - but here's a quicky:
In main.cf:
smtpd_recipient_restrictions =
reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_unauth_destination,
reject_unauth_pipelining,
reject_invalid_hostname,
reject_rbl_client relays.ordb.org,
reject_rbl_client opm.blitzed.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl-xbl.spamhaus.org,
check_recipient_access hash:/etc/postfix/maps/recipient_access, //
magic line
permit_mynetworks, // shouldn't need this line - try removing it
permit_sasl_authenticated
/etc/postfix/maps/recipient_access:
<yourdomain.com> FILTER lmtp:unix:/var/dspam/dspam.sock
with the check_recipient_access filter map, only recipients matching your
domain will be passed to dspam.
--
Daniel
