--On 21 August 2009 18:56:13 +0200 MarkdV <markdv.exim@???> wrote:
>
> Ian Eiloart wrote:
>>
>> --On 20 August 2009 16:32:40 +0100 Jethro R Binks
>> <jethro.binks@???> wrote:
>>
>>> On Thu, 20 Aug 2009, Todd Lyons wrote:
>>>
>>>> Why is it an accept? That whole endpass thing just never really made
>>>> a whole lot of sense to me. Every time I have a case where I need to
>>>> use it, I have to study the docs and figure it out step by step. It's
>>>> not a natural thought process, and for some reason the knowledge
>>>> doesn't stick around after I've implemented it. I'll just assume that
>>>> I'm getting old and just can't remember crap anymore...
>>> If it's any consolution, I made similar grumbles to PH a few years ago
>>> about endpass, I always struggled to get my head around it, and like
>>> you, had to keep re-reading the docs. He didn't disagree that it was
>>> non-intuitive and awkward. :)
>>
>> so, according to the docs, endpass can only be used in an accept
>> statement.
>>
>> accept condition a
>> condition b
>> endpass
>> condition c
>> condition d
>>
>> will either accept, deny or pass. It'll accept if all conditions are
>> true. It'll pass if a or b are false. It'll deny if a and b are true,
>> but c or d are false.
>>
>>
>> a and b !(a and b)
>> c or d true: accept pass
>> c or d false: deny pass
>
> No, that first one should be c _and_ d true. You said it yourself, "if
> _all_ conditions are true".
quite right, it should be. Or. "! (c or d false)"
>
>> I think it's equivalent to nesting, like this:
>> accept condition a
>> condition b
>> deny
>> ! condition c
>> ! condition d
>
> So, no... More like:
>
> accept condition a
> condition b
> require
> condition c
> condition d
No, because "require c, d" passes when c or d are false. "deny !c, !d"
denies when c or d are false.
>> a and b !(a and b)
>> c or d true: accept pass
>> c or d false: deny pass
similarly here, that first line should start "! (c or d false)"
>> is that true? if so, it might be a neater, and more general solution, to
>> allow nesting of statements like this. Some additional syntax would be
>> required to distinguish a nested statement from a following statement.
>
> IMHO, I would not call it nesting so much as making-up-your-mind as to
> what the statement should do.
It should do what accept...endpass does. The problem is not the behaviour
of endpass, but the poor self-documentation that results from the lack of
clarity in meaning.
>> Perhaps, like this:
>>
>> accept condition a
>> condition b
>> but deny
>> ! condition c
>> ! condition d
>>
>> This would be simpler on two counts. First, the nesting could be used in
>> any statement, not just "accept". Second, it would avoid the mental
>> contortions involved in remembering that the alternative verb changes
>> after endpass - with my syntax, the implicit alternative verb is the
>> verb of the outer statement.
>
> Could you give some examples of how how that would work using other
> statements (and combinations) besides this alternative to what we already
> have? I'm a little afraid that the you'll only create more/worse "metal
> contortions" to go through.
>
>>
>> Of course, this could be confused with the existing nesting mechanism,
>> which allows conditions like "acl = ...". When an acl nested like that
>> returns "deny", it's simply causes the current statement to pass. So, I
>> might be proposing an unholy mess here.
>
> I think the "acl = .." mechanism already makes up for the otherwise
> somewhat lacking flexibility of "flow-control" in ACLs. If anything,
> perhaps I'd like the possibility to specify the acl in-line rather then
> having to refer to a named one. Perhaps make a condition out of it,
> allowing either a named or in-line acl. Like:
Well, you can't do what endpass does with "acl = ...", so you can't replace
endpass with anything there.
> condition = ${acl:named_acl}
>
> or in-line as:
>
> condition = ${acl:
> accept
> condition...
>
> deny
> condition..
>
> defer
> etc...
> }
>
> Oh yeah, and lets make the parser smart enough to just ignore line-breaks
> in places where it could just count braces to figure out where the
> statement ends. I find having to tack "\" all over the place somewhat
> negates the attempt to make stuff more readable by splitting it over
> multiple lines. But I digress...
>
>> A simpler solution, requiring less coding but more social engineering
>> (education). Just remember that endpass means "but deny if". Perhaps a
>> synonymous keyword "butdenyif" could deprecate "endpass"?
>
> Think that would be better named "but deny _unless_ (also)"...
>
> Having said all that, I think endpass really isn't all that hard to get
> your head around. Granted, the word "endpass" is _anything_ _but_
> intuitive, once you learn to think about what it actually does in some
> other terms then it's not all that hard to remember.
>
> accept
> [pre-conditions]
> endpass
> [post-conditions]
>
> What works for me is to just think of it as:
>
> if( pre-conditions ) {
> if( post-conditions ) {
> return accept;
> } else {
> return deny;
> }
>
> In exim-ACL terms it is just a shorthand for the sequence:
>
> accept
> [pre-conditions]
> [post-conditions]
>
> deny
> [pre-conditions]
>
> And it should probably just be used as such. i.e. Never start out trying
> to use endpass. Only use it as a shorthand when you find yourself having
> written a sequence like that.
>
> Oh, just one thing, I did not bother to check if the endpass and "long
> version" are equivalent when you have conditions that can return "defer"
> (like e.g. callout verification or dns lookups). YMMV.
>
> Cheers,
> Mark.
>
> P.S. Or at least I think so... But my understanding of "endpass" has been
> wrong plenty of times before too. :S
Which is exactly why some alternative is desirable!
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see
http://www.sussex.ac.uk/its/help/
