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
