QMQP: Quick Mail Queueing Protocol

What is QMQP designed to do?

QMQP provides a centralized mail queue within a cluster of hosts.

One central server runs a message transfer agent. The other hosts do not have their own mail queues; they give each new message to the central server through QMQP.

Note that QMQP is not designed for mail injection from dumb clients that are unable to build complete messages and envelopes. A QMQP server shouldn't even have to glance at incoming messages; its only job is to queue them and relay them to the outside world.

Why a new protocol? Why not use SMTP?

SMTP is painfully slow over high-latency connections, such as modem connections. Like QMTP, QMQP is much faster than SMTP, saving time and money for users. QMQP is also much easier to implement than SMTP.

For example, sending a typical message to 1000 recipients through a 28.8 modem takes only 10 seconds with QMQP.

How does a QMQP session work?

A QMQP client connects to a QMQP server through a reliable two-way 8-bit stream.

The client sends a mail message, an envelope sender address, and a list of one or more envelope recipient addresses. The server then sends back a response and closes the connection.

The server is not permitted to send its response until the client has sent the final byte of the recipient list. The client is permitted to close the connection before sending the final byte of the recipient list; in this case, the server must throw away the message without attempting to deliver it.

The server is permitted to close the connection at any time, although high-quality servers will try to send a response first. Any response not received by the client indicates a temporary failure.

A QMQP session should take at most 1 hour. Both sides are expected to close the connection after this time.

What exactly does the client send?

The client starts with a safe 8-bit text message. It encodes the message as the byte string firstline\012secondline\012...\012lastline. (The last line is usually, but not necessarily, empty.) The client then encodes this byte string as a netstring. The client also encodes the envelope sender address as a netstring, and encodes each envelope recipient address as a netstring.

The client concatenates all these netstrings, encodes the concatenation as a netstring, and sends the result.

What exactly does the server send?

The server's response is a nonempty string of 8-bit bytes, encoded as a netstring.

The first byte of the string is either K, Z, or D. K means that the message has been accepted for delivery to all envelope recipients. This is morally equivalent to the 250 response to DATA in SMTP; it is subject to the reliability requirements of RFC 1123, section 5.3.3. Z means temporary failure; the client should try again later. D means permanent failure.

Note that there is only one response for the entire message; the server cannot accept some recipients while rejecting others.

The remaining bytes are a description of what happened. It is expected that the description, when interpreted as UTF-8 characters, will be readable English text, and will not include formatting characters other than \040. However, these expectations are not requirements, and the client must be ready for arbitrary bytes from the server.

Descriptions beginning with \040 are reserved for future extensions. In descriptions not beginning with \040, the byte \043 must not appear except in HCMSSC codes.

A server must not accept a message unless it can store the message without corruption. Acceptance means that the server is accepting responsibility to deliver the message to the envelope recipient. Deletion of nulls is not permissible; a server that deletes nulls must reject any message containing nulls. Folding of long lines and high-bit stripping are also not permissible.

Is there a TCP port for QMQP?

QMQP may be used directly on top of TCP. A QMQP-over-TCP server listens for TCP connections on port 628.

Note that QMQP is not a public service. Servers should not accept QMQP connections from unauthorized IP addresses.