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 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 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 location of an MSRAP service is contained within the notifications sent out to recipient notification agents. For Internet mail, this location comprises either
a domain name
The domain name maps to the location of the MSRAP service via SRV resource record sets published in the public DNS database by the message store owner. There is, intentionally, no well-known port number for MSRAP service. The port number is contained in the DNS information.
When moving the MSRAP service to a different IP address or port number, the MSRAP service should continue to be available on the old IP address or port number until such time as the SRV records to locate it will have expired from any caching DNS servers. In other words, the MSRAP service should continue to be available on the old IP address or port number for the TTL period of the old SRV resource record set. (Some DNS server softwares provide a "time to die" mechanism to allow DNS changes to be synchronised with a service changeover.)or
a list of IP addresses and port numbers
Moving the MSRAP service to a different IP address or port number will invalidate all existing notifications. Specifying, in notifications, the location of a message store using an explicit list of IP addresses and port numbers inhibits the ability to move the MSRAP service.
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 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:
Each message is scheduled individually. When a message is submitted, a notification to each recipient for that specific message alone is sent immediately. At regular intervals thereafter, all recipients are again notified about that message. This has the consequences that only one <recipient,message> tuple is sent per notification transaction, and that informing a recipient about multiple messages requires multiple notification transactions.
A global schedule is used, and overridden only for the initial notification. A notification to each recipient for that specific message alone is sent immediately upon message submission. At regular intervals the entire message store is scanned and all repeat notifications are sent. This has the advantages of allowing multiple notifications to be sent at once, of needing the smallest number of lookups to find recipient notification agents, and of being simple to implement; but the disadvantages of not being scalable to large numbers of messages and of sending repeat notifications too frequently in some cases.
Notifications to all recipient mailboxes in the same domain are scheduled together. When a message is submitted, its recipient notifications are sorted by mailbox domain name and added to store-wide per-domain lists. Whenever a new per-domain list is created as a result of this, all notifications on that list are sent immediately. At regular intervals, using a per-list schedule, all of the notifications on each list are re-sent. Thus only one notification transaction is used to inform a recipient of all of the messages to be delivered to it by the message store.
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.)
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.
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.