* Philip Hazel
> I'm afraid I'm not convinced that this is something worth pursuing
> in Exim, as it seems to be of very minority use. Of course, I may be
> wrong there. Perhaps the advent of AUTH will cause a rise in
> demand...
One of the wonderful things about Exim in my eyes is that the power of
its configuration language makes it possible to use it for _extremely_
specialized cases. In line with this, I'd hope to persuade you to
make it possible to target this minority case as well, at least as
long as the ramifications for the code base are equally minor in terms
of complexity and size.
> Even so, there is a problem with implementing TURN in Exim. The problem
> is that it doesn't store queues of messages on a per-host basis. When
> your patch calls queue_run(), it will try to deliver all messages that
> have at least one undelivered recipient that matches the selection
> string that you set up - in this case, the domain - and it will try to
> deliver all recipients, not just the one you want.
>
> Why is this a problem? A brief look at your patch suggests that it does
> cope with deliveries to other hosts (by making a new connection).
> Nevertheless, the problems are as follows:
>
> 0. (Meta problem, discussed in book and manual): Exim is not designed to
> have long queues of messages that are "intentionally waiting". It
> doesn't even have a queue - just a pool of messages awaiting
> delivery, and assumed to be waiting because of some real problem.
>
> 1. When Exim is receiving a message, it is running as "exim", not as
> root. The process cannot regain root privilege. If you start a queue
> run, and thence a delivery process from that state, you may hit
> permission problems. And, should it happen that the message has some
> uncompleted local deliveries (delayed because of quota problems, for
> instance), those deliveries will fail. These issues are discussed in
> section 47.2 "Running Exim without privilege".
>
> OK, you may be in a situation where you can tolerate the
> restrictions, but I don't think this is the right way to go in
> general.
>
> 2. If there are other remote deliveries to be done for the message, they
> may take a long time. This may delay Exim in responding to the
> existing TCP/IP connection, which is not good.
You're right, these are issues I can live with. I realize not
everyone might want to, though. It seems to me that most of your
issues might be resolved by enabling the queue runner to pass the
selection string to the delivery process, which sounds doable to me.
We're still stuck with the fact that Exim does not really maintain a
queue of messages, but this is more of a performance issue, isn't it?
It is also one that I can imagine being resolved in general at a later
stage by adding a journal of some sort for the selection string
mechanism to select messages from.
> Server: If Exim had the ability to accept an ATRN command and then
> simply invoke an external program, passing the SMTP stream on stdin
> and stdout and the authenticated id as a parameter, that would do
> the job nicely.
This is just part of the solution, is it not? What entity will be
responsible for actually delivering the messages (and notifying the
sender if noone picks them up, etc)? I'll be interested in patching
this in instead if a good example of such an entity already exists,
but at the same time I find a substantial deal of comfort in knowing
that Exim maintains responsibility for the messages while they're on
hold. Being able to keep all my MTA configuration within Exim's
boundaries is also a definate plus for me.
Arne.
