After looking over to my own config files and think about what you
said, i came to the following changes:
1.- change my postfix main.cf to reject first any unlisted recipient
(it was almost at the end), so my new main.cf (for antispam) is now:
cut here --
smtpd_helo_required = yes
smtpd_delay_reject = yes
disable_vrfy_command = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname,
reject_non_fqdn_hostname
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_unlisted_recipient,
reject_unauth_pipelining,
reject_non_fqdn_sender,
reject_invalid_hostname,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rbl_client l1.spews.dnsbl.sorbs.net,
reject_rbl_client http.dnsbl.sorbs.net,
reject_rbl_client socks.dnsbl.sorbs.net,
reject_rbl_client misc.dnsbl.sorbs.net,
reject_rbl_client smtp.dnsbl.sorbs.net,
reject_rbl_client web.dnsbl.sorbs.net,
reject_rbl_client zombie.dnsbl.sorbs.net,
reject_rbl_client nomail.rhsbl.sorbs.net,
reject_rbl_client badconf.rhsbl.sorbs.net,
reject_rbl_client relays.ordb.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client bl.spamcop.net,
check_recipient_access hash:/etc/postfix/access,
check_policy_service inet:127.0.0.1:10023,
check_policy_service unix:private/spf_policy,
permit_sasl_authenticated,
permit_auth_destination,
permit
smtpd_data_restrictions =
reject_unauth_pipelining,
permit
cut here --
2.- Limit the number of listening smtpd processes for incoming mail
to 60 (default was 100) in the master.cf file
smtp inet n - n - 60 smtpd
3.- Limit the number of spf policy servers in master.cf (default was
also 100)
spf_policy unix - n n - 50 spawn
user=nobody argv=/usr/bin/perl /usr/libexec/postfix/smtpd-policy.pl
4.- Add all my DNS servers in my resolv.conf including my own caching
DNS (i have 2 additional dns Servers)
nameserver 192.168.200.1
nameserver 192.168.200.2
nameserver 192.168.200.246
I hope that this make a round robin on the DNS queries required by de
spf process, i dont know if this happens but im optimist.
Result:
The incoming mail takes 10 seconds more to get into the server (due
to the limit on the number of listening smptd daemons) and the cpu
usage statistics now show some spikes of 60% iowait, but most of the
time it remains on 10%.
I will keep this configuration for a couple of days making
adjustments to the number of smtpd daemons and policy servers on
main.cf if i see more iowait.
Thanks for your help.
On Oct 25, 2006, at 10:25 AM, Alex van den Bogaerdt wrote:
On Wed, Oct 25, 2006 at 10:05:53AM -0500, Adrian De los Santos wrote:
I have setup spf in postfix and found that it almost killed my server
raising the iowait at more than 90% putting the server on its knees.
while in the iowait state, the process itself doesn't use cpu.
Is the problem perhaps that too many processes are allowed to
be run simultaneously and the available memory is short, resulting
in trashing ?
Normally a process would terminate fast, but when you're waiting
for a DNS answer it stays present. A new connection could fire
up a new instance, use more memory, also wait for a DNS answer,
and so on. Snowball effect. Suddenly you need to use the swap.
This uses cpu time, time that could have been used to process the
incoming DNS reply.
I think that maybe the iowait is due to the delay that exists in the
DNS replies to the SPF process, my server recives more than 100k
mails on a daily basis, and i have a caching DNS on this same server.
The caching server will use resources as well. You may be better off
by putting it on a separate box, connected by a fast network.
Then look at the mail process:
- don't do SPF lookups if you can reject a message for other reasons
such as bad helo, non-existing receiver, etc.
- if an answer is not available from the cache, start greylisting
and thus terminate the connection. In parallel, do ask for the
SPF record (which won't be used at that time).
When the client is trying another time, your cache will have the
spf record and you get an answer fast.
- determine a sane number of processes that can run in parallel.
If this number is reached, for any reason including but not
limited to DNS lookups, refuse to accept more connections.
Others, please correct my mistakes and/or refine my suggestions.
I know this is a difficult topic.
HTH
Alex
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?listname=spf-
discuss(_at_)v2(_dot_)listbox(_dot_)com
==================================
Adrian de los Santos
demon(_at_)demon(_dot_)com(_dot_)mx
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s: a C++++ UL+++++ UC++++ US+++ UX++++ UB+++ P++++ L+++++++++
E--- W+++ N++ U++ K w-- O- M++ V PS+ PE Y+ PGP t+ 5 X R tv++ b++ DI+
+ D++ G++ e+++ h+ r++ z+
------END GEEK CODE BLOCK---
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com