Switching the mail transport architecture to IM2000 does not require the immediate global replacement of all MUAs. Existing MUAs for the SMTP-based Internet mail system may be used with the IM2000 Internet mail system, to make use of a subset of IM2000 services, by means of shims.
MUAs for the SMTP-based Internet mail system submit mail
An SMTP message submission shim would be an SMTP Relay or an SMTP Submission server, that accepts messages, and an MSOAP client.
One common trivial case of such a shim would be where it was the submission point for the outgoing (SMTP-based) mail sent by an organisation, replacing the organisation's outgoing SMTP mailhub. The shim would submit the mail that it received, via SMTP Submission from the organisation's old-style MUAs, to the organisation's message store. SMTP authentication information would simply pass through to the MSOAP session, and each SMTP transaction would become an MSOAP message submission transaction.
Users would lose two particular features of the old SMTP-based Internet mail system that they might have become used to:
Bounce messages: IM2000 does not have such a concept. (This is, of course, a good thing.) To track the delivery status of a message, users would have to use an IM2000 originator MUA to query the organisation's message store directly.
Detailed envelope validation: MSOAP provides detailed per-recipient envelope error reporting, but handles an envelope in a single command/response pair. This prevents envelope errors from being reported by the SMTP shim any earlier than the response to the DATA verb, preventing the error from being tied to the recipient concerned in the manner that MUAs might expect. (MUAs that tie the error to the particular recipient are rare, however.)
A more complex shim would be one providing an SMTP Relay interface to an IM2000 mailing list. Such a shim would be the SMTP Relay point for the incoming (SMTP-based) mail received at the mailing list host, replacing its incoming SMTP mailhub, and would submit the mail that it received, via SMTP Relay from the old-style SMTP MTSes around the world, to the host's message store. Its operation would be very similar to that of a mail-to-news gateway.
SMTP Relay clients would again see the reporting of envelope errors deferred to the response to the DATA verb. However, and somewhat ironically, this is the present behaviour of some existing SMTP Relay servers, which SMTP Relay clients are already required to deal with.
For semi-public mailing lists, the shim would derive the MSOAP authentication information either from the SMTP authentication information (if provided, which is unlikely given that most clients will be MTAs) or from the envelope sender (resulting in the same access model as with SMTP-based semi-public mailing lists).
Because IM2000 does not have the concept of bounce messages, and unlike the case with some SMTP-based mailing lists, people posting to such lists would not receive bounce messages in the event of problems with list subscribers. (This is a common cause for complaint with some SMTP-based mailing lists.)
A local message submission shim would mimic an SMTP-based MTS's local submission utility (such as the sendmail command) and would act as an MSOAP client. MSOAP authentication information would be derived directly from local user account or user-supplied information.
In the trivial case, the shim would resemble an SMTP-based or QMQP-based "null" MTS (such as qmail's qmail-qmqpc) relaying to a "smart" mailhub. The shim would obtain the location of the message store's MSOAP service from system-wide or per-user configuration information.
MUAs for the SMTP-based Internet mail system read mail
Local mailboxes are entirely contrary to the "sender stores" design of IM2000, their being the very embodiment of the "recipient stores" philosophy. It is possible to create a shim that automatically, at regular intervals, used RNAQP and MSRAP to discover and to transfer new messages to a local mailbox, but this would re-create the very vulnerability to sender abuse that IM2000 is designed to avoid.
MUAs that only read directly from local mailboxes are unsuitable for IM2000.
A POP3 or IMAP message reading shim would be a POP3 or an IMAP server and an RNAQP and MSRAP client.
In the trivial case, the shim would communicate via RNAQP with only one recipient notification agent, and would communicate via MSRAP with multiple message stores. A POP3 shim would operate as follows:
The shim would keep for each user a persistent (across sessions) list of saved notification information for "current" messages.
At session login, the shim would obtain the users's "current" list, and use the authentication information supplied to log in via RNAQP to the recipient notification agent and obtain a list of the notifications for "new" messages. Then it would save the "new" and the "current" lists combined to be used as the "current" list for the next session. Finally, it would scan the "new" list, and for each message make an MSRAP connection to the message store and silence further notifications.
The LIST command would result in a combined list of the "new" and the "current" messages.
(It is possible that the shim could get away with presenting fake message size information. If not, the shim would have to make an MSRAP connection to each message store to obtain summary information for the message, either at session login or when the LIST command is executed. This would have the possibly unfortunate side-effect of having the originator think that the summary of the message had been read, even for messages that were never RETRived by the POP3 client and summarily DELEted unseen - which is rare behaviour for most POP3 clients, however.)
The RETR and TOP commands would result in the shim making an MSRAP connection to the appropriate message store to retrieve the appropriate part of the message. (This gives straight "pass through" semantics to message retrieval. Shims may choose to cache retrieved messages, but with the way that most POP3 clients behave this is unlikely to be useful.)
The DELE command would mark the appropriate message, in the appropriate list, with a flag indicating that it has been "deleted".
The QUIT command would cause the "new" and the "current" lists to be scanned. For each "deleted" message, an MSRAP connection would be made to the message store holding it, and the message store would be instructed to cease retaining the message because it had been refused/transferred. The other remaining messages in the lists would then be saved to be used as the "current" list for the next session.
The operation of an IMAP shim would be analogous, except that:
In the trivial case, an IMAP shim would not support the creation of new mailboxes (and just have the one "INBOX" mailbox) nor support the submission of messages into mailboxes with the APPEND command.
A trivial case shim would usually be run by a recipient notification agent hosting service. More complicated IMAP shims are possible, which would provide for having multiple mailboxes, and have the ability (by acting as a shim for MSOAP) to submit messages. These would usually be run by end users, using user-supplied configuration information to locate and access the user's recipient notification agent and message store. Unlike trivial case shims, they would require their own storage for (outgoing and non-INBOX mailbox) messages.