Isn't it sufficient to note SMTP is a single channel client/server
state machine protocol? Clients send commands, Servers respond.
Server signals are not part of the SMTP client/server framework.
Server Connection Drops are not expected by clients.
In 3.8, it includes an implicit response for such unexpected drops.
SMTP clients that experience a connection close, reset, or other
communications failure due to circumstances not under their control
(in violation of the intent of this specification but sometimes
unavoidable) SHOULD, to maintain the robustness of the mail system,
treat the mail transaction as if a 451 response had been received
and act accordingly.
Clients are expected to end the session with QUIT.
But in principle, for client/server designs, the clients initiates the
commands, servers respond.
--
SM wrote:
At 08:03 19-10-2009, David MacQuigg wrote:
Forget about DKIM. What if there is some other reason to abort, like
the payload is too large? We cannot just continue receiving data
forever. Is there a "permissible" way within SMTP to abort during
data, or should I just ignore these ambiguous requirements, and
either: 1) Send a TCP reset, or 2) Let the transmitter hang.
Arnt mentioned the RFC for for SMTP Service Extension for message size
declaration. You can send a TCP reset to abort the connection. The
SMTP client will retry delivery. If you want to say "payload too
large", you'll need to send a 552 code before you get to the DATA phase.
Section 4.5.3.1.7 of RFC 5321 discusses about the maximum total length
of a message content. There isn't a permissible way within SMTP to
abort during DATA. It's a "don't do it unless you know what you are
doing".
Regards,
-sm
--
Sincerely
Hector Santos
http://www.santronics.com