On Mon, 13 Dec 2010, Jethro R Binks wrote: > I'm sure Philip has passed commentary on this situation in the past.
I probably have. When I first started to write Exim, I did try to design it as a number of separate binaries, but the problem that made me change my mind was the difficulty of passing information between them. Also, I realized that the "receive message" code needed to have the "deliver message" code available (or quite a lot of it) so that it could apply recipient checks at SMTP time. So having it all in one binary made sense. (Another issue that I thought about was "how do you update a *set* of binaries instantly?" but of course that is easily solved by sticking them all in one directory and updating a symbolic link to the directory.) Having said that, I readily confess that I was probably too naive about security issues at that time, not having had very much experience. There is evidence for that in the way things changed between Exim 0.00 and later releases, as I learned more (e.g. don't use seteuid()). Also, I knew only the basics about processes, pipes, shared memory, etc., that is, stuff that could help with passing information around. (Until 1990 I had been an IBM mainframe person.) Copying what Smail (and indeed Sendmail) did rather than trying to be innovative (and perhaps screwing up spectacularly) seemed a safer bet. On Mon, 13 Dec 2010, David Woodhouse wrote: > It would be an interesting exercise to see how much we could reduce what > Exim does as root when setting up for a delivery run. If we could get to > the point where it doesn't need to interpret the config at all, but is > handed everything it needs for that specific delivery 'on a plate', then > that might be interesting. Although of course if you pass it information > by some other means you still have the question of why it should *trust* > what it's being told... That's basically what I couldn't see how to do (see my 1st para above). While I'm here... I must say, I've been impressed by the way people have leapt in and worked on the security issue in the last week. Nice work! Philip -- Philip Hazel -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
