D. J. Bernstein
Internet mail
SMTP: Simple Mail Transfer Protocol

The QUIT verb

A QUIT request asks the server to close the connection:

     220 heaven.af.mil ESMTP
     QUIT
     221 heaven.af.mil saying goodbye

QUIT parameters are prohibited. Some servers will reject any QUIT request with a nonempty parameter.

If the server accepts the QUIT request (required code 221), it then closes the connection without reading further requests.

Clients closing connections

RFC 821 recommends that the client send QUIT, and wait for the QUIT response, before closing the connection.

There are a few broken TCP implementations, such as MacTCP 2.0.6, that fail to acknowledge TCP FINs after a local close. If the client is running on such a host, it shouldn't close the connection until it sees the server close the connection; otherwise the server will waste time repeatedly transmitting the FIN until it times out.

Clients will close connections without QUIT in some circumstances, for example because of a crash, or a message I/O error or timeout after DATA. Servers must not throw away messages that they accepted during such connections. (Banyan Vines in 1994 reportedly violated this rule.)

Most implementors agree that QUIT is useless, and support a transition to a world without QUIT. Some servers pester their system administrators when they don't see QUIT; I recommend that they change this behavior. Someday clients will no longer send QUIT. Eventually servers will no longer need to support QUIT.

qmail's SMTP client sends QUIT but does not wait for the QUIT response.

Servers closing connections

RFC 821 recommends that the server not close the connection until it receives a QUIT request and sends the response.

Servers close connections without QUIT in some circumstances, for example because of a crash or timeout. Some servers send an asynchronous response before closing the connection after a timeout. The correct code here is 451, temporarily rejecting the client's next request; some servers incorrectly use 552 or 554, producing sporadic bounces.

Timeouts

The client should not wait forever for a response from the server; the server may have crashed. Similarly, the server should not wait forever for a response from the client.

I use a default timeout of 1200 seconds for each packet. Timeouts below 600 seconds are dangerous in today's Internet. On the other hand, some dumb clients wait only 60 seconds for a greeting.

RFC 1123 suggests different minimum timeouts for different requests, ranging from a 120-second timeout for the DATA response to a 600-second timeout for the response to the message itself. Measurements show that this sort of tweaking does not make a significant difference in average resource consumption.