Re: [exim] acl_smtp_notquit and acl conditions

Top Page
Delete this message
Reply to this message
Author: Dean Brooks
Date:  
To: exim-users
Subject: Re: [exim] acl_smtp_notquit and acl conditions
On Sat, Oct 06, 2007 at 01:48:45AM +1000, Ted Cooper wrote:
> 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.
>
> 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.


Coindentally, I ran into this same issue in the QUIT acls last week.
In the end, I had to put the logic in-line instead of using nested ACLs.

The real problem here is that the deny/accept clauses are overloaded,
when in fact, nested ACLs should instead have a mechanism to return
a true or false value instead that results in no change to the behavior
of the original calling ACL.

Not sure it's worth the effort to code though.

--
Dean Brooks
dean@???