summaryrefslogtreecommitdiff
path: root/doc/doc-misc/LongTermIssues
diff options
context:
space:
mode:
authorPhilip Hazel <ph10@hermes.cam.ac.uk>2004-10-08 10:38:47 +0000
committerPhilip Hazel <ph10@hermes.cam.ac.uk>2004-10-08 10:38:47 +0000
commite05f33e0b79c14608757a60f2f3f8588008355f7 (patch)
tree0a8dd6eaa4b91c51b6b1b013eeba11ab1cf7dc13 /doc/doc-misc/LongTermIssues
parent495ae4b01f36d0d8bb0e34a1d7263c2b8224aa4a (diff)
Start
Diffstat (limited to 'doc/doc-misc/LongTermIssues')
-rw-r--r--doc/doc-misc/LongTermIssues200
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