Hello,
Having read all the responses regarding the Exim 4 proposal over the weekend,
and not understanding some of them!, I guess 'tis my turn :-)
Rather than saying what I agree with or disagree with, I'd say I agree with
it all but note the exceptions below. Some things - queryprogram, batch
SMTP, etc - are not used by us and therefore should not affect us. With other
things I am trying to be devils advocate and just trying to avoid problems
and think of worst cases :-) Overall I can see advantages in reducing the
number of options to things, the combining of directors and routers, and a
more generic access policy (the ACL system). I would, therefore, say it is a
project worth doing.
Here goes...
> There comes a time in the life of every program when it needs a good spring
> clean.
>
I would add that the same is true for 'exim configuration' :-) We have now
had 2 major configuration changes at the Uni. over about 3 years. Generally
we settle on something then add/modify/fiddle/tweak it as new features come
along. Every so often a 'spring clean' is required. The Xmas break just gone
was the last one we did :-)
> Should I embark on this major re-working or not?
>
Doubts already eh? :-)
> (But the book I am currently trying to finish would be partially obsolete.)
>
A shame, but these things happen. As already pointed out though, this is the
perfect reason for a second edition :-)
> Upgrading to the proposed 4.0 release will require changes of configuration
> file, but I will provide a Perl script for converting 3.x configurations
> into 4.x configurations,
>
From what I've seen already, and all the combinations of things we Exim users
have contrived I think the perl script could be 'interesting' :-) Good luck
:-)
> Amalgamating directors and routers
>
This has been on the cards for some time, and I think it is something 'you'
want to do (perhaps an aesthetic feeling that the code would be 'better'
:-)) As you say the two are pretty close already, so I doubt there would be
much of a problem. I'd say go for it.
> There is a lot of duplication in the code, and it also seems quite hard to
> explain the distinction to new Exim users.
>
Yes, this has cropped up on the mailing list several times. Oddly, I don't
think it was the 'distinction' that eluded me, but simply each
directors/routers configuration, or trying to follow an emails path along the
'directors trail' :-)
No problem with using the generic name of 'routers' for the old 'directors
and routers'. There again I see no problem with 'directors' either...:-)
> This defines a `private' domain list with the name xyz_domains. Such lists
> can be referred to in other domain lists by giving their name, preceded by
> a + sign.
>
Can I ask why a plus-sign - that is, why is there a need for anything?
Macros use an upper-case letter to start with, could this not again be used?
> Up to 32 `private' domain lists can be defined.
>
I know others have mentioned about this hard limit. I would only question it
*if* any future development being considered may have an impact requiring the
use of many private domain lists. For our site 32 should not be a problem.
> The accept_recipient option contains a list of items which are alternative
> conditions for accepting the RCPT command. However, we need to have an
> `and' facility as well as an `or' facility, and the ability to determine
> the priorities of `and' and `or'. I propose to use the words AND and OR,
> and parentheses. This means that the syntax of this list is a bit different
> to other lists. Colons might still appear within the indivitual condition
> items. For example, a list of hosts that are allowed to relay might be
> specified.
>
I cannot really add anything new to what has already been said. One the one
hand I like a 'logical' approach to things with AND's and OR's, but I
immediately started to wonder about some of our more complex conditions. I
have briefly dealt with Apache's configuration file and its ACL's and had no
problem. In that respect I would go with the majority and suggest using
ACL's. I would also consider keeping the somewhat generic name of 'ACL'
rather than trying to invent something new - in itself this may confuse
newbies :-)
> different term - this would also get away from `rbl' as well, which is
> after all only one of these lists. We need something like notlisted.
>
Or 'notblacklisted' (or 'notbl' for short)? Not listed refers to something
not being in a list, but we have many lists (of users, addresses, etc).
notblacklisted specifies that they are not on a 'black list' list. Take it
or leave it :-)
> Something like /warn will also be needed to implement what the current
> sender_try_verify option does.
>
And receiver_try_verify I assume. What about the '+allow_unknown' feature?
Is that going to be a problem?
> Is this getting over complicated?
>
Yes. But I think the subject matter is complicated and you will end up with
a complicated solution regardless of what method/format you use. For simple
scenarios the solutions should be easy enough - and the default Exim
configure file starts off easy enough. It is with more complex scenarios that
I can see things (possibly/probably) getting complicated. However, they are
complicated already (at our site) and we have managed to deal with it! :-)
Secondly, devising a solution to a more complex scenario simply (?) requires
more thought - I done it once so I guess I can do it again :-)
> Just abolish sender_verify_fixup. How many sites actually make serious
> use of this facility?
>
We don't, but it has come up before on the mailing list. Hence I would say
that it is used. 'seriously' or not I could not say.
> Question: Is this new scheme for policy controls the right way to go?
>
Seems to be, there seems to be a lot of favour for it all.
> Will it all be easier in the end?
>
I would say it will be 'no less complicated' :-) Yes, it looks easier (famous
last words of course!).
> Will I be able to write a script to convert old configuration files to this
> new format?
>
I doubt it. Sorry, but you asked :-) I think there are too many combinations
of things possible. You may be able to right a script to handle some of the
'easier stuff' - whatever that may be, but ultimately I think it will be for
the site admin/postmaster/whoever to deal with the conversion process.
Personally I would be doing that anyway.
> There has been some discussion on the list about ways of incorporating
> local code into Exim to handle message scanning.
>
As others have said, Exim is an MTA and not a virus scanner. I agree with
this. However, if you want to provide hooks for others who do want to use
this, then I see no problem with that.
> never_users is a paranoid trigger guard to avoid running local
> deliveries as root.
>
Again, I agree with others that I would rather have this paranoia present :-)
> Somebody once tried to autoconf Exim, but found it too big a job. I now
> have some experience with using autoconf for PCRE, and I think maybe some
> use could be made of it.
>
Nice if you can do this, but I have no problems with the current build
process.
> Semaphores could be used to implement serialize_hosts and
> smtp_etrn_serialize without having to use a hints file. Not only is this
> likely to be more efficient, it avoids the problem of data being left
> around after a system reboot.
>
Again, nice if you can do it, but its not really a hassle to remove old data
prior to starting Exim at boot time (via the startup script).
> If the major policy checking restructuring goes ahead, we will have
> lost the tag rbl_ in any options. It therefore seems sensible to
> rename variables as well, so as to remove the specific name.
> $rbl_domain would become $blacklist_domain and $rbl_text would become
> $blacklist_text.
>
See my comments above about using the 'notblacklisted' keyword :-) This would
tie in nicely, would it not, with your suggestions here.
> From the comments people make, it is clear that the HTML documentation is
> used in preference to the other formats a lot of the time.
>
I've only used the texinfo and html versions once or twice. Personally I use
a hardcopy of the manual from the postscript (but that's because of the
way I work) :-)
-------------
Additional point:
Re: Comments regarding using a monlithic program and security
Well one of the reasons we rejected using qmail was *because* of all the
small programs it had floating around :-) I see no problem with Exim as it
stands.
---------------------------------
That's it,
John.
------------------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: jhorne@???
PGP key available from public key servers
