Re: [Exim] Planning for Exim 4

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Andromeda
Fecha:  
A: Exim
Asunto: Re: [Exim] Planning for Exim 4
Hello Philip,

I've been watching the debate carefully, and since I'm pretty much happy
with the way Exim works (uncomplicated, simple, straightforward), I wanted
to make sure that I got things right first time round.

I don't know much about the innards of Exim. However, I agree with you that
the routers and directors should be combined, considering that they all do
the same. It is up to the administrator to decide which are outgoing and
which are incoming directors.

I would however like to sit with Yann Golanski and rather call the combined
processing elements "routers". That's just me... but you can do whichever
you think is best.

Yann also mentioned having home as a default option (as he had explained in
his first email). I think this would remove any reliance on /etc/passwd? If
so, that would REALLY help with virtual domains (although the virtual
domain procession currently is so damn easy it's not even funny anymore
*grin*).

As far as transport changes are concerned, I don't know too much about
that. Here it works. Period.

Security features... Hmmmmm... I haven't ever had any problems with exim,
but yes, the questions you ask, and that others have asked, are indeed
valid. I believe Marc Haber and Phil Pennock both mentioned eximd and
modularity.

I stand with Peter Radcliffe and prefer one big executable because it is
less of a security hassle. The safety of the coding is important, it shows
the mindset of the developer (you) and the responsibility you take for your
development (and you've been great).

What use would a modular approach be if you left it up to the individual
administrators to plug security holes? Not much.

Policy rejection... oh boy. I like John Sloan's way of using ACL style
rejections. Does it really matter how the configure file has those listed?
If anything, Exim can parse those ACL statements into one huge ANDed
statement when it is HUPed... Looking at your example earlier:

accept host = 192.168.10.3 :: 10.3.4.0/24 : authenticated
accept host = 192.168.10.3 :: 10.3.4.0/24 : notlisted = dul.maps.vix.com

As you stated, it would be equal to:

  accept_recipient = host = 192.168.10.3 : 10.2.4.0/24   \
                     AND                                 \
                       (                                 \
                       authenticated                     \
                       OR                                \
                       notlisted = dul.mapx.vix.com      \
                       )   



It looks just like a broken-up set of AND and OR instructions? If anything
the proposed ACL syntax would just make administration from OUR standpoint
easier.

I guess it makes your job harder in having to parse and optimize those
instructions, but looking at the syntax it is not that much more difficult.
In that light I think it would be best if users of Exim (administrators)
were to list all ACCEPTs first, and then the DENY's?

As far as message scanning is concerned... I think those kind of things
should stay OUT of Exim. Pass the message on to a program to scan it, and
reinject it into the queue to be processed again.

It wouldn't make a huge difference, would it? If all the routers are set
correctly, the messages should skip right through (after all, it is a
message from the localhost, to the localhost). System filters. Yes... those
are very useful. Stick to message scanning in here... (see above.

As for the documentation, I have been accessing za.exim.org a lot lately in
an effort to fix some things. So, documentation should stay HTML. It's the
fastest, simplest, and best :)

With Regards

Andromeda


- The Andromeda HTML Workshop - http://www.htmlworkshop.com/
Home of Search & Replace 98