On Thu, 24 Jul 2003, Arne Georg Gleditsch wrote:
> 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.
The problem I have with your patch is that it does not do the proper
job, and cannot do the proper job, because of the underlying Exim
design.
> You're right, these are issues I can live with. I realize not
> everyone might want to, though.
Quite.
> 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.
There is a fundamental problem of lack of root privilege at this
stage.
In addition, Exim is not designed as a message store. It expects its
"queue" (which is really a "pool") to be small; it is just transit
storage. It has no mechanisms for efficiently scanning the queue for
specific messages.
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."
> 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.
Once you start building additional mandatory data structures that refer
to the message files, you are into a whole new ball park, because you
have to ensure that the pointers and the files remain in step. This
destroys the current simple design, where the files *are* the queue and
there is nothing extra. I suspect it would also impact performance
because in this kind of design you have to have a central locking point
where you update the data. Exim is specifically designed to avoid these
kinds of centralized bottleneck.
> > 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)?
Delivering messages for disconnected hosts into local files, instead of
leaving them on Exim's queue has the following advantages:
1. It saves Exim scanning the messages in every queue runner. This is
significant if a lot of messages are involved.
2. It makes management easier, because the queue is known to contain
only messages that are having delivery problems (and those that are
currently being delivered). Exim performs better if its queue is
kept small. (cf stuff about large installations and fallback hosts
for long-delayed messages).
3. It means you can put all messages for one offline host into one
directory, thus identifying them easily. You can put a quota on the
directory to manage the size. You can write scripts that scan the
directory and delete too-old messsages - with or without bounces.
4. It splits up the messages so that, if one has multiple recipients,
you end up with just the one recipient in the message that is stored
for the offline host.
> I'll be interested in patching
> this in instead if a good example of such an entity already exists,
I do not know if a suitable entity exists. If not, somebody will have to
write one.
> 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.
Thank you for your confidence, but I worry about those long queues... :-)
> Being able to keep all my MTA configuration within Exim's
> boundaries is also a definate plus for me.
For ETRN, people have managed to do this job using only Exim and some
scripts, because you can re-inject the messages into Exim once the
recipient host is online. This is not possible with TURN.
Sorry to be so negative, but I do feel that the Exim design just won't
bend this much.
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
