|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: defer_if_* and restriction classes
From: /dev/rob0 (rob0
gmx.co.uk)
Date: Thu Jun 30 2005 - 13:02:10 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thursday 30 June 2005 11:26, Noel Jones wrote:
> >positives. So I started using it preceded by defer_if_reject:
> >[ ... ]
> >smtpd_restriction_classes = ... policy, spamcop ...
> >policy = check_policy_service unix:private/policy
> >spamcop = reject_rbl_client bl.spamcop.net
> >smtpd_recipient_restrictions = ... defer_if_reject spamcop, policy
> >
> >I expected Spamcop positives to return 454's and policy rejections
> > to return 5xx. But policy rejections were also 4xx.
> >
> >Yes, this is documented, but it seems inconsistent to me. I expected
> >defer_if_* to behave like warn_if_reject, only affecting the
> >restriction which immediately follows.
[ typo repaired in above ]
> I think you misunderstand the defer_if_[permit,reject] parameters.
> These are actions in themselves, just like REJECT or DEFER or OK,
> they are not a modifier like warn_if_reject.
Oh, that makes sense now.
> These are special actions as the actual response is determined after,
> and delayed until, all other restrictions have been evaluated.
> So your example above (corrected with defer_if_reject) would turn any
> rejection by spamcop or the policy service into a deferral.
And (please correct or confirm) it cannot be "contained" within a
restriction class. If it's inside my "spamcop" class it will still
apply to any further restrictions.
> If you want spamcop to return 450 and more trusted rbl's to use 550,
> I believe you can use the rbl_reply_maps feature to do this.
> http://www.postfix.org/postconf.5.html#rbl_reply_maps
Splendid idea. I will do that. Thank you for the reply.
[on further thought ]
Just yesterday we had a thread about DNS whitelisting. Will this do
whitelisting?
main.cf:
[ ... ]
rbl_reply_maps = hash:$config_directory/rbl_reply_maps
smtpd_client_restrictions = [ ... various permit restrictions ... ]
reject_rbl_client dns.whitelist.local
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net, [ ... ] permit
rbl_reply_maps:
dns.whitelist.local OK
bl.spamcop.net 454 $client Deferred: $rbl_reason
It's ugly to use the "reject" when you mean "permit" and "bl" when you
mean "wl", but we take what we can get, I suppose. :)
I'm not going to try this, myself, having moved my whitelists to hash
and CIDR maps, but I'm curious.
--
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]