On 26/12/04 02:17 -0500, der Mouse wrote:
The message headers and body are part of the message itself, as
part as SMTP is concerned.
Sure, but that doesn't mean that the connection can't be dropped
DURING the body transfer.
See the RFCs. It does mean exactly that.
Well, it doesn't *mean* that, exactly.
I'm not sure which RFC specifies that the server is not permitted to
drop the connection if it feels like it, if indeed there is such a
specification (I can't recall one offhand, but I'm willing to
tentatively believe that there is one). However, the client must be
prepared to handle it if it happens; servers do crash.
RFC 0821
Page 25, description of the quit command:
The receiver should not close the transmission channel until
it receives and replies to a QUIT command (even if there was
an error). The sender should not close the transmission
channel until it send a QUIT command and receives the reply
(even if there was an error response to a previous command).
If the connection is closed prematurely the receiver should
act as if a RSET command had been received (canceling any
pending transaction, but not undoing any previously
completed transaction), the sender should act as if the
command or transaction in progress had received a temporary
error (4xx).
RFC 2821 clarifies (section 4.1.1.10):
The receiver MUST NOT intentionally close the transmission channel
until it receives and replies to a QUIT command (even if there was an
error). The sender MUST NOT intentionally close the transmission
channel until it sends a QUIT command and SHOULD wait until it
receives the reply (even if there was an error response to a previous
command). If the connection is closed prematurely due to violations
of the above or system or network failure, the server MUST cancel any
pending transaction, but not undo any previously completed
transaction, and generally MUST act as if the command or transaction
in progress had received a temporary error (i.e., a 4yz response).
It also seems like no less reasonable a thing to do than a lot of the
other things that are done when dealing with spam and associated
issues, including a number that violate the RFCs (such as non-relay
hosts dissecting message headers, or my own "half-open hell" tactic for
dealing with hosts that retry too fast).
However, this would play hell with hosts that play by the rules (ISP
outbound relay servers, for example, which need not be the same as their
submission servers).
Devdas Bhagat
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg