On Wed, 23 Jul 2003, Arne Georg Gleditsch wrote:
> Due to requirements beyond my control at a site where I'd like to
> install Exim I've taken a shot at implementing TURN support in Exim
> 4.20.
Thanks for the patch, but:
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...
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.
I think a better way to add TURN (and ATRN) support is the one that was
already suggested, and is on the Wish List:
------------------------------------------------------------------------------
(48) 21-May-02 M Support for ATRN (server and client)
Brian Candler
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.
Client: We need a variant of 'exim -bs' which would connect to a specified
host, send AUTH/ATRN, and then accept incoming messages as usual.
------------------------------------------------------------------------------
This avoids all the problems, and also gets waiting messages off Exim's
queue (which was never designed for this use).
Regards,
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
