Answers to Dan Bernstein's questions

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:

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.

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.

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.

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