On Wed, 14 Mar 2001, Oliver Cook wrote:
> I'm having some trouble understanding the way that Exim handles
> ETRN requests, and wonder if some explanation might be forthcoming.
As I say in the manual, and have said elsewhere:
Exim is not designed for storing mail for dialup hosts. It is designed
as a program for delivering mail. It is not designed to be a program
for storing mail for specific hosts.
Of course, people use Exim for things it was never designed for. That is
the fate of all artefacts. However, although you can chisel a piece of
wood with a screwdriver, and bang a screw in with a hammer, it isn't
very pretty.
The -R facility is intended as a tool for the Exim admin. "Oh, I see
that a host that's been down for a while has come back. I'll tell Exim
to deliver the mail for its domain, rather than wait till the next retry
time." This isn't something that happens regularly. Therefore, there is
no point implementing anything very sophisticated. -R just looks for
messages that have at least one recipient that matches, and runs a
delivery process on them. It makes no attempt to deliver *only* those
addresses - it looks at all the recipients of the messages. (It's got
the message open; it might as well take a look at all the recipients.)
> If someone issues an ETRN, it's because they want their mail to
> be delivered. I have some trouble then with this part of the spec:
I think that issue (forcing the first message only) has already been
answered.
> I also have a little niggle about the way smtp_etrn_command is
> handled. The specification explicitly states that the exit
> status of the command is not checked because exim does not wait
> for the command to be complete, but doesn't AFAICS go on to say
> why.
Exim originally did not have ETRN. People kept asking for it, and as I'm
a helpful kind of guy :-) I cobbled something together. The first
attempt just did -R, but later the facility for running an arbitrary
command was added. Perhaps it would have been better just to have the
arbitrary command, since matching the ETRN spec to the -R spec isn't
straightforward. The point is that Exim does not keep messages in queues
per host, so to implement "deliver mail for this *host*" is not
possible. The best it can do is what -R does: "deliver messages
addressed to this *domain*".
I didn't make it wait for the command to complete because a queue run
can take quite a long time - and anyway, the return code from a queue
run is always "success".
> Imagine a situation where you want to put a wrapper, say, around
I take this point, but it could require adding a lot of apparatus for a
facility, which, as I say above, is a bodge in the first place.
> |250 OK, queuing for node <x> started
It can do that. Assuming that "queueing" means "delivering". Actually,
no, it can't. It doesn't have the ability to deliver to a specific host.
> |251 OK, no messages waiting for node <x>
It doesn't know the answer to that.
> |252 OK, pending messages for node <x> started
> |253 OK, <n> pending messages for node <x> started
> |458 Unable to queue messages for node <x>
> |459 Node <x> not allowed: <reason>
Not sure I understand what those mean.
> |500 Syntax Error
> |501 Syntax Error in Parameters
I think Exim supports those. :-)
> Basically the thrust of all this is that if there is to be the option
> to run an external command, there has to be some facility for getting
> information back to the remote mailer from the command and not just send
> back a generic response that might potentially be misleading.
I will consider, for Exim 4, an option that says "wait for the command
and use its stdout as the SMTP response". In this context "consider"
means "take a look at the code and see this is an easy thing to add with
only a few lines of code".
> Oliver Cook Systems Administrator, ClaraNET
If you are seriously into storing mail for dial-in users (which I guess
you might be since you are at clara.net), you should not really be using
-R. You should instead deliver the mail into files on the server, in
BSMTP format, where they can wait off Exim's queue. There was an elegant
sample config published which did this for messages that couldn't be
delivered within n minutes; when the ETRN kicked, the messages were
re-submitted to Exim with -bS. Thus, it avoided having to have another
program to do the final delivery.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
