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.
> 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. :)
I had a horribly bad headache this very evening, in fact. Just a
coincidence? I doubt it.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
