Comments:


Token complexity - 

it has been suggested that tokens might be 
as simple as a five-digit number, and yet still provide adequate 
security for most uses.  However, since only the special "manual"
tokens ever need be seen by humans, it is recommended that
something of the approximate complexity of a Message-Id be employed
in most cases.  And the special manual tokens could be anything
that the developer of a Receptionist client chooses to allow, 
perhaps including user-entered data such as names or dates.


Phased implementation - 

since backward compatibility is an integral part of Receptionist, 
it is envisioned that implementation of the protocol could take 
place in phases, with each user choosing which phase to advance 
their own client implementation to.

The lowest phase might be respond-only, where the only functions
of the client are to monitor outgoing messages and respond
appropriately to any incoming confirmation request messages.

The next phase could confirm only incoming 
messages (not from established correspondents and) bearing any
Receptionist headers.  This keeps the likelihood reasonably low 
of sending confirmation request messages to anyone not already 
set up to handle them automatically.

The next phase could confirm all incoming messages not from
established correspondents.  At this point the "annoyance" factor
would appear - if it is going to. 

The annoyance in this case being
that spam with forged origins might cause the victim of a forgery
to receive a large number of false challenge messages.  Interim phases 
have been proposed to limit or eliminate this problem, among them the
most attractive so far is the proposal to implement a public/private
key system, load the public key(s) in every user machine, and have 
each software vendor keep a private key securely, issuing
an encrypted data block to each registered user as a part of the
software licensing process.  Vendors of all products attempting to
be compatible would want to publish their public keys, and to build
their products to permit the insertion of other vendors' public keys.
Each user's encrypted data block would decode, using that vendor's
public key, to the email address of the registered customer.  
The very existence of a block of text which decodes to that user's 
address is extremely strong evidence that the owner of that address 
is a registered user of RMOP compatible client software, and 
therefore should not be unduly bothered by false challenges.


Actually requiring that a key exchange take place would come
at a still-later phase.  This could easily be done on a per-user
basis, by including a flag on each entry in the whitelist.
And it could be automated to insist on passkeys from anyone
who's exchanged them in the past.

In fact, the keycodes might never really become necessary if 
abusers don't engage in forgery to get around simple whitelisting.

But eventually a phase could be implemented where any incoming 
messages without Receptionist headers are simply discarded.


Website coordination -

One of the initial goals for the protocol was to NOT require any
centralized support to function fully.  However, that doesn't
mean it couldn't add useful capabilities.  In particular, data
distribution, such as to aid a phased startup by giving registered
users a place to confirm whether the observed sender of a message
bearing RMOP headers is also a registered user.  If 3rd-party
verification confirms that the apparent sender of a message is in
fact running a compatible responder, there is little reason NOT
to just send a confirmation request and skip any further message filtering.


Manual Confirmation -

The confirmation request message should include a set of human-readable
instructions, or at least a URL link thereto, and also a complete
copy of the headers of the message being confirmed.  In case
the origin of the message was forged, this would give 
the forgery victim all the info available.


Negative Response -

The recipient of a confirmation request might be given 
the facility to request that the complete initial message be returned.
This feature has not yet been incorporated into the protocol.
It might take a new subtype of the RMOP-Control header.
It seems reasonable for the recipient to discard such a 
message after returning it.  It also seems reasonable not to
care whether the sender identity was forged - if a forgery
victim wants to see the whole message, why not?


Extension to SMTP -

It should be practical to extend SMTP to include a significant
portion of RMOP.  Nothing in RMOP prohibits the same message
from being confirmed at multiple locations along its transit,
but scaling issues might make that a poor choice.  Nonetheless,
if server software developers wished, existing SMTP transaction
commands could be extended by adding tokens.  e.g.:

MAIL FROM <a@b.c> [token]
RCPT TO <d@e.f> [passkey]

===