Although some MUAs employed by users (e.g. those for interactive use) will likely be capable of both tasks, the tasks of originating and of receiving messages are completely distinct and separate. Indeed, some MUAs (e.g. robot MUAs for automatically retrieving messages) may only need be capable of one or other of the tasks, not both. Therefore, recipient MUAs are considered separately from originator MUAs.
Recipient MUAs are used by message recipients to retrieve, to transfer, or to refuse messages, and to configure the operation of recipient notification agents. To achieve this, recipient MUAs communicate with one or more recipient notification agents using the Recipient Notification Agent Query Protocol, and with one or more message stores using the Message Store Recipient Access Protocol.
To read a message, a recipient MUA retrieves the notification information from the recipient notification agent, and contacts the MSRAP service of the message store indicated therein. It saves the notification information to persistent storage and instructs the message store to stop sending notifications. It then optionally retrieves the actual message data from the message store, one or more times. Finally, it instructs the message store that it need no longer retain a copy of the message (The message is "un-pinned".) and deletes the notification information from the persistent storage.
The process of reading a message may be spread out over several sessions. Recipient MUAs may request the message data from a message store many times before instructing the store to un-pin the message. (Expressed in terms of a folder-paradigm MUA: The recipient's "Inbox" folder is not stored locally, but comprises individual messages spread out across all of the message stores of the originators who have sent messages.)
Recipient MUAs must be capable of handling in a reasonable way the case where a message store owner or an originator has deleted a message whilst the recipient has not yet copied it to local storage. (Expressed in terms of a folder-paradigm MUA: Messages in the recipient's "Inbox" folder may disappear at any time.)
Silencing notifications from a message store does not imply message delivery and that the responsibility for the message storage has been transferred. (Expressed in terms of a folder-paradigm MUA: Silencing a notification simply changes the message status from "new" to "current", but does not move it out of the recipient's "Inbox" folder.)
Recipient MUAs should maintain in persistent storage a list of the notifications for messages that the recipient is still interested in but whose notifications the MUA has already silenced. (Expressed in terms of a folder-paradigm MUA: The recipient notification agent manages the list of where to find the "new" messages, and the recipient MUA manages the list of where to find the "current" messages, in the recipient's "Inbox" folder.)
To avoid a race condition, a recipient MUA should add newly received notifications to its list in persistent storage before instructing the message stores to silence the notifications.
To locate a message store's MSRAP service on Internet, a recipient MUA uses the service location information contained in the notification, which comprises one or both of
To locate the service using the list of IP address and port pairs, the recipient MUA sorts the list using local criteria (such as locally specified network proximity information) and then scans the list attempting to connect to each IP address and port combination in turn, and stopping at the first successful connection.
To locate the service using the domain name, the recipient MUA takes the domain name and using it applies the common DNS lookup algorithm for IM2000 services, using the appropriate service name, which is _MSRAP-SSL for MSRAP-SSL service and _MSRAP for plain MSRAP service.
If both a domain name and a list of IP address and port pairs are supplied recipient MUAs must use the domain name. As a consequence, message stores that give the locations of their MSRAP services using domain names must publish service location information in the public DNS database.
For examples:
An "interactive" MUA may have, in its configuration information, a list of "recipient accounts", which will comprise the locations of one or more recipient notification agents, the authorisation information (if any) for accessing them, and their mailbox names. It will allow the recipient to scan for "new" mail in each recipient account. For each recipient account, it will also have a list of "current" messages, comprising the message notifications for that recipient account that it has previously saved to persistent store.
A "robot" MUA may be supplied the location of a single recipient notification agent and the authorisation information for using it.
Recipient notification agent owners may choose to supply simply a domain name as the location of the recipient notification agent's RNAQP service. In this case, the recipient MUA must locate the service by applying the common DNS lookup algorithm for IM2000 services, using the appropriate service name, which is _RNAQP-SSL for RNAQP-SSL service and _RNAQP for plain RNAQP service.
Recipient MUAs manage "reading" subscriptions to mailing lists. Because a recipient MUA has to know where a mailing list is, in order to retrive the messages sent to it, the IM2000 model requires that recipients explicitly inform their recipient MUAs of any mailing lists that they wish to read. Recipient MUAs are provided with a list of mailing lists that the recipient is subscribed (for reading) to. Each mailing list "reading" subscription requires a message store and the account information (if any) for reading from that mailing list on that message store.
Because public mailing lists do not require that the readers have accounts on the message store holding the list, "reading" subscriptions to public mailing lists are an entirely private matter for recipient MUAs, and do not involve any other parties at all.
Recipient MUAs should maintain, for each mailing list so subscribed to, information denoting which messages on the mailing list the recipient has already seen. The recipient MUA uses this saved information when determining, using MSRAP, whether any new messages have been added to the mailing list.
A recipient may choose to transfer responsibility for storing a mail message to its MUA's local storage, or may choose to refuse delivery of a message. (Expressed in terms of a folder-paradigm MUA: The recipient may choose to move a message from the recipient's "Inbox" folder to another, local, folder; or to delete the message outright.)
These are simple variants on the same sequence of operations. To refuse a message, the recipient MUA contacts the message store via MSOAP and instructs it to un-pin the message, without retriving the actual message data first. To transfer a message, the recipient MUA does the same thing, except that it retrieves the message data and saves it to local storage before it un-pins it.
When transferring messages to local storage, recipient MUAs should prepend a trace header in the format specified in RFC 2822. The date should be the date that the transfer took place, and the following data should be included: