[Top] [All Lists]

Re: Mail Data termination

2011-08-18 07:43:49

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


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;
    if (MaxCommandErrors && (nCommandErrors > MaxCommandErrors)) {
Send("%3d '%s': command not understood. (error count: %d) Disconnecting!\r\n",
             nCode, cmdline,nCommandErrors);
    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.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>