Sabahattin Gucukoglu wrote:
Wait a minute. You didn't advertise PIPELINING. Do your logs report
the lock-step reads and writes of CRLF-terminated lines from the network, or
would they print the entire buffer content? If the former, there is
the possibility that the client never finishes sending data to you before it
gets a write error, and is thus forced to shut down without completing a mail
transaction (it doesn't realise that it has incorrectly terminated the
transaction). This would not indicate that it wants to send QUIT, only that
it never got a chance to read the 250 response before you killed the
connection.
Hi,
Without knowing the devil details regarding the COMM I/O used by the
client, its all speculation. I lean on the side the client has a read
buffer that has 250 in there waiting to be read just like the IETF
mailer have shown. You would not expect the client in DATA mode
reading the socket while its sending the payload. But its also
plausible that all the 500 responses pushed out the 250 at the top of
the read buffer when it was still sending out text.
No matter what, it was a screwed up transaction to start and I don't
believe its a good idea to correct it by relaxing compliancy or
presume that everything is still ok. When there is irregularities,
accepting and automatically starting a delivery purely based on 250 is
more problematic than not. The message was truncated and if signed, no
longer DKIM valid.
Just consider, if the server option NO-QUIT-CANCEL was disabled (the
log showed its state when the session started), then our server would
of started the delivery process immediately (in the background) after
issuing the 250 and this sender would of still began it additional
resends with what are now dupes.
--
Sincerely
Hector Santos
http://www.santronics.com