-------- Original-Nachricht -------- > Datum: Tue, 4 Aug 2009 23:57:41 -0500 > Von: "/dev/rob0" <r...@gmx.co.uk> > An: postfix-users@postfix.org > Betreff: Re: Question regarding Restriction Classes
> On Tuesday 04 August 2009 13:51:31 Steve wrote: > > > 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? > > A restriction is something that can be put in smtpd_*_restrictions. > > smtpd_*_restrictions themselves are each "estriction stages". > > "Subclass" is not a Postfix term. I was using it to mean "subdivide > your restriction classes into smaller classes." And I think you got > that part. > Yes. I got it now. The commands inside a restriction class are acting like a macro processor/template. Whatever you do inside the restriction classes is what then is conditionally added into those smtpd_*_restrictions where you called the restriction class. > > 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. > > Indeed, while restriction classes can make smtpd(8) restrictions akin > to a programming language, they do lack branching and jumping features. > But my simplified approach is a workaround that should ensure that the > aspirin bottle never strays too far from your desk. :) > Aspirin does not help much over here. I need stronger stuff. Unfortunately. Anyway... your mail helped me so much that in fact I changed my whole setup yesterday and guess what? It works! It's not that hard anymore. Once I figured the mechanism how restriction classes work it was just a task of typing the commands and glue everything together. In the past I got some of my older restriction classes to do what they where supposed to do but somewhere after doing the first simple ones I mixed up how restriction classes work and expected to much from them. But now I am back to earth and understand for what they are and how they are supposed to work. They are somehow limited but hey! The Postfix documentation never mentioned anything about complex conditions, branching, jumping etc. It was my own interpretation/imagination which was the problem. > I had a horribly bad headache this very evening, in fact. Just a > coincidence? I doubt it. > You write that sentence in the past so I assume the headache is gone? Thats good :) Again: THANK you so much! You helped me to get out of the own digged hole and take one step back and look with different eyes on the whole issue. Thanks! > -- > 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
