Graeme Fowler wrote: > On Fri, 2007-10-05 at 08:15 +0200, Magnus Holmgren wrote: >> Errm. ยง 40.8 says (about the QUIT ACL) that "You do not need to have a final >> accept", and logically the same should apply to the not-QUIT ACL. It's only >> explicit denys that are forbidden (at least by the implementation). And by >> the way, that wasn't even the issue here. > > Hrm... > > I just read, and closed, #608 with the comments that an explicit deny in > the QUIT or not-QUIT ACLs is invalid per the spec. > > Surely calling a child (nested) ACL which returns a deny is the same as > explicitly stating deny? > > Or... thinking about it... in this case, with the child ACL returning an > explicit deny, the statement resolves (in human terms at least!) as: > > accept acl = false > > so any further processing of that ACL section will halt, and it'll drop > to the next part - as none is defined, that hits the implicit deny which > in the case of the QUIT and not-QUIT ACLs is irrelevant anyway, as the > connection has gone away already and no further access control is > possible. > > The interesting part here is that by calling the child ACL from the QUIT > or not-QUIT ACL, should the same rules apply? IMO they should do - so > deny is an invalid verb in the child ACL aswell as the parent ACL for > QUIT and not-QUIT - but this may be argued against by others! > > Maybe #608 needs re-opening. Discuss :)
I added the not quit acl because I needed a hook for logging and other such menial tasks. It was meant for completion - there would be a terminating acl called for every connecting acl. It has no possibility of ever affecting the connection or email in any greater capacity than a warn. An accept just means it will skip all subsequent rules just as well as a deny verb. To this point, the existing situation works perfectly. Nested acl's seem to break horribly though. Normally, they would have 2 results but with the lack of a deny, they are reduced to simple non-returning procedure calls. I believe this is the issue. Since these acls can't affect anything, I don't see why anyone would need such advanced nested acls. The answer or result will always be an effective warn. Any serious processing should really be offloaded to something else like a program/pipe. Essentially I don't see this as a bug or a necessary change to add functionality. Anything you can do in nested acls, you can do in linear ones with a few more conditions. -- The Exim Manual http://www.exim.org/docs.html http://www.exim.org/exim-html-current/doc/html/spec_html/index.html -- ## 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/
