--On 21 August 2009 18:56:13 +0200 MarkdV <[email protected]> wrote:
> > Ian Eiloart wrote: >> >> --On 20 August 2009 16:32:40 +0100 Jethro R Binks >> <[email protected]> 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/ -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
