This document describes a protocol for a distributed-server communication system, tentatively called FMTP (Flexible Message Transfer Protocol).

The types of messaging this protocol could support include:

• Email
• Instant Messaging
• Blogging/Public Forums
• Chat Rooms
• More?

Architecture

• An FMTP system is distributed and scalable. Anyone may run a server, provided it has a name that can be resolved. Much of this mechanism is identical to an SMTP system. A major difference from SMTP is that data may be requested as well as delivered. Additionally, an 'ideal route' may be negotiated.

Objects

• FMTP defines data as discrete objects. A user is an object, as is a server, an email, etc. Each object has attributes that define it. Listed are some objects and properties:

  Object	Property	Description
  All Objects
  	ENCRYPTED-KEY	Decrypt this with the key retrieved from a DNS lookup on the domain. It contains both the key and the user address
  	HASH	Decrypt this with the decrypted key. It contains a hash of the message body.
  User
  	ADDRESS	username@domain
  	GIVEN-NAME	User's first name
  	FAMILY-NAME	User's last name
  	...	other contact data, perhaps including quote and reference to avatar image
  	BLACKLIST	Space-separated list of address patterns (wildcard/regex?) that messages are never accepted from
  	WHITELIST	Space-separated list of address patterns that messages are always accepted from. Supersedes blacklist
  	POLICY	How to treat addresses not in either list: Accept, Reject, confirm, ???
  	FORMAT	List of accepted formats. HTML, attachments, inline images, ???
  	ENCRYPT-POLICY	Required, optional, none
  	ENCRYPT-METHOD	Encryption name, and info needed. RSA mypublicencryptionkey, for example
  	STATUS	Online, offline, away, etc

Route negotiation

• The user and host objects include a description of the best way to make contact, including hostname or IP, port number, and protocol (TCP/UDP). When communicating with an object, the first step is to retrieve the object and its properties. This can be done in the following ways:

• Local Cache
  • Perhaps we've looked up this object recently
• Parent Cache
  • If we are in a hierarchal organization, perhaps our local server has looked up this object recently
• Domain
  • Connect to the MX server of the target domain, and retrieve the object
• Parent Lookup
  • If we cannot connect directly to the target domain, we can ask our parent to look up the object for us.

  BROnce we have the object, it will tell us the best way to make contact. The following methods may be used to connect to a known object:

• Recommended
  • Connect in the way the object describes
• Domain
  • If the object cannot be contacted directly, connect to the domain's MX server.
• Parent
  • If you cannot connect directly to the target domain, we can ask our parent to deliver our message.

Messages

• Messages can describe objects, or request objects. As an example, a client might request the user object of each 'buddy' when it starts up. The response would include online/busy status. The client may also send its user object to each online buddy when the online/busy status changes.

Public Objects

• Objects marked as public will be freely given to anyone who asks. Public status is ideal for blogs or bulletins, as well as shared files etc. A list may be obtained, showing all available public objects.

Abuse Prevention

• An encrypted hash will be sent with each message to verify it. To prevent monopolization by a single controlling entity, DNS will be considered authoritative. A DNS query to the target domain will retrieve the public key, for decrypting the hash. I don't recall the name, but somewhere I read a well-written description of this method intended for use with SMTP. A question - When a client with no resolvable name connects directly to another, how do they verify?

Threads, or object relation

• Multiple objects may be related such as emails and replies, all the messages in a chat session, a blog and its comments, etc. Each object will be given a unique ID when it is created. The ID, combined with the user address (1239583738491.user@domain) should be universally unique. Probably based on a timestamp and perhaps another nonce. Each object may have a parent attribute, specifying the object ID that it is linked to. For example, a reply will have the original message as its parent. For different uses, the parent might be the immediately preceeding object, or the toplevel object of the thread. Perhaps both a parent and a top attribute would be handy?

Example conversation (in plain english)

• For this example, we have two machines (Poe.net and Lenore.org) which have

  users (edgar@poe.net and lost@lenore.org). Edgar@poe.net wants to send a message to lost@lenore.org.

1. Poe.net checks its cache for lost@lenore.org, but does not find it.

2. Poe.net looks up the MX record for lenore.org, and finds mail.lenore.org
3. Poe.net looks up fmtpkey.lenore.org, and caches the public key
4. Poe.net connects to mail.lenore.org
   • Poe: Hi, I'm poe.net. Here's my hash.
   • Lenore checks its cache for a poe.net public key, but does not find it.
   • Lenore looks up fmtpkey.poe.net, and gets the public key.
   • Lenore verifies the hash
   • Lenore: Nice to meet you, poe.net. I am lenore.org. Here's my hash.
   • Poe verifies the hash

   • Poe: Do you know lost@lenore.org?

   • Lenore: This is lost@lenore.org. Connect to lost.lenore.org, port 8000 tcp

5. Poe now has lost@lenore.org, and attempts to connect to lost.lenore.org

6. Poe cannot reach lost.lenore.org, so reconnects to mail.lenore.org
   • Perhaps connections could be left open, either for a time period or until a connection limit is reached.

   • Poe: This is edgar@poe.net

   • Poe: Here is a message for lost@lenore.org from edgar@poe.net

   • Lenore: Thanks.

7. Lenore uses an existing logged-in connection from lost@lenore.org

   • Lenore: This is edgar@poe.net

   • Lenore: Here is a message for you from edgar@poe.net

   • Lost: Thanks.