The Message Store Recipient Access Protocol is the means by which recipient MUAs communicate with message stores. It shares a common structure and common transport layer requirements with the other IM2000 protocols.
Individual to MSRAP are:
With MSRAP, the client is the recipient MUA, and the server is the message store.
MSRAP is subject to the common IM2000 PDU rules.
The response that an MSRAP 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 MSRAP server must send to a client in the event of a timeout is a ResponseNull PDU comprising
This is the ASN.1 definition of MSRAP.
MSRAP is designed for one basic security model with respect to the communications path. It is designed to make brute force attacks against the authentication mechanism harder. It is designed to prevent (unauthenticated) recipients from reading any but their own messages.
The communications path between client and server may involve third parties. This will usually be the case, since the message store will have no direct prior relationship with the recipient.
In this case, 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. (And, conversely, message stores generally will want to allow unauthenticated clients to retrieve messages, requiring that implicit authorisation not occur as a side-effect of employing transport-level security measures, and rely instead upon the security of the message identifier, so that they do not have to arrange accounts with every possible recipient.)
Retrieval of a message employs an opaque identifier supplied by the recipient to the message store. The security of message retrieval stems from the security of the generation of that identifier and the security of the RNASP and RNAQP mechanisms used to pass that idenitifer to the recipient.
There are four tasks which an originator MUA can perform using MSRAP, each of which comprises a single transaction:
The operations on a message store that recipients see via their MUAs are actually combinations of these tasks. For example:
To refuse a message the recipient MUA silences further recipient notifications for the message and then signals the message store that a message need not be stored further.
To read a message the recipient MUA silences further recipient notifications for the message; retrieves the message, possibly several times, in part and in whole; and then signals the message store that a message need not be stored further when appropriate.
To retrieve new submissions to a mailing list the recipient MUA scans for (new) public messages and then retrieves each message, possibly several times, in part and in whole.
These combinations may be spread across multiple sessions and over a long period of time.
Retrieval transactions comprise a single command/response pair. The client sends a CommandRetrieve PDU containing a unique message identifier, the type of message data requested, and offset and length information; and the server sends a ResponseRetrieve PDU that (if it does not abort the transaction and does not indicate an error status) comprises a "chunk" of the required message data, along with the overall size of those data.
The message identifier supplied by the client is obtained either from a recipient notification agent, as part of a message notification, or from the server via a scanning transaction.
The RetrievalType part of a retrieval command specifies what data the "chunk" retrieved comes from. Clients may request four different forms of message data from servers:
When the "summary" information is requested, the data requested comprise a filtered version of the actual headers of the message. Servers parse the message headers and select all Subject:, From:, Date:, Message-ID:, and References: headers that occur, returning them in the same order that they occur in the message. However, clients must not assume that servers have done this filtering, and must scan the retrieved data for the desired headers. (Recipient MUAs should issue an alert if a server returns any non-"summary" headers in a summary, or if when later retrieving the full headers the "summary" headers therein do not match what was retrieved as the summary.)
Clients must also allow for messages that have more than one occurrence of each header. Servers and clients should not impose line length limitations on message data during retrieval.
If the specified offset is beyond the end of the data requested, servers must return zero octets of data. If the specified length spans beyond the end of the data requested, servers must only return as many octets as the data actuall comprise. Servers must return no more than the number of octets requested (which may be zero) and must not pad what they return with extra octets to fill it to the requested length.
Silencing transactions comprise a single command/response pair. The client sends a CommandSilence PDU containing a unique message identifier; and the server sends a ResponseSilence PDU that (if it does not abort the transaction and does not indicate an error status) indicates that notifications have been silenced.
"Unpinning" transactions comprise a single command/response pair. The client sends a CommandUnPin PDU containing a unique message identifier; and the server sends a ResponseUnPin PDU that (if it does not abort the transaction and does not indicate an error status) indicates that the server has acknowledged that the client does not need it to store the message further.
"Listing" transactions comprise a single command/response pair. The client sends a CommandScanList PDU containing the name of the message list to scan, and a beginning time; and the server sends a ResponseScanList PDU that (if it does not abort the transaction and does not indicate an error status) comprises a list of message identifiers and an ending time.
Messages are scanned as if they are ordered by the time of their submission, expressed as the number of TAI seconds since the beginning of the POSIX Epoch. The beginning time in the command is the submission time where the scan is to begin. Messages submitted on or after that time are returned, listed in submission order. The ending time is the current time at the server. Servers must not return in the list the identifier for any message submitted on or after that time.
The time values allow a trivial client to retrieve messages using successive transactions using just a single time field to maintain state. Whenever it issues a scan command, it uses its saved time value as the beginning time. Whenever it receives a scan response, it saves the end time as the new saved time value.