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:
With RNAQP, the client is the recipient MUA, and the server is the recipient notification agent.
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
The response that an RNAQP server must send to a client in the event of a timeout is a ResponseNull PDU comprising
This is the ASN.1 definition of RNAQP.
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.
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.
The communications path between client and server may involve third parties. This would be the case if, for examples,
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
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.
There are two tasks which an originator MUA can perform using RNAQP, each of which comprises a single transaction:
If the session is not in the authenticated state, servers should abort all transactions, other than authentication transactions, with an ErrorNotAuthenticated response.
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.
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:
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.