The IM2000 Recipient Notification Agent Query Protocol

The Recipient Notification Agent Query Protocol is the means by which recipient MUAs communicate with recipient notification agents. It shares a common structure and common transport layer requirements with the other IM2000 protocols.

Individual to RNAQP are:

• The PDU definitions
• The security considerations
• The individual transactions

With RNAQP, the client is the recipient MUA, and the server is the recipient notification agent.

PDU definitions

RNAQP is subject to the common IM2000 PDU rules.

The response that an RNAQP server must send to a client in the event of a parsing error or a non-command PDU is a ResponseNull PDU comprising

• an ErrorMalformedPDU status and
• the forceabort flag set to TRUE.

The response that an RNAQP server must send to a client in the event of a timeout is a ResponseNull PDU comprising

• an ErrorCommandTimeout status and
• the forceabort flag set to TRUE.

This is the ASN.1 definition of RNAQP.

Security considerations

RNAQP is designed for two basic security models with respect to the communications path. It is designed to make brute force attacks against the authentication mechanism harder. It is designed to prevent recipients from reading any but their own message notifications.

Security with a trusted communications path

The entire communications path between client and server may be under the control of either the recipient or the recipient notification agent owner. This would be the case if, for example, the recipient notification agent is owned by an ISP, the RNAQP service of the recipient notification agent is on the ISP's own network, and the recipient MUA is running on a machine connected to the ISP's network.

The same security considerations apply here as for POP3 in the same situation:

• The protocol is client-driven; and is designed such that authentication data, envelope data, and message data are transmitted only from client to server.

• Third parties must be unable to monitor traffic from the client to the server, and must be unable to inject traffic impersonating the server and addressed to the client.

Security with an untrusted communications path

The communications path between client and server may involve third parties. This would be the case if, for examples,

• an ISP's recipient notification agent, supplied to its clients, were not directly connected to the ISP's LAN,
• a "roaming" user were connecting to his/her "home" recipient notification agent via a third party, or
• an ISP customer were using a recipient notification agent provided by a third party.

In these cases, the protocol is vulnerable to man-in-the-middle attacks, or to any third party capable of injecting traffic into the session. Therefore, for security, clients and servers in such situations should either

• employ transport-level security measures to encrypt PDUs, or
• tunnel the session through a secure communications mechanism such as SSH.

Servers must not use transport-level security measures as a substitute for the authentication mechanism in the protocol. Transport-level security measures protect the client and server from third parties. Authentication is still required to protect the server from unauthorised clients.

Transactions

There are two tasks which an originator MUA can perform using RNAQP, each of which comprises a single transaction:

• A recipient MUA can attempt to authenticate, switching the session into the authenticated state.
• A receipient MUA can retrieve and clear the list of notifications.

If the session is not in the authenticated state, servers should abort all transactions, other than authentication transactions, with an ErrorNotAuthenticated response.

Authenticating a session

Authentication transactions comprise a single command/response pair. The client sends a CommandAuthenticate PDU containing the authentication data, and the server sends a ResponseAuthenticate PDU that either aborts the transaction (indicating that the session is now in the unauthenticated state) or completes the transaction (indicating the the session is now in the authenticated state with the credentials supplied).

Servers must not prohibit authentication transactions when the session is already in the authenticated state. Clients may switch credentials during a session.

The authentication data comprise an account name and a password string (i.e. a per-account secret shared between client and server). These data are to have been obtained from the recipient notification agent store owner via some out-of-band means that is not specified.

Retrieving and clearing the list of notifications

Retrieval transactions comprise a single command/response pair. The client sends a CommandRetrieveAndClear PDU containing the authentication data, and the server sends a ResponseRetrieveAndClear PDU that (if it does not abort the transaction and does not indicate an error status) comprises the list of notifications.

Retrieval transactions retrieve all of the received notifications at the server and clear the server's list of received notifications. Servers must perform these two actions as a single, atomic, operation. Servers thereby provide a guarantee to clients that any notification received whilst a retrieval transaction is in progress will either be returned by that transaction or be on the server's list of notifications after the transaction has completed.

Each message notification comprises:

• the location of the message store's MSRAP service from whence the message can be retrieved;
• the recipient mailbox to which this notification applies;
• the message identifier to use for retrieving the message;
• the (publically visible) name of the originator of the message;
• the location of the RNASP client that submitted the notification;
• the date (expressed as the number of TAI seconds since the start of the POSIX Epoch) that the message notification was submitted; and, optionally,
• the size (advisory only) of the message, in octets.

Clients must not treat the size value as anything but advisory. Its sole purpose is to provide a means whereby a POP3 message reading shim may serve up message and mailbox size data that at least have the possibility of being correct.