Tony Finch wrote:
Murray S. Kucherawy <msk(_at_)cloudmark(_dot_)com> wrote:
I don't think it clearly indicates that. I think this is more plausible:
Or this:
- client sends DATA
- server sends 354
- client starts sending a broken message body that contains an errant
<CR><LF>.<CR><LF> plus more after it
- server sees the termination, starts message delivery and returns 250
- server starts seeing the other message content as SMTP commands, rejecting
them all with 5xx
- server drops the connection
- client sees the connection drop while still trying to write message data
- client aborts the transaction and retries later
Tony.
Digging further on who dropped the connection, well the logged 10054
socket error is a "remote forced closed" error. To double check, my
particular setup did not have a limit set on 500 responses issued. It
would of logged the disconnection if a limit was set:
DWORD nCode = 500;
nCommandErrors++;
if (MaxCommandErrors && (nCommandErrors > MaxCommandErrors)) {
Send("%3d '%s': command not understood. (error count: %d)
Disconnecting!\r\n",
nCode, cmdline,nCommandErrors);
Control->Close();
return;
}
Send("%3d '%s': command not understood.\r\n", nCode,cmdline);
But MaxCommandError was set at zero and the server was no dropping the
line.
Since the client dropped the line (10054 was the real clue here), it
makes it more speculative as to why it dropped it without knowing its
comm I/O logic.
I mean, SMTP does not have any design consideration or expectation for
a client in a DATA state to be reading a socket during its pumping out
the data. In other words, short of a drop, there is no official
method to abort a data exchange.
But I can also see an implementation who uses this non-expectation and
assume that its reader buffer must remain quiet (empty) and it may
have "sanity check" just to make sure. If there is information on its
reader buffer while it loop pumps out its DATA payload, I can see this
being used an an unofficial method of an ABORT and hence it drops the
line. I guess, one can use the theory that a client should not expect
any application level noise coming from the receiver during its DATA pump.
One thing we do know, it was all FUBAR and IMV, how liberal we should
be on accepting non-compliancy such as this makes things more complex,
more problematic than not. The Mail was no longer valid in terms of
incomplete capture. It wasn't a good transaction. Passing this junk to
users is not a good idea, IMV.
--
Sincerely
Hector Santos
http://www.santronics.com