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 <[EMAIL PROTECTED]> http://dotat.at/ FAIR ISLE: CYCLONIC 5 TO 7 BECOMING EASTERLY 4 OR 5. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.
