----- Original Message -----
From: "Paul Smith" <paul(_at_)pscs(_dot_)co(_dot_)uk>
Hector, I'm not really disagreeing with you here as I think the choice of
intermediate reply code is pretty academic - either the client will try to
interpret it, in which case a 1yz response code might give an 'unexpected'
error (eg if the client is hard coded to expect a 2, 4, or 5 as the first
digit after a DATA command - which is acceptable based on the standard),
and a 4yz and 5yz might cause a premature failure (hence my choice of
2yz),
or the client will ignore it, in which case it doesn't matter what it was.
Right.
The description of the 1yz reply you quote above is for that being the
FINAL reply code. It's not a 'please wait' response, it's a 'please
confirm
what to do' response. (Note the "The SMTP client should send another
command specifying whether to continue or abort the action." sentence).
Right, we have no 'please wait' concept. But issued as "continuation reply
code" there is no instructon to the client to issue another response.
No doubt, it is kludgy. But it works :-)
Really, the issue is, do the intermediate reply codes need to be the same
as the final reply code (from my reading of 2821, this could be said to be
implied by the examples, but it's certainly not explicit), and, in the
case
where they are different, which one do you use (from my reading of 2821,
you should use the last one).
Yes, that is an issue to discuss, and in my view, we need to not make it a
requirement for situations where the final response code has yet to be
determined. We need to allow for another intermediate reply code. For
backward compatibility, it will only work with as a continuation line.
I think clarification in RFC 2821 bis is what is needed.
No doubt.
BTW, the only solution to the 'keepalive' problem that I can think of
other
than having varying reply codes is for the server to receive the message
the first time, reply with 450- until it decides whether to accept it or
not, then reply '450 ' to temporarily reject the message, but record
identifying details about the message (message id, envelope details, etc),
then wait until the sender tries to re-send it and then accept it straight
away. (This method also sort of merges the idea of 'grey listing', so
might
be even better at stopping spam). However, the obvious drawback is that
every message has to be sent twice - which isn't good, but I can't see any
other way to do it.
Good point. I would rather avoid double transactions.
On a related not, one point which I intentionally left out, is you or in
general, the hook writer. :-)
Of course, the devil is in the details, but if we begin down the path, it
can not become an open invitation for a "take your sweet time" server
design. Hook writers need to optimize their hook just as well, to minimize
all delays to the utmost with the ideal goal of reaching SMTP TIMEOUT
boundaries.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com