diff options
author | Philip Hazel <ph10@hermes.cam.ac.uk> | 2004-10-08 10:38:47 +0000 |
---|---|---|
committer | Philip Hazel <ph10@hermes.cam.ac.uk> | 2004-10-08 10:38:47 +0000 |
commit | e05f33e0b79c14608757a60f2f3f8588008355f7 (patch) | |
tree | 0a8dd6eaa4b91c51b6b1b013eeba11ab1cf7dc13 /doc/doc-misc/LongTermIssues | |
parent | 495ae4b01f36d0d8bb0e34a1d7263c2b8224aa4a (diff) |
Start
Diffstat (limited to 'doc/doc-misc/LongTermIssues')
-rw-r--r-- | doc/doc-misc/LongTermIssues | 200 |
1 files changed, 200 insertions, 0 deletions
diff --git a/doc/doc-misc/LongTermIssues b/doc/doc-misc/LongTermIssues new file mode 100644 index 000000000..808ba3f8c --- /dev/null +++ b/doc/doc-misc/LongTermIssues @@ -0,0 +1,200 @@ +$Cambridge: exim/doc/doc-misc/LongTermIssues,v 1.1 2004/10/08 10:38:47 ph10 Exp $ + +Exim Long Term Issues +--------------------- + +I restarted this list from scratch for Exim 4. I amalgamated it with another +list when creating the CVS repository (October 2004). But it still probably +needs a substantial spring clean. Some of it is very old now. + + +AUTOCONF +-------- + +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. I don't, however, believe that \(all)\ Exim build-time +configuration should be done that way. The reason is that, unlike something +like PCRE, there is quite a lot of information that is "user choice". Giving it +all as options to a \(configure)\ command does not seem the best way of doing +things. + +Whenever I build something that needs more than a couple of obvious options to +\(configure)\, I always save them in a file anyway, so I know what I did for +next time. Therefore, I think it is sensible to retain the current Local file +structure for all the user choice configuration. + +However, it might be helpful to use \(autoconf)\ to dig out various bits of +information about the operating system. At present, the \(OS/Makefile-*)\ files +have hard-wired settings, and maybe this information could be figured out by +running \(autoconf)\, which would save having to keep maintaining these files. + +I would arrange things so that \(configure)\ is run automatically the first +time that \(make)\ is run, but it would be possible to run it manually first, +to override defaults. (For example, if you have both \(cc)\ and \(gcc)\ +installed on your system, as I do, you need to be able to specify which to +use.) I will need to do some experiments to see exactly how this would work. + + +EXIMON and other utilities +-------------------------- + +. Consider optionally making it possible to link with something other than + Athena widgets - for example, gtk. Or indeed re-write the whole thing! + + +GENERAL +------- + +. Convert os.c into a directory of separate functions, with the macro + switches defined elsewhere. Then make it into a library. + +. Use a pointer to an address structure for expanding $domain etc, to make it + easier to save/restore this collection of variables. But note that $domain + and $local_part aren't always in an address. Check out when these are set. + Note also the new $address_data possibility. + +. Spool_in and spool_out - speed up by using a table? + +. Find a more compact way of encoding the options interpretation, and also of + checking for incompatible options. + +. Find a more compact way of passing an open SMTP channel without having + to use options. What about the TLS state information? Could use a pipe to + pass more data. + +. Some people have suggested separately loadable modules. But do all systems + have them? Is this going too far for just a few specialist users? In + particular, people want to be able to replace the logging with his own code. + Can we arrange this without going for the separately loaded modules? (cf the + incoming checking code.) + +. SIGHUP the daemon - don't close the sockets; instead pass a list of them + somewhere for the new daemon to pick up. Iff started by exim or root, of + course. There might be quite a long list of them - argv might not be the best + idea. If this were done, then a non-setuid exim daemon could be SIGHUPped. + +. Parallel deliveries. Currently dead host information doesn't get propagated + between them very well. Is there anyway this could be improved? + +. In some environments the use of gethostbyname() seems to cause problems. + Check out its use, and see if having a "force DNS" option could be helpful. + But people would have to know what they were doing. + +. accept_max_per_host is a slow, linear search. If smtp_accept_max is large, + this can be very slow. Is there some way we can speed this up? Some kind of + index based on the IP address? Remember, this is in the daemon, so it must + not consume store. + +. Change the names of all the pcre_ stuff to, say, PCRE_ so that Exim can be + linked with libraries or whatever that also use an external PCRE library. + +. Look at code in pidentd for running Exim in wait mode from inetd and re-using + the socket. This would allow it to run more tidily as non-root. + +. Think up some scheme for checking for orphan files in the spool directories. + Perhaps -bp should always do it, but it would be nice to have it done + automatically now and again. Maybe we just leave this for a cron job? Perhaps + a new -bx, e.g. -bpck or something. Better, perhaps, is a separate Perl + script. Orphan = a file that is over 24h old (or 1s when test harness) and + either doesn't end in -D or -H, or is a -D without a matching -H (or vice + versa). + +. Make set_process_info buffer bigger, and put the overflowed message at the + end, thereby leaving the start. + +. Swamping with delays in checking for reserved hosts - the connections are + counted in the total allowed. Can we improve on this somehow? Maybe shared + memory can help here. Think about different states and different limits. + +. Lists that must use colons: can we check for other cases, and fix them up + before passing them on? Is it worth it? + +. Linux for S/390 - create configuration? + +. Process receiving error message fails - can we get more info, such as the + stdout/stderr? + +. dbmbuild - if renaming one of .dir/.pag fails, reinstate the other. Should + there be a lock? + +. Write a script to check for format problems in the source - formats that are + not fixed strings and are built from outside code. + +. freeze_tell: Don't if message is a bounce message containing From: the local + machine - even if the bounce comes from another host. + +. Add additional data into the "frozen" log message at end of delivery, e.g. if + remote host was the local host or whatever. At least some cross referencing. + +. Someone had a requirement to install the Exim binary in a different place to + the utilities, etc. Also, for different builds on the same host and + architecture. + +. Include (part of?) the ppid in the message id? Or a random number? + +. Re-implement the code in readconf that reads error names for retry rules. + Make it use a table for most of the error types. Then see if we can usefully + add any additional error types. + +. Should there be "exim -bP acls" etc? It would mean inventing some kind of + "hide" facility within the ACL syntax. + +. VERY LONG TERM: the message ID is too small now, with the recent changes to + cram in the sub-second time. It would be a big project to extend it; Exim + would have to recognize both forms for a while, and become stable, before + generating the new form. Probably a runtime switch needed. The new form needs + at least microsecond time (or more?) and should probably cope with 64-bit + pids, just to be safe (or leave expansion space that could be used for that). + It should also be able to hold big enough things in base 36. + +. Take a look at libexec. + +. Sort out the stcncpy/strlcpy issue once and for all. Time things. + +. Error in transport filter. See test 407. All 3 processes see errors - which + one should be noticed? Transport_filter_temp_errors may be needed. + +. Think about 5xx thresholds -- too many and you're out. What about 4xx? + +. autoreply - should it call /usr/sbin/sendmail? Provide a way of not passing + -C and -D when creating the message ('cause it won't be privileged). + +. Strings containing \000 - anything we can do? + +. OpenSSL - can we pass an opened file for certificate? Repeatedly? + Otherwise pre-initialize while root? There do seem to be functions for + manipulating certificates, but documentation is scarce. Can we just load the + certificate in as root in the server? + +. Consider using poll() to close unwanted fds. Is this efficient? Perhaps it + doesn't matter for the daemon. + +. On a 64-bit system there are some cast warnings for casting addresses to + ints. Either we must find a way of not warning, or we'll have to use unions + to get round it. + +. Run splint on the source? + +. It has been suggested that rejection because not authenticated should use + 530 and not 550, but this is hard to detect because of the way ACLs work. + +. When there is a sender verify failure, $acl_verify_message contains "sender + verify failed", not the details of the failure. Should this change? Some of + the waffly details are added later in smtp_in.c. In the ACL that text is in + sender_verified_failed->user_message. + +. An empty string for a transport filter currently causes an error. Should it + ignore? Tricky because of special expansion rules for commands. + +. GFDL for documentation (www.gnu.org/licenses/fdl.html)? The 1.2 version of + this licence is still quite new (it is dated November 2002) so I think + waiting for reaction/opinion is the best plan. There are Debian concerns + about this licence. At very least, no Invariant Sections and no Cover Texts + can be used. + +. Allow $recipients in other places. Not clear what this value should be if, + say, the system filter has overridden them. Default would be envelope + recipients, as now. + +End |