The Message Store Originator Access Protocol is the means by which originator MUAs communicate with message stores. It shares a common structure and common transport layer requirements with the other IM2000 protocols.
Individual to MSOAP are:
With MSOAP, the client is the originator MUA, and the server is the MSOAP service of the message store.
MSOAP is subject to the common IM2000 PDU rules.
The response that an MSOAP 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 MSOAP server must send to a client in the event of a timeout is a ResponseNull PDU comprising
This is the ASN.1 definition of MSOAP.
MSOAP 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 originators from tracking or cancelling any but their own messages.
The entire communications path between client and server may be under the control of either the originator or the message store owner. This would be the case if, for example, the message store is owned by an ISP, the MSOAP service of the message store is on the ISP's own network, and the originator MUA is running on a machine connected to the ISP's network.
The same security considerations apply here as for SMTP Submission 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. (And, conversely, in the case of message stores that accept messages from unauthenticated clients, clients may want to have sessions with servers that are secure from third-party interference without any implicit authentication occurring as a side-effect.)
Submission of a message supplies an opaque identifier to its originator that servers must prevent from being used for tracking and cancellation of a message by any sessions not authenticated as that same originator.
Message stores that permit unauthenticated clients to submit messages must not support message tracking and cancellation.
There are four tasks which an originator MUA can perform using MSOAP, each of which comprises a single transaction:
If the session is not in the authenticated state, servers may abort all transactions, other than authentication transactions, with an ErrorNotAuthenticated response. (Note that some message stores, e.g. those that are public mailing lists, may choose to accept message submissions from unauthenticated clients.)
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 message store owner via some out-of-band means that is not specified.
Submission transactions are the only MSOAP transactions that comprise multiple command/response pairs. The first command/response pair transfers the message envelope and control information, and subsequent command/response pairs transfer the message itself (both headers and body together) in "chunks", sized as necessary to ensure that the command PDU does not exceed a given size.
If a client aborts, rather than completes, a submission transaction in any manner (e.g. by sending a command PDU with the forceabort flag set to true or by aborting the session), or if the server aborts the transaction for any reason (e.g. the envelope and control information are erroneous or the user has run out of assigned storage space), the server must not store the message. Conversely, before sending the final (successful) response in the transaction, the server must have stored the message.
A CommandSubmitEnvelope command comprises
The message expiry information is expressed as a message lifetime, in TAI seconds (i.e. "leap" seconds are counted as one second). The lifetime begins from the time that the message is submitted. Message stores may refuse to accept envelopes with lifetimes that are below a minimum length set by the message store owner.
A ResponseSubmitEnvelope response indicates whether the envelope data are acceptable or not.
If the envelope data are acceptable, the response will have the forceabort flag set to false, and will optionally contain the maximum message chunk length that the server is prepared to accept in a single command PDU. The response may also contain an unique message identifier for use in subsequent tracking or cancellation transactions.
If the envelope data are unacceptable, the response will have the forceabort flag set to true and the recipients and lists will optionally contain status codes for each of the message recipients and mailing lists supplied in the command, in the order corresponding to the order in which those data were supplied in the command from the client. If the reason for the envelope data being unacceptable are related to the recipient or mailing list lists, the server should supply the status code lists, providing a status code for every recipient and mailing list. In any event, the response status code will indicate a general reason for the failure.
Message data are transferred by a CommandSubmitMsgChunk command, which comprises
Servers must be capable of coping with clients that send "chunks" that overlap one another. It is the client's responsibility to ensure that when all of the "chunks" are combined, they comprise the entire message. The contents, when retrieved from the message store, of those portions of a message that were not sent by the client, are unspecified.
Message data are send as the raw sequence of octets comprising the message. Message data are not otherwise encoded or escaped for transmission. Servers must be capable of storing arbitrary octets, and must not attempt to parse message content. It is the client's responsibility to ensure that message data are in the Internet message format.
Servers may prepend trace headers, in the format specified in RFC 2822, to the message content before storing it. The date should be the date that the message submission took place, and the following data should be included:
Servers must not include the unique message identifier in such trace headers, and should not include for data.
Each ResponseSubmitMsgChunk response indicates the success or otherwise of receiving that chunk of data. Clients must transmit messages in chunks whose data are no greater than the chunk size specified in the ResponseSubmitEnvelope response (defaulting to 32KiB if the server does not specify a maximum size).
Tracking transactions comprise a single command/response pair. The client sends a CommandTrack PDU containing a unique message identifier previously supplied by that server, and the server sends a ResponseTrack PDU that (if it does not abort the transaction and does not indicate an error status) comprises the delivery status of the message.
The delivery status of a message comprises a list of DeliveryStatus tuples, one per envelope recipient, in the same order as the recipients were specified at the time of message submission.
The NotificationStatus part of the tuple describes the status of notifications to the recipient for the message. The notification status can be:
Even in the event of an error, clients must allow for the fact that the notification status may change on subsequent notification attempts.
The ReadStatus part of the tuple describes the delivery status of the message with respect to the recipient. The read status can be:
The pinned part of the tuple indicates whether that recipient has un-pinned the message using MSRAP.
Cancellation transactions comprise a single command/response pair. The client sends a CommandCancel PDU containing a unique message identifier previously supplied by that server, and the server sends a ResponseCancel PDU that (if it does not abort the transaction and does not indicate an error status) indicates that the server has accepted the cancellation by the originator.