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 submitting messages) may only need be capable of one or other of the tasks, not both. Therefore, originator MUAs are considered separately from recipient MUAs.
Originator MUAs are used by message originators to create messages and enter them into the mail system, and to monitor and control their status thereafter. To achieve this, originator MUAs communicate with one or more message stores using the Message Store Originator Access Protocol.
A complete message is constructed, and is then submitted along with envelope information by an originator MUA, using MSOAP, to a single message store. The details of how a message and its envelope information are constructed by the originator MUA are outside of the scope of this document, and will vary according to the purpose of the originator MUA concerned.
Originator MUAs do not "discover" message stores. Access to a message store by an originator is through explicit arrangement between the originator and the message store owner. The latter provides the former with the location of the message store and the authorisation information (if any) required by MSOAP for accessing it. (The out-of-band means by which these are provided is beyond the scope of this document.) The former then passes that information to his/her originator MUA. (The out-of-band means by which this is done is beyond the scope of this document.)
For examples:
An "interactive" MUA may have, in its configuration information, a list of "originator accounts", which will comprise the locations of one or more message stores and the authorisation information (if any) for accessing them. It may allow the originator to pick which originator account is used to send a message. It may also allow other information to be stored along with the account (such as a default From: field to place into messages when they are created under the aegis of that account, for example).
A "robot" MUA may be supplied the location of a single message store and the authorisation information for using it.
Originator account names do not denote recipient mailboxes. Originator MUAs must not use originator account names where recipient mailbox names are expected (such as in the sender identification fields of message headers).
Message store owners may choose to supply simply a domain name as the location of the message store's MSOAP service. In this case, the originator MUA must locate the service by applying the common DNS lookup algorithm for IM2000 services, using the appropriate service name, which is _MSOAP-SSL for MSOAP-SSL service and _MSOAP for plain MSOAP service.
Originator MUAs manage "writing" subscriptions to mailing lists. Because an originator MUA has to know where a mailing list is, in order to post messages to it, the IM2000 model requires that originators explicitly inform their originator MUAs of any mailing lists that they wish to post to. Originator MUAs are provided with a list of mailing lists that the originator is subscribed to. Each mailing list is associated with a message store and the account information (if any) for posting to that mailing list on that message store.
Originator MUAs are thus capable of distinguishing between posts to mailing lists and posts to explicit recipients. However, originator MUAs should not prevent messages from being addressed to both at the same time.
When a message has been submitted to a message store using an "authorised" MSOAP transaction, the message store provides (as part of the MSOAP transaction for submitting the message) the originator MUA with an unique (to that particular message store) identifier. An originator MUA can use that identifier to later track the delivery status of that message and to cancel it.
MSOAP (by design) does not provide originator MUAs with a mechanism for reading messages back from the message store. Therefore, originator MUAs that track delivery status or that allow message cancellation are expected to retain part or all of the message locally, associating it with the unique identifier from the message store, if displaying part or all the original message to the originator, when tracking its delivery status or when cancelling it, is desired.