-------- Original-Nachricht --------
> Datum: Tue, 4 Aug 2009 13:01:12 -0500
> Von: "/dev/rob0" <[email protected]>
> An: [email protected]
> Betreff: Re: Question regarding Restriction Classes
> 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.
>
This statement I don't understand. Allow me to rephrase what I have understood
from the above paragraph:
Restrictions are mubmle_restrictions (aka
(smtpd_client|smtpd_helo|smtpd_sender|smtpd_recipient|smtpd_data|smtpd_end_of_data|smtpd_etrn)_restrictions)
What are subclasses? I don't know what that is?
> > 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.
>
So inside a restriction I can have multiple classes called. If in one of the
classes I do an OK then the whole restriction is exited. Right?
If in one of the classes I do a DUNNO then the execution stays inside the class
and continues. Right?
Much like:
RESTRICTION 1: START
CLASS 1: START
COMMAND 1
COMMAND 2
IF ACTION IS OK THEN WHOLE RESTRICTION 1 IS OK
IF ACTION IS DUNNO THEN CONTINUE WITH NEXT COMMAND (3) IN CLASS 1
COMMAND 3
COMMAND 4
CLASS 1: END
CLASS 2: START
COMMAND 1
COMMAND 2
CLASS 2: END
CLASS 3: START
COMMAND 1
IF ACTION IS OK THEN WHOLE RESTRICTION 1 IS OK
IF ACTION IS DUNNO THEN CONTINUE WITH NEXT COMMAND (2) IN CLASS 3
COMMAND 2
COMMAND 3
CLASS 3: END
RESTRICTION 1: END
> 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.
>
> [email protected] class_helo, class_grey, class_rbl
> [email protected] class_helo, class_rbl
> [email protected] reject_unauth_destination
>
Now that is new to me. I did not know that I can call multiple restriction
classes in one statement. I now remember to have read about that some while ago
but I simply have forgotten about it. Thanks! Thank you so much reminding me
about that.
> > 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!)
>
LOL! :)
But I understand now better. Your text above helped me. And I have read now
again more about restriction classes and I think I get it. My viewpoint
changed. I was looking at the whole topic with a "developer" eye but that's
wrong. I see now that the way restriction classes are handled is differently
then I expected. It's more a way of extending the processing by adding blocks
of commands on condition then branching/jumping inside the processing flow.
> --
> Offlist mail to this address is discarded unless
> "/dev/rob0" or "not-spam" is in Subject: header
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
