Re: IM2000: what it is and isn't

TFBW> Slight correction: the sender knows which entities have
TFBW> *fetched* the mail, not whether they read it. 

Another good counterpoint ... that I forgot to mention.  (-:

TFBW> IM2000 does not address the issue directly, but it does 
TFBW> offer a firmer foundation than SMTP for an authentication 
TFBW> layer. 

One could certainly extend MSOAP/RNASP/RNAQP with more information in
envelopes and notifications (and they are designed to be extensible in this
manner) such as a token provided by the originator that the recipient (or the
recipient notification agent) could use to prove the originator's "identity". 
And, indeed, some people may choose to refuse all mail that doesn't come from
someone that they already know.  However, it should be only an option that can
be added to IM2000 by those who want it, since it is a false foundation for
the actual underlying design.  First:  It is based upon the flawed notion of a
perfect web of trust, which is of course a fool's dream.  Second: _Other_
people _want_ to receive mail from people that they have never heard of and
whose identity is completely unknown to them, so the mail system design should
account for their needs too.

TFBW> An SPF-like authentication system for IM2000 would restrict
TFBW> associations between message originators and IM2000 message
TFBW> stores.

It would do better to restrict the associations between RNASP clients and
message stores.  (As I said in a previous message: "Why would one accept a
message notification claiming that there's a message at AOL's message store
from anything other than AOL's designated RNASP client IP address(es)?")

Tying _originators_ to specific message stores is either redundant or a poor
idea, depending from which aspect of an originator one is tying.  If one is
tying the envelope "source" aspect of an originator to a specific message
store, then this is redundant, because the envelope "source" identifier for an
originator _already_ comprises the message store at which the originator holds
an account.  If one is tying the originator's mailbox name to a specific
message store, then that is a poor idea, since that is the originator's
identity _as a recipient_.  It need not have any relation to a message store,
and should not have such a relation if we want to preserve the principle of
allowing people to shop around for their services and obtain different
services from different providers.

This is touched upon in the "Bill and Ben" case study.