RE: SA vs. postfix main.cf
At one time I tried to "do it all" in Postfix. It's all or nothing binary operation of its Spam rules drove me to find another solution to Spam; SpamAssassin. Now a triggered rule only adds to a Spamminess value, and won't kill the message. I ultimately took almost all the rules out of Postfix because I couldn't keep up with the false positives they created. All the FQDN, MX, an A record checks were removed due to false positives... The check_* restrictions implement white and black listing. smtpd_recipient_restrictions = check_recipient_access hash:$config_directory/smtpd-recipient-checks, permit_mynetworks, reject_invalid_hostname, reject_unauth_destination, check_recipient_access regexp:$config_directory/smtpd-recipient-checks.rx, check_sender_access hash:$config_directory/smtpd-sender-checks, check_sender_access regexp:$config_directory/smtpd-sender-checks.rx, check_client_access hash:$config_directory/smtpd-client-checks, check_helo_access hash:$config_directory/smtpd-helo-checks, reject_unknown_recipient_domain smtpd_data_restrictions = reject_unauth_pipelining <> > -Original Message- > From: Menno van Bennekom [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 07, 2004 5:45 AM > To: users@spamassassin.apache.org > Cc: David Newman > Subject: SA vs. postfix main.cf > > >We run postfix 2.1.5_1,1 on FreeBSD 5.2.1, and use some RBL lists: > >smtpd_recipient_restrictions = > >... > > reject_rbl_client opm.blitzed.org, > > reject_rbl_client list.dsbl.org, > > reject_rbl_client proxies.relays.monkeys.com, > > reject_rbl_client relays.ordb.org, > > reject_rbl_client bl.spamcop.net, > > reject_rbl_client sbl.spamhaus.org > >We are seeing cases where mail is rejected because of the > RBL lists, > >even when a sender is whitelisted in a recipient's SA > user_prefs file. > >Is there any way to reverse the order of operations so that postfix > >doesn't check with the RBL list when SA says a sender is OK? > > You can't reverse the checks, but you can whitelist > addresses in Postfix. > I use the check_client_access to allow certain domains/ips > to send mail although they appear in RBL's. Just put them in > the access-file with 'OK' > on the end of the line. You can do the same with check_sender_access. > And make sure this check is done before the RBL checks, like: > smtpd_recipient_restrictions = reject_non_fqdn_sender, >reject_non_fqdn_recipient, >permit_mynetworks, >reject_unauth_destination, >check_client_access hash:/etc/postfix/client_access, >check_helo_access hash:/etc/postfix/helo_access, >check_sender_access hash:/etc/postfix/sender_access, >reject_rbl_client dynablock.njabl.org, >reject_rbl_client dul.dnsbl.sorbs.net, >reject_rbl_client cbl.abuseat.org > > Regards > Menno van Bennekom > >
Re: SA vs. postfix main.cf
Per Jessen wrote: Not that I can think of. Essentially you need to decide who makes the decision for you - SA or Postfix. By the time postfix delivers the mail to SA via the content_filter, all the Postfix checks are complete - smtpd__restrictions - so if postfix has decided to reject an email, SA can't really override that later. Therefore, if your users disagree with your blockinglist, don't use those blockinglist(s) in postfix and leave it to SA. In order to do the same kind of whitelisting in Postfix, you'd basically need to setup some check_*_access checks before your RBL's allowing them to pass. -- Matt Barton Webexcellence PH: 317.423.3548 x22 TF: 800.808.6332 x22 FX: 317.423.8735 [EMAIL PROTECTED] www.webexc.com
Re: SA vs. postfix main.cf
David
I had a similar problem with another program..
If you let SA do all the RBL's etc it won't use the RBL's as a
blacklist, just add to the score.
You may have to aleviate the straing on the system by then letting the
MTA (postfix in your case) check the email for valid email addresses,
and not letting invalid ones in.
--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
David Newman wrote:
Greetings, and apologies is thisn't the right forum for this post. I've
already asked on postfix-users with no luck there.
We run postfix and SpamAssassin. Postfix's use of RBL is pre-empting
SA's ability to whitelist specific senders. I'm wondering if there is
some way to override that.
We run postfix 2.1.5_1,1 on FreeBSD 5.2.1, and use some RBL lists:
smtpd_recipient_restrictions =
...
reject_rbl_client opm.blitzed.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client proxies.relays.monkeys.com,
reject_rbl_client relays.ordb.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org
We also use SpamAssassin 3.0.1_2, called from master.cf:
smtp inet n - n - - smtpd -o \
content_filter=spamassassin
...
spamassassin
unix - n n - - pipe
user=nobody argv=/usr/local/bin/spamc -f -e /usr/local/sbin/sendmail
-oi
-f ${sender} ${recipient}
We are seeing cases where mail is rejected because of the RBL lists,
even when a sender is whitelisted in a recipient's SA user_prefs file.
Is there any way to reverse the order of operations so that postfix
doesn't check with the RBL list when SA says a sender is OK?
Thanks.
Regards,
David Newman
Network Test
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.
**
Re: SA vs. postfix main.cf
David Newman wrote: > We run postfix and SpamAssassin. Postfix's use of RBL is pre-empting SA's > ability to whitelist specific senders. I'm wondering if there is some way > to override that. [snip] > Is there any way to reverse the order of operations so that postfix > doesn't check with the RBL list when SA says a sender is OK? Not that I can think of. Essentially you need to decide who makes the decision for you - SA or Postfix. By the time postfix delivers the mail to SA via the content_filter, all the Postfix checks are complete - smtpd__restrictions - so if postfix has decided to reject an email, SA can't really override that later. Therefore, if your users disagree with your blockinglist, don't use those blockinglist(s) in postfix and leave it to SA. -- Per Jessen, Zurich Let your spam stop here -- http://www.spamchek.com
