On Tuesday 04 August 2009 07:48:12 Steve wrote:
> I have a problem with restriction classes that I can't solve. I have a
> bunch of restriction classes. In order to simplify this mail I am only
> using two. One for SPF checking and the other for Greylisting. Now I would
> like to have for each of the restriction classes a bunch of conditions to
> whitelist by client ip, sender name or recipient name and that twice. Once
> on a map per policy service and one global.
>
> Basically something like that here (simplified example):
> -------
> /etc/postfix/main.cf:
> smtpd_restriction_classes =
> spf_policy
> greylist_policy
>
> spf_policy =
> check_client_access
> pcre:${config_directory}/lookups/pcre/spf_client_whitelist.cf
> check_sender_access
> pcre:${config_directory}/lookups/pcre/spf_sender_whitelist.cf
> check_recipient_access
> pcre:${config_directory}/lookups/pcre/spf_recipient_whitelist.cf
> check_client_access
> pcre:${config_directory}/lookups/pcre/global_client_whitelist.cf
> check_sender_access
> pcre:${config_directory}/lookups/pcre/global_sender_whitelist.cf
> check_recipient_access
> pcre:${config_directory}/lookups/pcre/global_recipient_whitelist.cf
> check_policy_service unix:private/spf-smtpd-policy
>
> greylist_policy =
> check_client_access
> pcre:${config_directory}/lookups/pcre/greylist_client_whitelist.cf
> check_sender_access
> pcre:${config_directory}/lookups/pcre/greylist_sender_whitelist.cf
> check_recipient_access
> pcre:${config_directory}/lookups/pcre/greylist_recipient_whitelist.cf
> check_client_access
> pcre:${config_directory}/lookups/pcre/global_client_whitelist.cf
> check_sender_access
> pcre:${config_directory}/lookups/pcre/global_sender_whitelist.cf
> check_recipient_access
> pcre:${config_directory}/lookups/pcre/global_recipient_whitelist.cf
> check_policy_service inet:127.0.0.1:2501
>
> smtpd_recipient_restrictions =
> permit_mynetworks
> reject_unauth_destination
> spf_policy
> greylist_policy
> permit
> -------
>
>
> Now my problem is that if I would add an sender/recipient/client ip to one
> of the maps for SPF and return OK as action then the Greylisting policy
> would as well be overstepped. I don't know what I can add as action to not
> overstep the Greylisting policy? I have not tried DUNNO but as far as I
> understand the DUNNO would just continue to evaluate the other maps and at
> the end it would hit the check_policy_service anyway. Right?
>
> I was thinking in maybe adding another restriction class and branch/jump
> there instead of giving an OK. For example:
Right ...
> instead of:
> -------
> /^123\.123\.123\.123$/ OK
> -------
>
> use this here:
> -------
> /^123\.123\.123\.123$/ dunno_policy
> -------
>
>
> and then in main.cf adding dunno_policy to smtpd_restriction_classes and
> adding something like that for the dunno_policy: -------
> dunno_policy =
> check_client_access
> pcre:${config_directory}/lookups/pcre/dunno_policy_client.cf -------
>
> and in dunno_policy_client.cf:
> -------
> /./ DUNNO
> -------
But I don't think this is it. What you want to do is make subclasses
that continue on into your restrictions.
> But I am unsure what happens if I branch/jump from one restriction class to
> another and the other restriction class has just a DUNNO. Will then the
> processing return back to the first restriction class and continue or is
> the whole branching/jumping more or less like a flow of processing without
> returning back there where it was originally called?
DUNNO is going to exit only that one restriction, and continue with the
next specified restriction. It doesn't matter that you came in via a
restriction class; DUNNO is not going to exit the class.
restriction_classes = class_relay_ok, class_helo, class_grey, class_rbl
class_relay_ok = permit_mynetworks, permit_sasl_authenticated
class_helo = check_helo_access pcre:$config_directory/helo,
reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname
class_grey = check_policy_service ...
class_rbl = reject_rbl_client ...
smtpd_recipient_restrictions = class_relay_ok, check_recipient_access
hash:$config_directory/rcpt_restrict, reject_unauth_destination
Add more classes and granularity as desired. Then in the rcpt_restrict
map, call the classes you want, per recipient or per domain.
g...@example.com class_helo, class_grey, class_rbl
nog...@example.com class_helo, class_rbl
wants...@example.com reject_unauth_destination
> Does anyone know the answer? Is that somewhere described in Postfix? Where?
>
> Or does anyone know a better way in handling such a situation/problem?
Not sure. I do know that you will need lots of caffeine and analgesics
as you develop and debug this. And then you'll never want to look at it
again! (Don't ask how I know this!)
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
