On Tue, Jan 02, 2001 at 02:03:01PM +0000, Philip Hazel wrote:
> [Sent to both exim-announce and exim-users. Reply-to set to exim-users.]
This is going to be long and hard. It could be usefull for others on the
list to know this, so I have send it to the list rather than to Philip
himself.
> The file is 60K in size and is in simple HTML (all text, no pictures).
What? No flash enhanced pages with streaming MP3ed sound and MP4ed video?
... sheeeeesh, soon everyone will want linewarp at 80 lines....
> If you are interested in the future technical development of Exim,
> please read this document and send me (or the exim-users list) any
> comments you may have. Even simple remarks such as "I like this idea" or
> "I don't like this idea" will be useful feedback.
Just remember, you asked for it... ;>
> Should I embark on this major re-working or not?
Yes. Definitly. Sometimes it's the only way to make something
better/more efficent. Exim -- while great -- has some issues that could
be fixed and improved.
As for the book being ``partially obsolete'', yes it would. However,
that leaves you with a second edition or/and a new book. Not as good as
a film, but there you go.
Config files can be changed and it's not a big deal to do it --
especially if there is a perl script to do it. However, it depends how
radical you want to make Exim 4. If you remove one of director or router
it will cause major chaos, but will be clearer in the long run. Talking
about that...
> Amalgamating directors and routers
Definitly a good idea. There isn't of a difference there to really make
it worth having two of those.
Router is fine as names go.
I like the idea of having router specific domains. For example, router A
will only be used for the those domains and not others... Of course, one
would need to them do DNS querries even for local_domains. Which is a
good thing (tm) in our case. Domain_list is indeed a great feature.
> New Generic Options
Lowercase_local_part could be usefull... On the other hand,
check_localuser and match_home_directory definitly will be very usefull.
> Changes to conditional running of routers
No comments there. It makes sense.
> Revamping the old directors
Both makes sense as names and features.
Is it worth to have a test in routers as to the existence of a .forward?
An option like forward_file? So instead of having a router for
.forwards, it becomes an option to be added into routers... I can see a
use for that in virtual hosting where you may wish to give only some
domains access to filtering.
Is there a point in creating a third one called `hubb', which would act
as a hubbing option? So, all messages that go via that router are hubbed
(ie forwarded) to some other host.
> Revamping the old routers
No problems there.
> Sample new routing configuration
Where are you getting $home from in userforward? Could this be added per
director?
So something like this:
----------
domain_list cluefull = kierun.org
domain_list luser = losers.com
clue_domains:
driver = domainlist
domains = +cluefull
home = $nhash_10_10{$localpart}
forward = $home/.forward
luser_domains:
driver = domainlist
domains = +luser
home = $nhash_10_10{$localpart}
----------
Comments?
> Saving looked up data with an address
Good idea. However, care has to be used not to oveload the system with
memory caching so that it ends up swaping. No, I don't think it's going
to be that much of an issue, but remember that on some systems, there
are hundreds of exim processes at any time.
> Consequential change to queryprogram
Makes sense.
> Transport changes
Hum... it is always dangerouse to have a transport (esp with filters)
run as root.
The more things are done in parallel, the better IMNSHO.
The rest seems fairly usefull stuff.
> Changes to security features
Could there be an option that Exim *never* runs as root. In the install
script, you have to add a user (a default can be added) that will be
exim's effective priviledged ID?
It shoudn't be too hard to add this into the EDITME file...
Otherwise, all in this section is great.
> Policy rejection features
I think that one should still reject things as soon as they happen. I
know that some MTAs will always be broken, but...
How about adding a IPChain-like feature? So for things like RBL lists,
exim blocks at the packets level and does nothing but cut the
connection. Something similar to what OpenSSH can do. Would that be
usefull?
The relay host is indeed a good idea.
> RBL processing
Oh boy.
All those a great idea.
How about adding an option that will count (in a hint database) how many
messages are delivered by a host to your machine? If these is bigger
than a certain value, then freese or/and bounce those mails as spam.
For example, if a host sends my mail server 1000 emails in 10 mintues, I
want to freese all mails from it. If it sends 10,000 of those in 10
mins, I want to drop all connection from it. Of coruse, a postmaster
will then need to unfreese those mails that are not spam... ;>
This will add something to harm against DOS and the like.
Comments?
> Consolidation of policy rejection features
Statements like things are okay. Everyone who administer a unix systems
has done some coding and knows how that works.
I like this a lot. Much simpler and clearer IMNSHO.
Again, are those default in the main config, or setable per router -- or
both???
I can see Exim moving more and more towards a Object Orianted MTA, where
the objects are ways of delivering emails. Certainly would help me as I
tend to think in OO ways.
Script to change configurations.... hum, now that's a tought one.
Probably is doable. Of course it won't be plug and play. However, I
think this *should* be done anyway. The clarify and ease of use will be
far greater.
> Full mailboxes
Again a hint database maybe usefull? ... if Exim discovers that there is
a full mailbox, right the localpart (whatever) to the full_mbox.*db.
The same thing can be done with nearly full mboxes.
Sure, if you have mboxes mounted on NFS you could have all hints
databases mounted on NFS (ARGH!) or not care if two different machine
don't have the same hints.
> Local code for message scanning
Ick. Don't like that at all. Perl is slow and has much overheads and
cannot be used on large systems.
If you want to do message scanning, then there is filter files and
sepcific other things.
....
> A simple extension to the system filter
Yup, makes sense. Again, more caching means more memory...
> A much more complicated filtering scheme
Simpler scheme definitly. Otherwise, you are effectivly providing two
MTAs rolled into one.
> Deliveries from a system filter
No comments.
> Changes to default runtime configuration
;>
> Proposed abolitions
No worries there.
How about adding something that would more the forzen messages off the
queue and give support for it? ;> Hell, I can code that bit ;>
*caught*
> Autoconf
Best of luck.
> Inter-process communication
Use MPI and have the first MTA that is truly parallel? I love the idea
myself.
Go for it!
> Message freezing
Sure.
> Panics
Paranoia is good when you are delivering customers email and they can
sue you for zillions if you mess up...
> Log level and log options
Sure.
> Debugging
Same as above makes sense.
> Hints databases
Many new things in this... see above.
> Miscellaneous
All this is reasonable.
> Terminology
Ditto.
> Internals
I am intrested... ;> who said I was sane again?
> Documentation
HTML is indeed great and works best.
....
Comments welcome ... anyone but Phil reached here?
I'm off home to bed and try to kick off this cold. So, if something
doesn't make sense: it's cause I'm ill. It's my excuse and I stick to
it!
--
Dr Yann Golanski Senior Developer
Please use PGP: http://www.kierun.org/pgp/key-planet
