[Top] [All Lists]

Re: Abort data transfer?

2009-10-19 20:27:35

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 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".



Hector Santos

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