Constructing shims to allow old SMTP/POP3 MUAs to interact with IM2000

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.

Message submission shims

MUAs for the SMTP-based Internet mail system submit mail

SMTP message submission shims

An SMTP message submission shim would be an SMTP Relay or an SMTP Submission server, that accepts messages, and an MSOAP client.

Trivial shims: SMTP Submission of an organisation's outgoing mail

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:

More complex shims: SMTP Relay front-end to an IM2000 mailing list

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.)

Local message submission shims

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.

Message reading shims

MUAs for the SMTP-based Internet mail system read mail

Local reading shims

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.

POP3 and IMAP reading shims

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 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.

© Copyright 2004-2004 Jonathan de Boyne Pollard. All rights reserved. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp information is preserved.