This is a case study of how a hypothetical organisation such as the IETF would run a public mailing list, named upgrade-to-im2000, and how people would read and contribute to that list.
In order to run a public mailing list, the IETF has to run a message store to hold the messages on that list, which it does.
Since this list is intended for the general public to both read from and write to, the message store must speak MSRAP to readers and MSOAP to writers over TCP on IP addresses that can be reached by Internet at large. (In contrast: If the list were intended for private use, the IETF would choose to make it speak MSOAP and MSRAP over TCP on IP addresses that are only reachable within its own network, or choose to make it speak MSOAP or MSRAP over some local non-Internet transport protocol.)
The IETF chooses to have its message store speak MSOAP and MSRAP on the same IP address, 64.246.32.114, on the TCP ports 8192 and 8193, respectively. It publishes DNS information such that this IP address can be looked up in the DNS under the name lists.ietf.org..
The IETF also chooses, for reasons that we shall come to later, not to employ transport-layer security on its MSOAP and MSRAP services.
Creating the mailing list is relatively simple. The message store administrator instructs the lists.ietf.org. message store that it now contains a new mailing list named upgrade-to-im2000, using whatever configuration interface that the particular message store software being used provides to its administrator. From that point on, the message store will now accept messages for that mailing list.
The message store administrator also chooses the access controls for the mailing list, which the message store software requires as part of the list creation process. The administrator has to choose
The administrator chooses the access controls most suitable for the list, according to who it is intended can read from and write to it. The IETF intends this to be a public mailing list, that anyone can read from and write to without restriction. The administrator therefore chooses
As a consequence of the latter, message cancellation via MSOAP is unavailable. (Were it otherwise, anyone could cancel any message posted to the list by anyone else.)
The administrator could, alternatively, have chosen more restrictive access controls, such as
Such restrictive access controls on readers would be unusual, and would generally apply only to semi-public (e.g. invitation only) mailing lists. Such restrictive access controls on writers would be more common, and would be employed by message store owners that required the ability to exclude certain people from contributing to the list (which they would do either by denying post access to their accounts or by simply not granting them an account in the first place). They do, of course, incur the administrative overhead of the message store owner having to manage accounts and the processing overhead of the message store having to retain and to verify account information.
Whether the access control is based upon just whether one has an account or upon whether one has an account that has been specifically permitted to read or write, depends from whether the message store also holds other mailing lists or provides personal mail storage services as well. Message stores that provide multiple mail storage services would generally have fine-grained access control information for user accounts. Conversely, message stores that only hold a single (semi-public) mailing list need only rely upon the binary datum of whether a user has an account.
The fact that the administrator chooses not to require that readers and writers have message store accounts, in conjunction with the fact that contributions to the mailing list are intended to be for public consumption, are the reasons that the IETF chooses not to employ transport-layer security on its MSOAP and MSRAP services. If the interception by third parties of messages being written to and read from the list, or of account authorisation information being transmitted to the server, were a concern, then a message store owner would choose to employ transport-level security.
The IETF then advertises the existence of that mailing list, listing the IP addresses and port numbers on which it can be accessed via MSOAP and MSRAP. If transport-level security were required, it would also publish the message store's host keys for those two services.
In the IM2000 model, there are two separate and distinct forms of mailing list subscription. One can be subscribed to the list in order to read from it, and one can be subscribed from the list in order to write to it. One does not necessarily have to do both. (For example: In the case of an announcment mailing list, only those posting announcements would be subscribed for writing, whereas members of the general public would be subscribed for reading.)
Since the message store owner has chosen that an account at the IETF message store is not required in order to read from the upgrade-to-im2000 mailing list, subscribing to and unsubscribing from the mailing list, in order to read from it, is purely a local matter for readers and their own recipient MUAs.
To subscribe to the mailing list, readers simply instruct their recipient MUAs to access the message store at lists.ietf.org. on port 8193 using MSRAP with no user account information. To unsubscribe from the mailing list, readers simply instruct their recipient MUAs to cease doing this. Nothing is done at the message store end at all.
If the message store owner had chosen that an account at the IETF message store were required in order to read from the mailing list, subscribing to the mailing list would require the additional steps of readers contacting the message store owner (via some out-of-band means) to obtain a user account at the message store, and passing this account information to their recipient MUAs as part of subscribing to the list. (One means of obtaining this account information, for example, would be an account request form on an IETF web page.)
Since the message store owner has chosen that an account at the IETF message store is not required in order to write to the upgrade-to-im2000 mailing list, subscribing to and unsubscribing from the mailing list, in order to write to it, is purely a local matter for writers and their own originator MUAs.
To subscribe to the mailing list, writers simply inform their originator MUAs that there is a mailing list named upgrade-to-im2000, and that all messages marked as posts to that mailing list are to be sent to the message store at lists.ietf.org. on port 8192 using MSOAP with no user account information. To unsubscribe from the mailing list, writers simply delete that information from their originator MUAs. Nothing is done at the message store end at all.
Alternatively, since no account information is required to access the message store, originator MUAs may provide writers with the means for addressing "once off" messages to mailing lists, with the originator explicitly supplying the mailing list name and message store location at the time of individual message composition.
If the message store owner had chosen that an account at the IETF message store were required in order to write to the mailing list, subscribing to the mailing list would require the additional steps of writers contacting the message store owner (via some out-of-band means) to obtain a user account at the message store, and passing this account information to their originator MUAs. (One means of obtaining this account information, for exmaple, would be an account request form on an IETF web page.)
In the IM2000 model, moderation of submissions to a mailing list is done by the message store communicating with moderators via a private channel, separate from the message store's MSOAP and MSRAP services, and having the ability to hold submissions for review and confirmation or rejection before (if confirmed) making them visible via MSRAP.
If the IETF intended to moderate submissions to the mailing list, it could (for example) employ message store software that provided moderators with a (secure) World Wide Web interface to a list of "pending" submissions, with forms allowing messages to be permitted or to be rejected by moderators.
The process of reading from the mailing list is managed by Wendy's recipient MUA.
When Wendy decides to check the mailing list for new messages, her recipient MUA connects to the MSRAP service on lists.ietf.org. port 8193 and requests a scan of the upgrade-to-im2000 mailing list for new messages. The server responds with a list of the unique IDs of any new messages, which Wendy's recipient MUA then uses to obtain each individual message.
Wendy's recipient MUA obtains just the summaries of each message, and displays them to Wendy as a list. (If Wendy has configured any "kill files", "watch lists", and so forth, it instead obtains the headers of each message, and automatically processes any messages that match Wendy's specified criteria.) When Wendy decides to read an individual message, Wendy's recipient MUA obtains the full message.
The process of writing to the mailing list is managed by Sally's originator MUA.
Sally composes a message that she specifies to be posted to the upgrade-to-im2000 mailing list. Since she has already told her originator MUA that posts to that mailing list are to be sent to the MSOAP service on lists.ietf.org. port 8192, when she instructs her originator MUA to send the message it connects to that MSOAP service and sends the message.