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.
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.
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.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.