Commit | Line | Data |
---|---|---|
e05f33e0 PH |
1 | Exim Long Term Issues |
2 | --------------------- | |
3 | ||
4 | I restarted this list from scratch for Exim 4. I amalgamated it with another | |
5 | list when creating the CVS repository (October 2004). But it still probably | |
6 | needs a substantial spring clean. Some of it is very old now. | |
7 | ||
8 | ||
9 | AUTOCONF | |
10 | -------- | |
11 | ||
12 | Somebody once tried to \(autoconf)\ Exim, but found it too big a job. I now | |
13 | have some experience with using \(autoconf)\ for PCRE, and I think maybe some | |
14 | use could be made of it. I don't, however, believe that \(all)\ Exim build-time | |
15 | configuration should be done that way. The reason is that, unlike something | |
16 | like PCRE, there is quite a lot of information that is "user choice". Giving it | |
17 | all as options to a \(configure)\ command does not seem the best way of doing | |
18 | things. | |
19 | ||
20 | Whenever I build something that needs more than a couple of obvious options to | |
21 | \(configure)\, I always save them in a file anyway, so I know what I did for | |
22 | next time. Therefore, I think it is sensible to retain the current Local file | |
23 | structure for all the user choice configuration. | |
24 | ||
25 | However, it might be helpful to use \(autoconf)\ to dig out various bits of | |
26 | information about the operating system. At present, the \(OS/Makefile-*)\ files | |
27 | have hard-wired settings, and maybe this information could be figured out by | |
28 | running \(autoconf)\, which would save having to keep maintaining these files. | |
29 | ||
30 | I would arrange things so that \(configure)\ is run automatically the first | |
31 | time that \(make)\ is run, but it would be possible to run it manually first, | |
32 | to override defaults. (For example, if you have both \(cc)\ and \(gcc)\ | |
33 | installed on your system, as I do, you need to be able to specify which to | |
34 | use.) I will need to do some experiments to see exactly how this would work. | |
35 | ||
36 | ||
37 | EXIMON and other utilities | |
38 | -------------------------- | |
39 | ||
40 | . Consider optionally making it possible to link with something other than | |
41 | Athena widgets - for example, gtk. Or indeed re-write the whole thing! | |
42 | ||
43 | ||
44 | GENERAL | |
45 | ------- | |
46 | ||
47 | . Convert os.c into a directory of separate functions, with the macro | |
48 | switches defined elsewhere. Then make it into a library. | |
49 | ||
50 | . Use a pointer to an address structure for expanding $domain etc, to make it | |
51 | easier to save/restore this collection of variables. But note that $domain | |
52 | and $local_part aren't always in an address. Check out when these are set. | |
53 | Note also the new $address_data possibility. | |
54 | ||
55 | . Spool_in and spool_out - speed up by using a table? | |
56 | ||
57 | . Find a more compact way of encoding the options interpretation, and also of | |
58 | checking for incompatible options. | |
59 | ||
60 | . Find a more compact way of passing an open SMTP channel without having | |
61 | to use options. What about the TLS state information? Could use a pipe to | |
62 | pass more data. | |
63 | ||
64 | . Some people have suggested separately loadable modules. But do all systems | |
65 | have them? Is this going too far for just a few specialist users? In | |
66 | particular, people want to be able to replace the logging with his own code. | |
67 | Can we arrange this without going for the separately loaded modules? (cf the | |
68 | incoming checking code.) | |
69 | ||
70 | . SIGHUP the daemon - don't close the sockets; instead pass a list of them | |
71 | somewhere for the new daemon to pick up. Iff started by exim or root, of | |
72 | course. There might be quite a long list of them - argv might not be the best | |
73 | idea. If this were done, then a non-setuid exim daemon could be SIGHUPped. | |
74 | ||
75 | . Parallel deliveries. Currently dead host information doesn't get propagated | |
76 | between them very well. Is there anyway this could be improved? | |
77 | ||
78 | . In some environments the use of gethostbyname() seems to cause problems. | |
79 | Check out its use, and see if having a "force DNS" option could be helpful. | |
80 | But people would have to know what they were doing. | |
81 | ||
82 | . accept_max_per_host is a slow, linear search. If smtp_accept_max is large, | |
83 | this can be very slow. Is there some way we can speed this up? Some kind of | |
84 | index based on the IP address? Remember, this is in the daemon, so it must | |
85 | not consume store. | |
86 | ||
87 | . Change the names of all the pcre_ stuff to, say, PCRE_ so that Exim can be | |
88 | linked with libraries or whatever that also use an external PCRE library. | |
89 | ||
90 | . Look at code in pidentd for running Exim in wait mode from inetd and re-using | |
91 | the socket. This would allow it to run more tidily as non-root. | |
92 | ||
93 | . Think up some scheme for checking for orphan files in the spool directories. | |
94 | Perhaps -bp should always do it, but it would be nice to have it done | |
95 | automatically now and again. Maybe we just leave this for a cron job? Perhaps | |
96 | a new -bx, e.g. -bpck or something. Better, perhaps, is a separate Perl | |
97 | script. Orphan = a file that is over 24h old (or 1s when test harness) and | |
98 | either doesn't end in -D or -H, or is a -D without a matching -H (or vice | |
99 | versa). | |
100 | ||
101 | . Make set_process_info buffer bigger, and put the overflowed message at the | |
102 | end, thereby leaving the start. | |
103 | ||
104 | . Swamping with delays in checking for reserved hosts - the connections are | |
105 | counted in the total allowed. Can we improve on this somehow? Maybe shared | |
106 | memory can help here. Think about different states and different limits. | |
107 | ||
108 | . Lists that must use colons: can we check for other cases, and fix them up | |
109 | before passing them on? Is it worth it? | |
110 | ||
111 | . Linux for S/390 - create configuration? | |
112 | ||
113 | . Process receiving error message fails - can we get more info, such as the | |
114 | stdout/stderr? | |
115 | ||
116 | . dbmbuild - if renaming one of .dir/.pag fails, reinstate the other. Should | |
117 | there be a lock? | |
118 | ||
119 | . Write a script to check for format problems in the source - formats that are | |
120 | not fixed strings and are built from outside code. | |
121 | ||
122 | . freeze_tell: Don't if message is a bounce message containing From: the local | |
123 | machine - even if the bounce comes from another host. | |
124 | ||
125 | . Add additional data into the "frozen" log message at end of delivery, e.g. if | |
126 | remote host was the local host or whatever. At least some cross referencing. | |
127 | ||
128 | . Someone had a requirement to install the Exim binary in a different place to | |
129 | the utilities, etc. Also, for different builds on the same host and | |
130 | architecture. | |
131 | ||
132 | . Include (part of?) the ppid in the message id? Or a random number? | |
133 | ||
134 | . Re-implement the code in readconf that reads error names for retry rules. | |
135 | Make it use a table for most of the error types. Then see if we can usefully | |
136 | add any additional error types. | |
137 | ||
138 | . Should there be "exim -bP acls" etc? It would mean inventing some kind of | |
139 | "hide" facility within the ACL syntax. | |
140 | ||
141 | . VERY LONG TERM: the message ID is too small now, with the recent changes to | |
142 | cram in the sub-second time. It would be a big project to extend it; Exim | |
143 | would have to recognize both forms for a while, and become stable, before | |
144 | generating the new form. Probably a runtime switch needed. The new form needs | |
145 | at least microsecond time (or more?) and should probably cope with 64-bit | |
146 | pids, just to be safe (or leave expansion space that could be used for that). | |
147 | It should also be able to hold big enough things in base 36. | |
148 | ||
149 | . Take a look at libexec. | |
150 | ||
151 | . Sort out the stcncpy/strlcpy issue once and for all. Time things. | |
152 | ||
153 | . Error in transport filter. See test 407. All 3 processes see errors - which | |
154 | one should be noticed? Transport_filter_temp_errors may be needed. | |
155 | ||
156 | . Think about 5xx thresholds -- too many and you're out. What about 4xx? | |
157 | ||
158 | . autoreply - should it call /usr/sbin/sendmail? Provide a way of not passing | |
159 | -C and -D when creating the message ('cause it won't be privileged). | |
160 | ||
161 | . Strings containing \000 - anything we can do? | |
162 | ||
163 | . OpenSSL - can we pass an opened file for certificate? Repeatedly? | |
164 | Otherwise pre-initialize while root? There do seem to be functions for | |
165 | manipulating certificates, but documentation is scarce. Can we just load the | |
166 | certificate in as root in the server? | |
167 | ||
168 | . Consider using poll() to close unwanted fds. Is this efficient? Perhaps it | |
169 | doesn't matter for the daemon. | |
170 | ||
171 | . On a 64-bit system there are some cast warnings for casting addresses to | |
172 | ints. Either we must find a way of not warning, or we'll have to use unions | |
173 | to get round it. | |
174 | ||
175 | . Run splint on the source? | |
176 | ||
177 | . It has been suggested that rejection because not authenticated should use | |
178 | 530 and not 550, but this is hard to detect because of the way ACLs work. | |
179 | ||
180 | . When there is a sender verify failure, $acl_verify_message contains "sender | |
181 | verify failed", not the details of the failure. Should this change? Some of | |
182 | the waffly details are added later in smtp_in.c. In the ACL that text is in | |
183 | sender_verified_failed->user_message. | |
184 | ||
185 | . An empty string for a transport filter currently causes an error. Should it | |
186 | ignore? Tricky because of special expansion rules for commands. | |
187 | ||
188 | . GFDL for documentation (www.gnu.org/licenses/fdl.html)? The 1.2 version of | |
189 | this licence is still quite new (it is dated November 2002) so I think | |
190 | waiting for reaction/opinion is the best plan. There are Debian concerns | |
191 | about this licence. At very least, no Invariant Sections and no Cover Texts | |
192 | can be used. | |
193 | ||
194 | . Allow $recipients in other places. Not clear what this value should be if, | |
195 | say, the system filter has overridden them. Default would be envelope | |
196 | recipients, as now. | |
197 | ||
198 | End |