In his partial outline of the IM2000 system Dan Bernstein poses several questions. These are the answers to those questions for these proposals.
How should receivers be identified? How will the sender's ISP find the receiver's ISP?
Recipients are identified by mailbox names, just as they are with the SMTP-based Internet mail system. Message stores use the DNS to determine, from a mailbox name, where the RNASP service of each receipient's recipient notification agent is to be found. In particular, they perform a SRV resource record lookup on the domain name portion of the recipient's mailbox name.
Recipients will want to move transparently from one host to another.
Moving transparently from one host to another is not quite the same issue as the subject of the two questions. When a recipient wants to move, there will be two common scenarios:
The recipient owns his/her own recipient notification agent. Therefore when moving the recipient moves the recipient notification agent along with everything else, and simply updates the DNS information for finding it to point to the new location, just as it would update the DNS information to point to its relocated SMTP Relay service or its relocated content HTTP service if it ran those itself. The recipient's mailbox name does not, therefore, change.
The recipient is employing the services of a hosting service for his/her recipient notification agent. Therefore the the recipient notification agent does not move when the recipient moves to a new host. This is the simple "roaming user" case. All that the recipient need do is ensure that the hosting service allows him/her to communicate with it using (secure) RNAQP from the new location. Again, the recipient's mailbox name does not change.
How should senders be identified?
Senders are identified in two separate ways:
In IM2000, the "mailbox" where someone receives messages is an entirely distinct concept from the place where they originate messages. The two do not share a single identifier. Moreover, users should be free to choose to buy message store service and recipient notification agent service from two entirely separate entities. The two thus should not share a single identifier.
How will the receiver find the sender's ISP?
Recipients find message stores using the information passed in a message notification. Message notifications contain the location of the message store's MSRAP service and an opaque token that the recipient must use to access the message.
Recipients will want to provide better handling to known senders; in the long run, recipients will want to debit unknown senders.
Recipients providing better handling to "known" originators is simply the reverse way of looking at the scheme that recipient notification agents employ on behalf of recipients. Recipients can configure recipient notification agents to discard notifications for particular messages, for particular originators, for particular message stores, or for particular notifiers (in the event that a message store's RNASP client is located somewhere different to the place that its MSRAP service is located).
Debiting "unknown" originators is not part of IM2000. Originators by design already pay the costs of storing and of transmitting, on demand, copies of their messages. Requiring them to pay further costs would be akin to web browser users requiring content HTTP server operators to pay them for downloading web pages.
How should messages be identified?
Messages are identified to recipients, in notifications, by a tuple comprising the location of the message store and an opaque token that the message store requires the recipient to send back in order to retrieve the message. (It is expected that message stores will generate tokens in a fashion that makes it hard to guess other tokens. Message stores can also employ transport-layer security on their RNASP clients and on their MSRAP services to prevent third parties from intercepting the token as it is sent from message store to recipient notification agent and from recipient back to the message store.) Message stores also communicate a limited set of additional message attributes (e.g. the name of the originator) with each notification.
How should messages be downloaded? Messages could be retrieved through HTTP, but an NFS/FSP-style UDP-based protocol would be much more resistant to denial of service.
Messages are downloaded using MSRAP. Re-using HTTP and NNTP for this was considered and rejected.
HTTP, at least without several complex and heavyweight bolt-ons, is insufficient to the task. Recipients not only need to download messages, they also need to tell message stores when to stop sending notifications and when they have taken over responsibility for storing the message themselves. Also, communicating a mail message over HTTP is non-trivial. A mail message cannot be sent directly as an HTTP message, since the semantics of several of the header fields differ. So at minimum such transport would also require MIME encapsulation of mail messages within HTTP messages, increasing transport costs and introducing ambiguities. MSRAP provides a simple "chunked" data transfer mechanism that is self-delimiting; MSRAP provides a greater range of message download options than HTTP; and using MSRAP does not require fiddling around trying to make the system work with HTTP extensions that were designed for other purposes.
NNTP is insufficient to the task. Recipients not only need to download messages, they also need to tell message stores when to stop sending notifications and when they have taken over responsibility for storing the message themselves. NNTP has no verbs, and not even any extensions, suitable for those tasks. NNTP also has the wrong message identification paradigm. MSRAP requires message stores to give individualised message tokens to recipients, whereas NNTP employs message IDs to identify messages, leading to possible recipient impersonation and the inability to properly track delivery (and so know when a message can be safely discarded from the store) for multiple-recipient messages. Furthermore, NNTP does not provide as complete a range of message download options as MSRAP does.
Whilst the current specification does not cover it, it is feasable to extend MSRAP to operate over unreliable message-based transports. All transactions, in the current specification, are idempotent. However, this weakens session authentication and makes transport-layer security somewhat more difficult. Authenticated MSRAP sessions are desirable because authenticated reading provides certain fringe benefits (such as allowing for semi-public, "invitation only", mailing lists).
How should notifications, messages, and confirmations be protected against espionage and sabotage? DH authenticators seem more appropriate than public-key signatures for private email; they're also much faster and just as convenient.
All of the protocols may employ transport-level security.
RNASP servers may specify that they provide transport-level secure RNASP service. Notifications over a secured RNASP connection, and the opaque message tokens within them, are thus visible in the clear only at the endpoints. A recipient is of course vulernable to sabotage from the recipient notification agent. But a presumption of trust between the two exists, just as a presumption of trust exists between a POP3 user and his/her mailbox service.
Notifications may indicate that the MSRAP services of the message stores employ transport-level security. The opaque message tokens and any recipient authentication information (for restricted mailing list access, say) are thus visible in the clear only at the endpoints.
Message stores may provide secured MSOAP service to message originators. The originator authentication information is thus visible in the clear only at the endpoints.
RNAQP servers may provide secured RNAQP service to message recipients. The recipient authentication information and the opaque message tokens are thus visible in the clear only at the endpoints.
How should the sender create a message?
See the case study for an outline of the procedures involved.
How should the receiver download a list of notifications?
See the case study for an outline of the procedures involved.
What format should messages have?
Messages are in the same Internet message format as used by SMTP-based Internet mail.