Bug#838098: Allow hooking ACL condition blocks similarly to routers, transports and other settings

[Rimas Kudelis]

Package: exim4-config
Version: 4.87-3

Since Exim4 requires each ACL to be specified by name, and exim4-config 
ships some ACL's, it becomes a bit difficult for external packages to 
add to these ACL's. One option is to specify one of the 
CHECK_*_LOCAL_ACL_FILE macros, but ideally, this would be reserved for 
the user to set, and either way, if more than one package would define 
this, it would either break the configuration or lead to unexpected 
results (only one package's file being read).

What's even worse is that for example CHECK_RCPT_LOCAL_ACL_FILE is being 
read after the following statements:

   # Insist that any other recipient address that we accept is either in 
one of
   # our local domains, or is in a domain for which we explicitly allow
   # relaying. Any other domain is rejected as being unacceptable for 
relaying.
   require
     message = relay not permitted
     domains = +local_domains : +relay_to_domains


   # We also require all accepted addresses to be verifiable. This check 
will
   # do local part verification for local domains, but only check the domain
   # for remote domains.
   require
     verify = recipient


which makes it impossible to use add alternative accept rules before 
these ones.

I suggest to implement ACL's in the same fashion as other parts of the 
configuration. In particular, I'd like to see default ACL's split into 
multiple number-prefixed files, one of them being the header, and others 
containing one or more condition blocks. This way other packages could 
add their own files with their conditions easily, instead of having to 
patch the configuration files shipped by another package (which is what 
greylistd package does, to the best of my understanding). This would 
also allow packages to specify their own accept rules, without altering 
+local_domains or +relay_to_domains.

Exim 4 also allows having quite a few more ACL's than Debian currently 
ships. I think it makes sense to ship all of these by default, even if 
empty, so that other packages wouldn't have to specify them, thus being 
in risk of conflict with other packages doing that as well.