On Mon, 11 Aug 2008, Paul Smith wrote:
As far as I can make out Tony was just asking for clarification. I may have
missed where he said there was a problem with a particular behaviour. He seems
to have been happy with Glenn, Ned, Frank, mine, et al's interpretation, just
thought it needed clarifying to prevent any possible compatibility issues.
Right, though the original question was about a different problem to the
one that Hector is aguing about.
I believe that Hector's view is contradicted by the spec, as follows:
Read section 2.3.6 which describes the buffers maintained by the server.
Read section 4.1.1.3 which says that the RCPT command adds a recipient to
the forward path buffer. (This text is in RFC 821 and 2821bis though it
was accidentally omitted from RFC 2821.)
Read section 4.2.1 on the theory of reply codes, which says that a 4yz
reply means "The command was not accepted, and the requested action did
not occur." i.e. in the case of RCPT the recipient was not added to the
forward-path buffer.
Therefore any subsequent replies (to DATA or <CRLF>.<CRLF>) from the
server cannot relate to any RCPT commands that got 4yz or 5yz replies
because the server did not store the recipients in its buffer and
therefore cannot take them into account when deciding what subsequent
replies to give.
I think this analysis also goes some way to explaining why the problem
client that stared this thread is wrong: a 4yz to RCPT says that adding
one recipient to the buffer failed, not that the whole transaction failed.
There's evidently still some scope for making this more obvious, but I'm
less convinced that there's an enormous gap in *821 that needs to be
filled. If this argument does turn into a document I think it should be
just an informative readers guide rather than a standards-track
clarification.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
FAIR ISLE: CYCLONIC 5 TO 7 BECOMING EASTERLY 4 OR 5. MODERATE OR ROUGH. RAIN
OR SHOWERS. MODERATE OR GOOD.