If you are an end user and want to migrate to IM2000, there are two possible paths that you can take:
You can keep your current MUA, speaking SMTP/POP3/IMAP, and employ the services of mail hosting companies that provide message store and recipient notification agent services and support shims to allow your MUA to indirectly talk to those services.
The disadvantages of this choice are that you won't be able to use the full capabilities of IM2000 Internet mail:
You won't be able to track the delivery status of the messages that you send.
You won't be able to refuse mail. (A POP3 shim pulls in all of the mail that everyone is sending to you, indiscriminately. An IMAP shim might be able to do better, depending from how good quality it is, since IMAP provides greater control over messages before they are downloaded. But even then, you are constrained by whether your IMAP MUA actually takes full advantage of these features of IMAP in the first place. Some don't.)
You won't be able to ostracise senders. Your MUA, speaking POP3 or IMAP, will have no means for telling your recipient notification agent whose mail notifications to filter out.
You can upgrade your current MUA to an IM2000 originator/recipient MUA.
The disadvantage of this choice are that such softwares are, at the moment, quite rare.
In both cases you then simply tell everyone your IM2000 Internet mailbox name, which you will have agreed with whoever owns your recipient notification agent.
Mail hosting companies and corporate mail systems have similar structures. Mail hosting companies provide incoming and outgoing mail services for their customers. Corporate mail systems provide incoming and outgoing mail services for their members/employees. One difference, however, is that mail hosting companies will generally allow "roaming" use, whereas corporate mail systems may require direct connection to their networks in order to submit company messages or to receive mail notifications for company mailboxes.
Migrating to IM2000 for both mail hosting companies and corporate mail systems has three aspects.
Migration to IM2000 involves deploying IM2000 services.
One deploys a message store to hold all outgoing mail.
The message store will provide MSRAP-SSL service on an IP address and port combination that is reachable by the rest of Internet.
For a mail hosting service or a corporate mail system with "roaming" users, the message store will provide MSOAP-SSL service on an IP address and port combination that is reachable by the rest of Internet. For a corporate mail system with no "roaming" users, it will provide MSOAP-SSL (or perhaps just plain MSOAP, depending from the security of the network to "insider" attacks) service on an IP address and port combination that is only reachable from the organisation's own network.
Use of the message store will require one to create, manage, and delete originator accounts at the message store. (For a mail hosting service, account generation will be part of the process of customers signing up for the service.)
Procedures will be required for passing originator account information, along with information about the location of the message store's MSOAP service, to originators, so that they can enter that information into their MUAs. (For a mail hosting service, these will be part of a "welcome message" presented to the customer at signup time. However, mail hosting services should also provide message store MSOAP service location information via their customer support services.)
Corporate mail systems with communications archival requirements may furthermore choose to disable the removal of any messages from the message store.
One deploys a recipient notification agent to hold all incoming notifications.
The recipient notification agent will provide RNASP-SSL service on an IP address and port combination that is reachable by the rest of Internet.
For a mail hosting service or a corporate mail system with "roaming" users, the recipient notification agent will provide RNAQP-SSL service on an IP address and port combination that is reachable by the rest of Internet. For a corporate mail system with no "roaming" users, it will provide RNAQP-SSL (or perhaps just plain RNAQP, depending from the security of the network to "insider" attacks) service on an IP address and port combination that is only reachable from the organisation's own network.
One must publish the locations of the recipient notification agent's RNASP-SSL and RNASP services in the public DNS database.
Use of the recipient notification agent will require one to create, manage, and delete originator accounts at the message store, and their concomitant mailbox names. (For a mail hosting service, account generation will be part of the process of customers signing up for the service. The service may choose to tie mailbox names to account names in some fashion, or to allow users a free choice in the selection of mailbox names.)
Procedures will be required for passing recipient account information, along with information about the location of the recipient notification agent's RNAQP service, to recipients, so that they can enter that information into their MUAs. (For a mail hosting service, these will be part of a "welcome message" presented to the customer at signup time. However, mail hosting services should also provide recipient notification agent RNAQP service location information via their customer support services.)
Originators and recipients may wish to retain their existing MUAs. Such MUA can usually (with the exception of recipient MUAs that operate by having direct access to locally stored recipient mailbox contents) be supported by the use of shims.
One may choose either
to provide the shim submission and reading services alongside existing SMTP Submission and POP/IMAP services;
orRunning the services in parallel has the disadvantages that it requires originator and recipient account information to be maintained concurrently both for the old services and for the IM2000 message store and recipient notification agent, and that it requires originators and recipients to use two sets of account information.
to entirely replace those old services with the shims.
Replacing old message reading services with POP3 and IMAP shims for IM2000 has the advantage that it provides the rest of the world with incentive to upgrade to IM2000 since it allows one to immediately discontinue one's SMTP Relay service entirely and require that from that point on all senders shoulder the costs of any mail that they wish to send to one.
Replacing message submission services with SMTP Submission shims has the consequence that all recipients to whom mail is to be sent must be capable of receiving IM2000 mail.
Deprecation of old services involves
Ironically, the best way to discourage the rest of Internet from using SMTP-based Internet mail to reach one is to simply employ all of the various anti-UBM measures for SMTP-based Internet mail to their maximal extents. The resultant paradigm conflicts, egregious discriminations, and outright destruction of SMTP functionality will render SMTP-based mail pretty much unusable, for communicating with one, by vast swathes of the populace.