On 10/27/2010 7:02 PM, Al Zick wrote:
Is there a replacement for procmail? I know it seemed to take
longer and did raise cpu usage, but when I first installed it
with bogofilter, it almost eliminated spam getting into my inbox.
depends on why you're using procmail... If you need a way to
interface spam/virus filtering, amavisd-new + spamassassin +
clamav + sanesecurity clam signatures are a popular and
effective combination, although SpamAssassin can use quite a
bit of resources.
problems lately have been with email. I feel like I need to
get postfix to stop using so much cpu.
Show some evidence. Postfix shouldn't use very much CPU.
Over the last month or so I am getting something like 2 to 3
times the spam, so Postfix cpu usage has changed with it. It
is not that it is using an abnormal amount of cpu for the
increased work it is doing. I am sorry I should have explained
that before.
How many connections are you getting per minute?
So then you are saying it is normal to have 1,000s of emails
per second hitting the mail server just to be temporarily
bounced by the graylisting when in the end they get bounced
anyway. Even after they are bounced, they just keep coming
anyway.
Most greylist services use DEFER_IF_PERMIT so that mail that
can be permanently rejected is not deferred to retry.
If your forwarded mail is what's attempting repeated delivery
despite being rejected, you'll need to whitelist those servers
and eat the mail. Otherwise, firewall clients who refuse to
go away.
Identify the problem, then address it.
Sounds as if you've foolishly set "soft_bounce = yes"
# postconf -d | grep soft_bounce
soft_bounce = no
"man postconf" to see what "-d" does and why the above
information is useless.
But no matter; soft_bounce doesn't appear in your "postconf
-n" listing, so that's not it.
[postconf output]
bounce_queue_lifetime = 2d
default_destination_concurrency_limit = 5
default_process_limit = 15
maximal_backoff_time = 4h
maximal_queue_lifetime = 3d
minimal_backoff_time = 2h
qmgr_message_active_limit = 50
qmgr_message_recipient_limit = 50
queue_run_delay = 30m
Your settings resemble what someone with an underpowered
server with a bad backscatter problem might try. If that's
not your situation, use the defaults. If that *is* your
situation, address the source of the problem rather than
putting postfix colored band-aids on it.
Mucking around with the above settings is a good way to
cripple postfix performance. Tread carefully here.
With a process limit of 15, any server less than 10 years old
should hardly get above idle. The default has been 100 for
years; most servers can easily support several times that.
smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination, reject_invalid_hostname,
reject_unauth_pipelining, reject_non_fqdn_sender,
reject_unknown_sender_domain, reject_non_fqdn_recipient,
reject_unknown_recipient_domain, reject_rbl_client
bl.spamcop.net, reject_rbl_client cbl.abuseat.org, permit
OK. I suggest dropping cbl.abuseat.org and adding
zen.spamhaus.org (zen includes cbl data).
I also like using reject_unknown_reverse_client_hostname to
reject zombies with no rDNS record.
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname
unknown_local_recipient_reject_code = 550
Good.
Consider a lower smtpd_hard_error_limit so that postfix can
disconnect misbehaving clients sooner. Something between
2..10 is probably good for most sites.
http://www.postfix.org/postconf.5.html#smtpd_hard_error_limit
Consider using the postfix anvil service to limit how much
mail individual clients can send. Note: anvil is not for
traffic shaping. You may need to exempt a few high volume
clients, such as your forwarders.
http://www.postfix.org/TUNING_README.html#conn_limit
If you have repeat offenders that send lots of spam, firewall
them. You can use fail2ban to automatically temporarily
blacklist clients that exceed a set number of rejects per time
period.
http://www.fail2ban.org
If system load is a problem, consider running a recent postfix
snapshot with the new postscreen service. The intent of
postscreen is to reject as much spam as possible using as few
system resources as possible. (You'll need to upgrade
somewhat frequently to stay with reasonably current snapshots.)
http://www.postfix.org/POSTSCREEN_README.html
[nothing remarkable in master.cf; looks like defaults]
I was wondering if using something like policyd would help the
spam problem?
Your time will probably be best spent in identifying the
actual problem and addressing it, rather than just bolting a
bunch of stuff into postfix hoping something will change.
Once you identify the problem as something policyd might help,
then policyd is worth trying.
Is there a proper way to filter spam? If so, what is it?
If it was easy, no one would get spam. This situation is
complicated since the type of spam and the tolerance for false
positives are local issues. Sounds as if a lot of your spam
is forwarded from accounts on other servers; that's something
SpamAssassin and clamav+sanesecurity sigs can help with.
You can have great success if you can spend time and energy on
it; otherwise just sign up for google apps and gmail.
-- Noel Jones
