(introduction) E-mail whitelisting systems can provide relief from "spam" mail in a way which does not depend on the content of any of the messages. It is my belief that such measures are or will soon be entirely necessary for any individual to be able to make use of e-mail. Users will require at least a small amount more computer "intelligence" at the user end, whether on the user's own machine or on that of their service provider, incoming messages will need to be compared to *individual* preferences for delivery. Trivial whitelisting features are already available from several major providers, such as AOL and Hotmail, but these currently leave the user closed off from e-mail contact by anyone they don't add to their lists. This requires that any new correspondent make "out of band" contact with the recipient first. It is as if a homeowner were to give door keys to their friends, but then have no doorbell which others could possibly ring, and not listen for knocking, either. Anyone not already known to the homeowner is unable to visit without first making arrangements by some other method, such as a telephone. Initial steps toward allowing in-band first-contact have included "challenge/response" systems, such as TMDA, and several others which use website-based "humanity tests" in an attempt to prevent senders from creating systems to automate passing the tests. This way only "humans" can successfully ring the bell to attract the homeowner's attention to the door. But some humans will consider such "jumping through hoops" to be an onerous task. From over six years of studying the spam problem, it is my considered opinion that such tests are themselves a problem. And that creating a facility expressly for automatically taking those tests is a much better answer. While it is certainly true that any system which permits abuse is likely to be abused, sooner or later, an abuser cannot pass through an all e-mail challenge/response system without exposing their own e-mail address and confirming receipt of a message there. It then becomes trivial for the recipient to block that address, as well as easy to report the abuse to an appropriate provider. So I concluded that the element which can complete the whitelisting solution is an in-band method for "knocking", and this need can be satisfied by a challenge/response method designed specifically to *permit* automation - a protocol. + sender transmits initial message (to NON-established correspondent) + recipient system fails to find sender on whitelist, replies with a challenge + sender system recognizes the challenge, compares it to outgoing log of message-ids, (since it is found) replys to meet the challenge + recipient system recognizes the response, whitelists sender, delivers initial message to recipient user's mailbox Any number of whitelisting and/or challenge-response systems can interoperate freely if a protocol standard is designed for them to follow. Of course, the simplest form of whitelisting system is extremely vulnerable to the simplest form of forgery, i.e., forging the spam to appear to have been sent by a correspondent of the victim, or even the victim. Legislative "solutions" might work, but clearly could be too slow, so the protocol provides facilities right from the start to render such forgery ineffective. Most transmissions include two "token" string, one for the recipient's future use in return mail, one as a key, asserting that the recipient previously sent that key (as a token) to the sender. A trivial configuration change in a client program determines whether to insist on the presence of a valid key or not. Such tokens may be vulnerable to various forms of eavesdropping, but little else, and are far simpler than alternatives like public-key encryption and also don't rely on any central "authority" to issue keys - each user is the sole authority for keys used to gain access to that user's in-box. "My in-box, my rules." Bob, 19 Jan 2003 === RMOP Receptionist Mail Origination Protocol A minimal authentication system built upon SMTP Draft 2.11 August 10, 2005 San Jose, California Bob O`Bob This author suggests that while the term "spam" currently lacks any widely-agreed-to specific technically qualifiable definition, there are certain types of email 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 email (without attempting to definitively explain that specific terminology, other than by example). === The Receptionist protocol can greatly enhance the confidence level that an email 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 email 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 Challenges, 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 Challenge. The Update control message provides transportation for new passkey information along already-established channels of communication. Additionally, the Receptionist protocol has been extended to include additional anti-forgery measures, to dramatically limit the potential for inappropriate challenge messages being sent to victims of origin forgery. === 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) Authentication (sender previously unknown to recipient) Promise (helps assure recipient that any challenge messages issued would be handled automatically) Broadcast (permit bulk transmissions if authorized by recipient) Group (facilitate authentication in 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, specifically including one-time-use tokens. === Authentication 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 challenge. To permit a Receptionist client to do all it's 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. === Promise headers RMOP-Registration: : RMOP-Hashcash: :@: To limit the potential for challenge messages themselves becoming abusive, such as in the case where the origin of a junk message is forged, a message may carry a "Promise" header. The claim of this "promise" is NOT the legitimacy of the immediate message, but instead the willingness of the stated origin to accept challenge messages and respond appropriately. For the preferred form of promise header (proof of registration) the content consists of text which the individual user will obtain from the vendor of their client software. The ciphertext will be prepared by that vendor and when decripted, the plaintext version will include the registered user's email address. The public portion of all vendors' encrytion key pairs will be distributed as part of any client software package, and the public key hash also provided on the header will assist the client software in determining which public key(s) to use for the decryption attempt. Additionally, to support the distribution of a "free" client, not based on registration with any vendor, the alternative form of promise header consists of an extension to the already-demonstrated "hashcash" technology (which bears at least some similarity to crytographic tokens in that it is easy to verify while being substantially more difficult to create). The "forward" hash in the promise header is expected to be consistent with previous hashcash implementations. This is extended by the addition of a second, "return" hash, which also incorporates the hash portion of the forward hash as the beginning of the generated portion of a hashcash using the return address for the challenge message. Computing more than one hash (actually partial-hash collisions) has been shown to be computationally somewhat more consistent. The average amount of cpu work necessary to compute two partial hash collisions of size "n" is comparable to that of computing one of size "n+1", but the variance is less. Note: an alternative mechanization currently under study is to adopt the already defined "X-Hashcash" header without major modification to carry the forward hash, using an RMOP-specific header for the reverse hash only. === 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 additional header types, is for an email 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 email, 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 challenged message. 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-Drop: yes RMOP "housekeeping" headers RMOP-Reference: RMOP-Client-ID: RMOP-Client-Version: RMOP-Sender: RMOP-Control-To: RMOP "promise" headers RMOP-Hashcash: :@: RMOP-Registration: : Existing SMTP headers vital to RMOP Message-Id: In-Reply-To: References: [...] Subject: [text...] [text...] === 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 challenges. The next phase could add issuing challenges only to incoming messages (not from established correspondents and) bearing any Receptionist headers. This keeps the likelihood reasonably low of sending challenge messages to anyone not already set up to handle them automatically. The next phase could challenge all incoming messages not from established correspondents. At this point the "annoyance" factor would appear - if it is going to. 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 challenge and skip any further message filtering. Manual Challenge - The challenge 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 challenged. In case the origin of the challenge message was forged, this would give the forgery victim all the info available. Negative Response - The recipient of a challenge for a message might be given the facility to request the complete 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 challenged 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 [token] RCPT TO [passkey] === 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 an 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 noted by the client such that replies from that recipient need not automatically generate challenges. --