[Exim] Re: [Exim-Announce] Planning for Exim 4

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Marc Haber
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: [Exim] Re: [Exim-Announce] Planning for Exim 4
Here are my comments:

I really like the idea of having routers only. This will make it
_much_ easier for people to understand exim.

Will a domain_list specification allow to specify a regexp?

|Up to 32 `private' domain lists can be defined.

Please make this a macro to increase at compile time.

I also support the idea of getting rid of old terminology
("aliasfile") in favor of more understandability. We'd need a
documentation section dealing with this, though, to make switching to
exim easier for people familiar with old terminology.

I feel that exim being a monolithic setuid binary is a major risk.
Even if there is no exploit, the mere chance of exim being vulnerable
this way is a big argument that is heavily used by qmail and postfix
advocates. But probably changing this into a small, control process
running as root and doing work in non-setuid binaries that are only
invoked with user privileges would be too big a change.

I am pretty indifferent about the new RBL syntax - both old and new
scheme are complicated and probably hard to understand. But, since RBL
is not necessary to get running and exim provides excellent debugging
aids, it is fine to work with. However, I would probably be confused
by having the RBL option in infix notation ("a AND b") while
conditions in routers are still in the prefix notation (which is even
more byzantine to me because exim is the only tool that I use on a
daily basis that uses prefix notation - my HP calculator being one of
the rare examples for postfix notation in my daily life).

Since all "my" servers don't enforce mail quotas (only thing we do is
occasionally sending mail to accounts that are over quota asking the
customer to delete their e-mail from the account), I don't care about
the quota option as well.

The message scanning code is of course a big issue for me. I feel
pretty comfortable with the idea of the C function, as long as "glue
code" to interface with other languages like perl, python or even ugly
shell comes with the exim release. It would be a nice idea to have a
documented and stable interface to read the message being filtered
from a file, since the message usually is already in the queue while
it is being scanned.

While I used to be a strong advocate of a possibility to interfere
with the message's context, I now consider it a breach of principles:
An MTA should keep its hands out of the message's body. If I can
cancel a message's delivery without anybody noticing from a system
filter in order to re-inject the modified message at the top, I am
fine with this. However, I am not opposed against adding this
capability because someone else might need it. Since it offers a
novice admin pretty much chance to shoot herself in the foot, this
might be a good candidate to be disabled by default, needing
compile-time configuration to be enabled. Tampering with a message's
contents in transit will break cryptographic signatures which I expect
to be a major point against doing so in the quite near future.

Please keep never_users, I feel comfortable to feel sure that even the
most blatant misconfiguration doesn't cause exim to touch mail spool
as root as long as root is in "there".

local_domains_include_host_literals is a security message making sure
that - for example - ORBS open relay warnings get though in any case.
I once had my main smarthost in ORBS for two weeks before noticing
because my exim rejected the warning sent to postmaster@[IP]. Forcing
users to explicitly list the literal in local_domains (which will BTW
be history in exim 4 ;), but I know what you want to say) makes using
the same config file for multiple hosts harder.

errors_copy is used much at smaller sites (for example on single-user
linux systems) or when the admin is not yet comfortable with exim. It
can go, but I suggest the docs showing an unseen router (which is a
pretty advanced feature not handled easily by the novice) doing this.

I agree to your comments about the autoconf thing.

The log level facility would need to be a little more user friendly,
for example by having constants that refer to bit masks and having
exim support bitwise operations like AND and OR in the config file.

Same thing would probably go for the debugging options, while I would
love to see some values that you think useful together with example
output in the docs. Otherwise, I already imagine myself and probably a
lot of other users defaulting to exim -d65535 instead of -d9.

I would like to conclude this length message - again - with thanks to
you for providing a great tool that has until now saved me from
learning sendmail.cf or from hassling with DJB's licenses. Please
continue this great work.

Do you already have the ISBN for your exim book so I can place a
pre-order asap?

Greetings
Marc

-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber          |   " Questions are the         | Mailadresse im Header
Karlsruhe, Germany  |     Beginning of Wisdom "     | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29