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.
For example, sending a typical message to 1000 recipients through a 28.8 modem takes only 10 seconds with QMQP.
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.
The client concatenates all these netstrings, encodes the concatenation as a netstring, and sends the result.
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.
Note that QMQP is not a public service. Servers should not accept QMQP connections from unauthorized IP addresses.