* Philip Hazel
> Any attempt to implement TURN or ATRN directly inside Exim just has to
> be a bodge. I also know that if the specification says
>
> "Exim supports TURN, subject to these very special conditions and
> restrictions.",
>
> people will take that to mean "Exim supports TURN." Then there will
> be complains, criticisms, etc that "Exim claims to support TURN but it
> does a really bad job of it."
My patch supports TURN in a satisfactory manner for me. Even so I
would like to base my deployed solutions on something I know will be
maintained upstream. The hassle of doing so myself, by keeping an
add-on patch in step with upstream code, is not tempting. So, let me
try a different angle. If I had:
* A transport (option to appendfile) that enabled delivering to
directories containing files on the standard Exim-queue format.
* A command-line option to runq to tell it to use stdin/stdout for
delivering messages.
* Acl-s for turn/atrn and an option for specifying an external
command to run upon accepting TURN/ATRN from a client.
I believe I would be able to implement a solution using Exim all the
way and still, I hope, address many of your concerns. Would a patch
implementing something like this be acceptable to you? (The last
point should match the existing ATRN-item on the wishlist, so I
suppose that one's fairly uncontroversial.)
Arne.
