I'm having some trouble understanding the way that Exim handles
ETRN requests, and wonder if some explanation might be forthcoming.
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:
|Once a message is selected, all its addresses are processed. For
|the first selected message, Exim always overrides any retry
|information and forces a delivery attempt for each undelivered
|address. If the <flags> contain `f' or `ff' then this forcing
|applies to all selected messages, not just the first.
What is special about delivering the first message, and not any
subsequent ones if their retry times have not been reached? And
why even look at the retry times? My understanding has been that
upon issuing an ETRN the remote mailer expects Exim to deliver
all messages for the relevant domain. It may have been offline
for a while and now wants to have its messages delivered in
their entirity.
RFC1985's introduction states:
|If any messages are at the server for the client, then the server
|create a new SMTP session and send the messages at that time.
^^^^^^^^^^^^
which seems to me to be pretty clear-cut. Would it be too bold
to suggest that the -R option should cause exim to ignore any
hints that are held about retry times, and to scrap the 'ff'
option. 'f' would still need to be kept for frozen messages though.
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.
Imagine a situation where you want to put a wrapper, say, around
exim -R to prevent some joker doing an "ETRN #com", or to limit
the number of identical ETRN commands received from a specific
IP in a time period (smtp_etrn_serialize goes some way to doing
this, but doesn't help if the queue runs finish quickly, but the
remote mailer keeps hammering away with the ETRNs). The wrapper
would pretty quickly be able to return a status code, which exim
might be able to interpret; the wrapper could even go so far as
to generate the entire SMTP reply on stdout ("501 ETRN argument too
unspecific" or "45x Too many concurrent requests from ...."). The
only reason I can think of for not waiting for smtp_etrn_command
to finish, is if it is assumed that that command itself is going
to process the queue, and might take some time over it. However,
this might not necessarily be the case. The wrapper, in this
example, might then call exim -R to run in the background and
return a status for Exim to report back to the remote mailer.
This would be more in keeping with 'full-compliance' with RFC1985.
(I put it in quotes because exim _does_ honor RFC1985, but doesn't
offer all the functionality laid out in it):
|Since the processing of the queues may take an indeterminate amount
|of time, this command should return immediately with a response to
|the client host.
|250 OK, queuing for node <x> started
|251 OK, no messages waiting for node <x>
|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>
|500 Syntax Error
|501 Syntax Error in Parameters
If one is to write a wrapper currently thati behaves as above, and
for whatever reason decides not to process the queue run, exim
will still return 250 OK to the remote mailer, which while not
a contravention of RFC1985:
|At the moment, there is no requirement that a connection must occur,
|or that the connection must occur within a given time frame. This
|should be noted in the case where there are no messages for the
|client host at the server host and only the 250 response is used.
... does seem to be a bit misleading, especially since:
|The 250 response code does not indicate that messages will be sent to
|the system in question, just that the queue has been started and some
|action will occur. ^^^^^^^^^^^^^^^^^^^^^^^^^^
Obviously, at the moment exim doesn't know that the queue run isn't
going to be started by the wrapper, so is in fact doing the "right thing"
far as it is concerned.
Another potentially good mechanism might be similar to what
Typhoon News uses for authentication. When it starts up it starts
x number of 'newsauth' processes which listen on stdin. Typhoon
sends username/password combinations to newsauth in turn, which then
returns a "200 OK" or "500 Authentication Failed" style reply code to
Typhoon on stdout. Could something similar to this be plausible?
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 hope that at least some of the above makes sense to other people; it
makes sense to me, but I don't think that's a valid criterion to judge it
on!
Regards,
Ollie
--
Oliver Cook Systems Administrator, ClaraNET
ollie@??? 020 7903 3000 ext. 291
