Re: [Exim] Planning for Exim 4

Top Pagina
Delete this message
Reply to this message
Auteur: Vadim Vygonets
Datum:  
Aan: exim-users
Onderwerp: Re: [Exim] Planning for Exim 4
Quoth Philip Hazel on Tue, Jan 02, 2001:
> For some time I have been promising a document that discusses some
> proposed major changes to Exim. The time has come to make the first
> version of the documment available for comment.


And here it is, as promised. I'm kinda late, and most things
seem to be discussed to death.

| Amalgamating directors and routers


Nice. I would also like to propose multiple router lists for
different sets of domains, ending with "break" (to stop router
processing and reject message if all routers failed) or
"continue" or "fallthrough" (to continue router processing).
Something like this:

<-----
begin routers +virtual_domains
thingie:
blah
continue

begin routers +local_domains
system_aliases:
blah
forwardfile:
blah
localuser:
blah
break

begin routers *
smtp:
blah
break
end
----->

It just seems more efficient and more intuitive in terms of
grouping routers according to their destination domains. And to
change domains for whole groups of routers you'll just need to
edit the definition of the group in one place.

The domain definition may be made to accept only previously
defined domain lists (thus forcing the admin to define a list
before the router group) or to accept full domain lists with
database lookups.

The break vs. continue (fallthrough) distinction may come handly
in some cases. However, if only "continue" is implemented then
the '*' group (remote domains, usually) will have to list all
previous groups negated (like "!+local_domains :
!+virtual_domains : *"), and if only "break" is implemented,
routers meant for two groups (like in the above example) will
have to include previous groups with "domains =" directives.

Nested groups should not be implemented.

| Revamping the old directors


In redirect router, match_directory from today's forwardfile
director should probably be eliminated and replaced with a test
like "condition = ${if{matches{$home}{/group}}{yeah}}" when
needed. But there will be lots of coments like this, I'm afraid.

Maybe multiple addresses (lists of addresses from aliasfile and
smartuser) should be made optional. But then, maybe not.

forbid_special should be extended to affect all of redirect
router (including today's smartuser).

| Transport changes

|
| Is the require_lockfile option of appendfile, which can be unset
| to make it try to create a lock file but not complain if it can't,
| actually useful? This goes back a long way; it doesn't seem to me
| to be of much use.


It should go, IMO.

| Consolidation of policy rejection features


"authenticated" should probably take a parameter specifying valid
IDs to allow different people do different things based on the ID
they authenticated with. I.e., from a connection coming from
outside the office, sysadmins can send mail anywhere, users can
send mail only to local domains, and middle management can only
send mail between themselves, other mail from middle management
gets redirected to /dev/null without error message, after erasing
the relevant logs ;)

Oh, and ACLs are the way to go.

| sender_verify_fixup


Should die, yes. Why fix other people's mistakes?

| Local code for message scanning


I'm not sure about it. Surely not the second way.

| Deliveries from a system filter


one_time should be the default IMO.

| Proposed abolitions


| never_users


Should stay. We want to sleep well at nights. Despite the fact
that we have very noisy disks in our rooms ;)

| The errors_address option has `decayed' over time. It seems that
| it is now used only for freeze_tell_mailmaster messages and for
| bounces caused by -Mg applied to a bounce message. In the latter
| case, I think we can just discard the bounce, and treat -Mg as
| -Mrm.


Well... Sounds about right. Yes, I agree.

| The X rewriting flag


No idea.

| Autoconf


For changing a compiler, you can always compile or configure
using a command like:

% env CC=cc CFLAGS=-O2 make

| Inter-process communication


I'm not sure which OSes don't have semaphores. But on OSes which
don't, this may be implemented using pipes (but then you can hit
maximum file descriptor limit).

| Debugging


Symbolic names were proposed, and I'm all for it.

| Miscellaneous


| A relic from very early days is the existence of patch space at.
| the end of the default values for the configuration file
| name, Exim's path, log_file_path, pid_file_path,
| received_header_text, smtp_banner, and spool_directory.


cs.huji.ac.il uses it, although the changed values are shorter
than the original ones.

| ignore_errmsg_errors_after


The default value should be names "-1" or "never" or some other
out-of-bound word, meaning "after default retry time". There
should be another option to send the failed error message to the
Postmaster after the retry time specified by this option.

| default message size limit


Should probably exist. But messages are large these days, with
lusers sending each other jokes in raw DVD format.

=== Feature request

Spammers these days use programs that just send all of the SMTP
dialogue in one big write(), without waiting for the server to
respond. Maybe Exim should have an option (defaulting to true)
to check whether any input on SMTP connection is available (using
select(2) with zero timeout) before sending each response, and
drop the connection IMMEDIATELY if there are bytes to read.
After all, RFC 821 says:

# The dialog is purposely
# lock-step, one-at-a-time.

This could be implemented easily in less than ten lines of code.
Should I volunteer?

Vadik.

-- 
Strange Fruit.  A brilliant way to describe
somebody hanging from a tree...
    -- Marcus Miller