IM2000 Message stores

Message store contents

Message stores contain messages with accompanying envelope and control information. The underlying database that message stores use is beyond the scope of this specification, and is purely an internal matter for individual message stores. Message store contents are accessed by IM2000 entities only via the access protocols.

Message stores may provide one, or both, of

A single message may be both a personal message (to one or more recipients) and a mailing list message (on one or more mailing lists) simultaneously. These data are stored in the envelope of the message. Originator MUAs must allow for the fact that message stores may reject the submission of messages that have both no recipients and no mailing lists in their envelopes.

Message stores are partially structured. Messages are indexed by a combination of mailing list name and submission date, and by one or more unique identifiers assigned to the message by the message store.

Message store access protocols

Message stores provide two services to clients, one speaking the Message Store Originator Access Protocol (to originator MUAs) and the other speaking the Message Store Recipient Access Protocol (to recipient MUAs).

These services are separate. Message stores that speak these protocols over TCP can, and in fact should, speak these protocols on separate IP addresses. These IP addresses may have different reachability characteristics. Indeed, the reachability of the IP addresses on which the access services are provided is one of the measures that message store owners may employ for securing their message stores.

For example: A message store, for use only by people within a single organisation and only when those people are connected to that organisation's own network, may be configured to speak MSRAP on an IP address that is reachable from the rest of Internet, allowing the general populace to receive messages from the message store; and to speak MSOAP on a non-public (RFC 1918) IP address that is only reachable by people within the same organisation as the message store, allowing only people that are directly connected to the organisation's own network to send messages.

Message stores must allow multiple concurrent sessions of both protocols to exist, and must not delay transactions in a session because of the mere existence of other sessions.

Message stores should provide their owners with mechanisms for specifying an upper bound on the number of concurrent sessions that the message store will serve. Message stores may simply close any new connections as they are made if an attempt is made to exceed the session limit, or may employ the transport protocol's mechanism for refusing new connections. Owners should not set an upper bound for MSOAP sessions that is less than 2, or set an upper bound for MSRAP sessions that is less than 5.

The originator access service

The location of the MSOAP service is provided to originators by explicit agreement between the message store owner and the originators. (The message store owner and the originator may, of course, be one and the same.)

There is, intentionally, no well-known port number for MSOAP service. The choice of port number is a private matter for originators and the message store owner.

The recipient access service

The location of an MSRAP service is contained within the notifications sent out to recipient notification agents. For Internet mail, this location comprises either

The life cycle of a message


Messages are submitted to message stores by originator MUAs. Message stores should prepend a trace header in the format specified in RFC 2822 to messages at the point of submission. The date should be the date that the submission took place, and the following data should be included:

Message stores may also include (but in order to preserve privacy may also choose not to include)

Message stores must not attempt to "canonify" messages as they are submitted. It is the responsibility of originator MUAs to create messages in the correct format and with all of the required fields fully filled in.


Message stores are active entities. Once a message has been submitted to a message store by an originator, the message store begins to attempt to send recipient notifications to the recipient notification agents for each of the message's recipients. Message stores are Recipient Notification Agent Submission Protocol clients.

Message stores should continue to attempt to send notifications, at regular intervals, to recipients until at least one of the following events occurs:

The schedules according to which which message stores repeat their notifications are unspecified. Common (but not the only) choices are:

Message stores should repeat notifications no more often than once per day.


Message stores retain messages until at least one of the following events occurs:

Cancellation and expiry are essentially the same, the difference between them being when the originator specifies that the message be deleted. With cancellation, deleting the message is a separate, explicit, command. With expiry, the command to delete the message at a certain point is implicit in the envelope information that the originator supplies at message submission time.

In the absence of cancellation or specification of an expiry time on the part of the message originator, deletion of a message from a message store is entirely recipient-driven. (Expressed in terms of a folder-paradigm MUA: When a message is stored by a message store, it resides in the (distributed) "Inbox" folders of all of its recipients. It is deleted when all of the recipients have either deleted it from their "Inbox" or transferred it to another folder.)

Notifications over Internet

Message stores are not required to connect to RNASP services from the same IP address(es) upon which they provide their own access services. Recipient notification agents must not expect or require this to be the case.

To locate a recipient notification agent on Internet, a message store takes the domain portion of the recipient mailbox name and using it applies the common DNS lookup algorithm for IM2000 services twice, first attempting to find an RNASP-SSL service (whose service name is _RNASP-SSL) and then attempting to find a plain RNASP service (whose service name is _RNASP).

Note that IM2000 does not provide a mechanism for locating recipient notification agents for recipient mailbox names whose domain portions are are IP address literals. Message stores may reject such recipient mailbox names at message submission.

If a recipient is permanently unreachable by both RNASP-SSL and RNASP, the message store must not attempt further notifications. The recipient's domain is considered not to have any IM2000 mail recipients in such circumstances.

Notification should be attempted again, after the retry interval, if a recipient is temporarily unlocatable.

To allow recipients to move their notification agents to different IP addresses by simply changing what is published in the DNS database, message stores must not themselves cache the location of a recipient's notification agent in between notification attempts.

Message identifiers

Messages are accessed by recipients using message identifiers. These are opaque tokens generated by the message store. A message has a zero or more identifiers, one for every recipient and one for each mailing list that the message is posted to. The per-recipient identifiers identify the message and the particular recipient. The per-list identifiers identify the message and the mailing list.

Message stores send the per-recipient identifier in message notifications to recipients. Recipients thus access messages using their per-recipient identifiers, allowing message stores to maintain the delivery information for the appropriate recipient.

Message stores send the per-list identifiers when instructed to scan mailing lists. Mailing list readers thus access messages using the per-list identifiers, ensuring that they are not confused with individual personal recipients. Per-list identifiers cannot be used to silence notifications or to un-pin messages. Recipients are thus protected from the possibility of mailing list readers affecting their delivery status in the case where a message is sent both to individual recipients and to one or more mailing lists.

How message stores generate identifiers is unspecified. Message stores should generate message identifiers in a manner that makes it hard to guess unknown identifiers, even if other identifiers issued by the message store are known.

Message identifiers are unique within a given message store. Message stores must guarantee that no two message identifiers valid at any one time are equal, and should never re-use previously valid identifiers that identify messages that have been deleted from the store.

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