|Main Archive Page > Month Archives > postfix-users archives|
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
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
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.
> 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.
> unknown_local_recipient_reject_code = 550
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.
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.
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
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.)
[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