On 2 Jan 2010, at 22:00, Tony Finch wrote: > On Sat, 26 Dec 2009, Sabahattin Gucukoglu wrote: >> As I see it, there is no reason not to pipeline both the message text >> lines and the final dot, because nothing is expected from the server and >> until the dot is received there is no change of state other than the >> accumulation of the DATA buffer. > > You can pipeline more than that. You can send one message per RTT if you > pipeline one message's data with the next message's envelope, i.e. > stream out all of headers, body, dot, RSET, MAIL, RCPT, DATA; then wait > for the server's replies; then repeat. > Sorry, I meant unextended SMTP. I was wanting to know whether, after the 354, I could send multiline data buffers followed by the dot, only single lines, or lines then just the dot. The difference is simply in how much gets put into the send buffer, and the rationale is avoiding silly bugs that can neither be specified nor assumed nonexistent.
> If the server supports the BDAT command then your client's sending and > receiving pipelines can be completely asynchronous. However if you do this > you massively increase the risk of message duplication caused by lost > connections. There's some discussion of this in > http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rfc1845bis.html > However it's probably easier in practice to fix this problem using some > server-side deduplication cleverness without protocol extensions. > This got me thinking on the precise nature of data duplication due to long delays between the final dot of the DATA block and the 250. Given that the 250 is the first send from the server after each client wait, would it not be feasible for the server to treat as undelivered any transaction for which it could not send the final acknowledgment, thus sympathising with the client's view of things? Are there any difficulties, for instance, is there the possibility that the server could send the acknowledgement but it not be delivered in spite of a lack of error from the underlying transport? >> But I also know there are implementations out there which don't like it >> when a command is incomplete, and try to respond to whatever is in their >> TCP buffer, and wondered if anybody knew how that might work for the >> final dot if it were stuffed at the end of some text. > > Such implementations are not allowed to advertise PIPELINING. > > The worst example I have seen recently was a Cisco PIX or ASA with SMTP > fuxup mode turned on. It replaces unrecognized SMTP commands with XXXX, > but if a known command is split between packets it cannot recognize it so > XXXXs it out. (More details at http://fanf.livejournal.com/102206.html). > Perhaps that is what you are thinking of. This is just one of many bugs in > the PIX SMTP implementation. Avoid it at all costs. Sounds terrible! But no, I was talking about *commercial MTAs*, usually for Windows, which if you connect to them with telnet in stream mode will happily disgorge "500 Unrecognised" whenever you send them a character. Yes, they're out there, really! Cheers, Sabahattin
