Bug#272870: /usr/sbin/exim4: exim4-daemon-heavy: More modular structure (integrating other tools)
Jari Aalto
Jari Aalto <jari.aalto@cante.net>, 272870-maintonly@bugs.debian.org
Tue, 08 Feb 2005 19:47:32 +0200
| retitle #272870 module structure for ACLs
| reassign #272870 exim4-config
| thanks
|
| > There are several good checks already and in newsgroups I have
| > found more checks to include to ACL RCPT file. Why not make these
| > all "standard" and ship with Exim. The user can selectively
| > enable those features that he wants.
||
| How about having the RCPT ACL split over different files? This has
| been requested already, and doesn't seem so intrusive to me like your
| suggestion. However, we are probably too late for sarge.
Sure, splitting 30_exim4-config_check_rcpt into separate directory
was the idea's key:
/etc/exim4/conf.d/acl/rcpt/
/etc/exim4/conf.d/acl/data/
| > And /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt is broken
| > into smaller parts, so that it can include several files. Here
| > I have listed some of the possibilities that I use:
| >
| > .include /etc/exim4/conf.d/acl/include/rcpt/helo_mandate
| > .include /etc/exim4/conf.d/acl/include/rcpt/helo_forged
| > .include /etc/exim4/conf.d/acl/include/rcpt/sender_ident
| > .include /etc/exim4/conf.d/acl/include/rcpt/spf_spfquery
| > .include /etc/exim4/conf.d/acl/include/rcpt/dnsbl
| > .include /etc/exim4/conf.d/acl/include/rcpt/sender_verify
| > .include /etc/exim4/conf.d/acl/include/rcpt/greylistd
|
| Why that include orgy when the files could be directly in
| /etc/exim4/conf.d/acl/?
Because I wanted to maintain single file for RCPT checks. Since
there isn't currently that dedicated */acl/rcpt/ directory (See above).
| > And so forth for all other "features". Each external package could
| > install new "feature" into the include directory and suggest user
| > to turn on that feature in /etc/exim4/conf.d/main/20_exim4_features
|
| Each external package could drop their ACL snippet into
| /etc/exim/conf.d/acl.
I'm suggesting to broke the ACLs a little further.
| However, all this won't work too well with the non-split configuration
| which is the default.
I'm not too familiar what problems that could raise, but wouldn't
that be just simple assembling? The .ifdef code activations are just
variables to enable.
It would be better to "wrap" the ACLs inside ifdefs, because then the
files could be dropped in place, ans later activated.
For example I'm in dynamic IP and can't run certain checks, so I do not
enable certain ifdefs, but I leave the code there.
Jari