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".
> 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
> a and b !(a and b)
> c or d true: accept pass
> c or d false: deny pass
>
> 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.
> 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:
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
