RMOP Receptionist Mail Origination Protocol A minimal authentication system built upon SMTP Draft 2.7 January 18, 2003 San Mateo, California Bob O`Bob This author suggests that while the term "spam" currently lacks a specific technically qualifiable definition, there are certain types of e-mail which constitute a large portion of "spam" for which technical measures of prevention could be applied. This paper describes a protocol for limiting the end-user impact of unsolicited broadcast e-mail (without attempting to definitively explain that specific terminology). === The Receptionist protocol can greatly enhance the confidence level that an e-mail recipient can attach to the claimed origin of an incoming message. Messages with unknown or unapproved origins can be dropped without taking up user time to even review them. The "heart" of the Receptionist protocol is the exchange of passkey tokens, which tokens can be as simple or as complex as the party generating them desires. A passkey token is, in general, only valid for authenticating incoming messages for the party who initially generated that token. For this reason a first-time contact between parties may require some extra control messages to be exchanged prior to any actual deliveries to the in-box of a user employing this protocol. This is to complete a round-trip authentication for the party attempting to initiate contact. Exceptions to the necessity for round trip authentication via e-mail include scenarios where a conceptual "round trip" has been completed via other media, such as printing a one-time token on one's business card. And of course established correspondence need not generate extra control messages as the passkeys can be exchanged and even replaced within the headers of ordinary correspondence. Another major (and believed unique) feature of the Receptionist protocol is the responder automation. The responder function is to monitor incoming mail for RMOP control messages, and handle them without requiring user intervention. Incoming control messages include confirmation request messages, to which the recipient client will automatically reply when appropriate, and both Responses and Updates, from which the recipient client will record incoming information as appropriate. Under most circumstances a Response control message will also cause the release of one or more prior incoming messages which had been held ("quarantined") pending this reply to an outgoing confirmation request. The Update control message provides transportation for new passkey information along already-established channels of communication. === Aspects of the Receptionist protocol could be categorized according to the types of conversation in which they occur, although there are significant overlaps between categories. Currently envisioned categories are Dialog (two party conversation) Introduction (sender previously unknown to recipient) Broadcast (bulk transmissions authorized by recipient) Group (multi party conversation) === Dialog headers RMOP-Passkey: RMOP-Token: Under most conversational conditions, the Token header will be used to pass a token for use in future messages coming back. These tokens will be supplied back (to their generating party) in the Passkey header. Upon receiving a message with a Passkey header, a Receptionist client should validate it as appropriate against recorded data, in most cases this validation will probably be tied to sender identity, but this is not a protocol requirement. It is permitted to generate sender-independent tokens, and any other specialty features the client may choose to support, such as one-time-use tokens. === Introduction headers RMOP-Control: Challenge [] RMOP-Control: Response [] Upon receipt of a message from an unknown sender, a Receptionist client may respond with a Challenge control message. The challenge will carry a Token header, with a token to be returned. At least until use of this protocol is widespread, the Challenge message must also carry data and instructions for manually meeting the confirmation request. To permit a Receptionist client to do all its work with header data only (e.g., for more efficient POP3 downloads), the manual response must be accomplished through headers. A special one-time token to be returned in the Subject line is one good possibility. Upon receipt of a Response control message, a Receptionist client will examine the Passkey header pretty much as Passkeys are normally used, But if the incoming Response control message is valid, there will probably also be one or more previously received messages held in a quarantine for the sender associated with the key. === Bulk headers RMOP-Keyhash: RMOP-Control: Update For bulk subscriptions and Receptionist authentication to coexist, individual, per-recipient, passkeys are often impractical. However, if a bulk sender chooses to implement Receptionist passkeys, and the recipient is willing to accept them, future passkeys can be generated by the sender (rather than the usual case) and hashes (e.g., MD5) of those future keys can be published ahead of time, either in normal list messages or in Update control messages (or both). A Receptionist client should seek user confirmation (at least once per list) before storing (and thereby accepting) incoming keyhashes. In this way, Receptionist authentication, once established (e.g., through a confirmation message round-trip, as currently practiced by many lists) can propagate itself forward even with the only one-way communication typical of bulk subscriptions. A recommendation for online sign ups is for the user to enter a one-time token on the sender's sign up form or page, with the sender using that token as passkey in an Update control message to serve as round-trip confirmation, and to deliver some number of Keyhash values in advance. === Group headers (to be determined) Group conversation (more than two parties, but not broadcast) should probably employ a mixture of dialog and bulk features. This category is under development. One possible approach, not requiring this specification, is for an e-mail client to expand the recipient list, sending each copy individually with 1:1 dialog headers included, while retaining the headers showing all visible recipients. However, this does not assist the "reflector" type of group e-mail, where a list server of some kind receives messages from multiple participants and subsequently "reflects" a copy out to each. For RMOP to help such situations probably requires that the "reflector" software be revised specifically to support the protocol. === Receptionist headers and their Syntax 1) RMOP-Control Identifies a control message. No human should see a control message received by any compatible client. However at least during phase-in some control messages will require a human processing method of equal functionality Syntax: RMOP-Control: Challenge [] RMOP-Control: Response [] RMOP-Control: Update Notes: Challenge If is omitted from Challenge then In-Reply-To header MUST be present AND bear the of the message to be confirmed. Update The Update control message provides a delivery method for notifying correspondents of changed keys. It is unclear at this early phase whether this message type will actually be required to support the intended functionality. It is, however, clear that Update messages must only be accepted from already-known correspondents, and any others must not be responded to - and especially not challenged. 2) RMOP-Passkey Asserts that the sender has an already-established relationship with the recipient, documented by the enclosed key token. An incoming message with an invalid Passkey would in general be treated as the same message lacking any Passkey. Syntax: RMOP-Passkey: 3) RMOP-Token Provides a transportation mechanism to send a key token for future use by recipient Syntax: RMOP-Token: 4) RMOP-Keyhash Provides a transportation mechanism for a hash of a key token planned for future use by the sender. Assumes the recipient already has a trust relationship with the sender. Given such trust, recipient should store the enclosed hash to use for validation of a future key or keys from the sender. Syntax: RMOP-Keyhash: === RMOP function headers RMOP-Control: [Challenge|Response|Update] [] RMOP-Passkey: RMOP-Token: RMOP-Keyhash: RMOP "housekeeping" headers RMOP-Reference: RMOP-Client-ID: RMOP-Client-Version: RMOP-Sender: RMOP-Control-To: Existing SMTP headers vital to RMOP Message-Id: In-Reply-To: References: [...] Subject: [text...] [text...] === Related Topics which are NOT a part of this specification: Sender - The rules for determining the origin address of an incoming message are complex, involving such headers as From, Sender, Reply-To, Resent-By, and others, and those rules are not a part of this specification. In this document, references may be made to the "sender" of a message, which do not refer necessarily to the content of that specific header, but to the result of those rules, which remain outside the scope of this document. However, when present, the optional "RMOP-Sender" header overrides such other considerations. Whitelisting - It is anticipated that a client implementation of RMOP will maintain a "whitelist" of some kind, and in fact some sort of database or other storage is an implicit requirement of the maintenance and use of the key tokens which are a central feature of RMOP. However most details of the management of such whitelisting are left to the client implementation. It is expected, for example, that any outgoing message will be logged by the client such that replies from that recipient need not automatically generate confirmation request messages. --