Changes between Version 2 and Version 3 of xhmtp


Ignore:
Timestamp:
Feb 19, 2008, 5:31:45 PM (10 years ago)
Author:
dkg
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • xhmtp

    v2 v3  
    1 = alice@A sends message to bob@B (and cheryl@C...) =
    2  1. alice MUA sends message to server-a.A
    3  1. server-a authenticates sender
    4  1. server-a generates message identification string ($ID)
    5  1. server-a stores message in alice's message queue, labeled $ID
    6  1. server-a generates message access code string for each recipient ($RS_B, $RS_C...)
    7  1. server-a stores the following in notification queue: (bob@B, $ID, $RS_B) ; (cheryl@C, $ID, $RS_C) ...
    8  1. server-a does ''srv'' lookup '''_xhmtp._tcp.B''':
     1= XHMTP =
     2
     3This is a project to try to define (and implement) an asynchronous messaging protocol capable of supplanting SMTP, without adopting any of SMTP's more noxious characteristics.  Yes, that's ambitious.
     4
     5== Goals/Principles ==
     6
     7Not all of these goals are met, unfortunately.  Nonetheless, they're the goals.
     8
     9 * reuse existing infrastructure and well-known protocols
     10 * costs of sending should be borne by the sender; avoid recipient-pays situations as much as possible
     11 * integrated strong cryptographic support (including message integrity, verifiable authorship, and privacy)
     12 * anonymous messages should still be possible (though they may be discarded by per-user policy)
     13 * avoid centralized or hierarchical authority
     14 * individual agents should be able to pool resources to participate
     15 * individual agents should not ''need'' to share resources to participate
     16 * universal connectivity: no walled gardens
     17 * robust to failures of systems involved
     18
     19== Basic Assumptions ==
     20
     21 * asynchronous messaging happens with a single sender and 1 or more recipients.  These are the messaging endpoints.
     22 * the endpoints may be humans or software
     23 * endpoints have well-connected agents that may act on their behalf.  These agents are online more reliably than the endpoints themselves.
     24
     25== Example messaging lifecycle ==
     26
     27This describes the steps taken during the transmission of a single message.  The message is sent by a human (`alice`) who belongs to or controls a domain (`A`).  We can call the sender `alice@A` as shorthand.  The message's recipient is `bob`, who belongs to domain `B`.  We can imagine the message also going to `cheryl@C`.
     28
     29Each domain (`A`, `B`, and `C`) offers a server that is better-connected than the relevant endpoints.  We'll call the server for domain `A` `server-a.A`.
     30
     31=== Message Injection ==
     32 1. alice's MUA sends message to `server-a.A` (how? HTTP POST?  [WikiPedia:Mail_submission_agent submission]?)
     33 1. `server-a` authenticates sender according to user/domain-specific policy.
     34 1. `server-a` generates message identification string ($ID)
     35 1. `server-a` stores message in alice's message queue, labeled $ID
     36 1. `server-a` generates message access code string for each recipient ($RS_B, $RS_C...)
     37 1. `server-a` stores the following in notification queue: (`bob@B`, $ID, $RS_B) ; (`cheryl@C`, $ID, $RS_C) ...
     38
     39=== Message Notification ===
     40`server-a` takes an item out of the notification queue and attempts to notify the agent of the recipient endpoint.  In this example, we assume that the item selected is (`bob@B`, $ID, $RS_B):
     41
     42 1. server-a does ''srv'' lookup '''_xhmtp._tcp.B''', which returns:
    943{{{
    10 _xhmtp._tcp.B hostname port
     44_xhmtp._tcp.B server-b.B 80
    1145}}}
    12  1. server-a does ''txt'' lookup '''_prefix._xhmtp.B''':
     46 1. server-a does ''txt'' lookup '''_prefix._xhmtp.B''', which returns:
    1347{{{
    14 [prefix_string/]
     48XYZ
    1549}}}
    16  1. server-a does http post to: http://server-b.B/[prefix_string/]bob@B which includes the following:
    17   * message url: http://bob%40B:$RS_B@server-a.A/.*/alice/$ID
    18   * message headers
    19  1. server-b extracts hostname from message url in post, and checks DNS A record against server-a
    20   * uses standard http return codes for notifications
     50 1. `server-a` does HTTP POST to: `http://server-b.B/XYZ/bob@B` which includes the following:
     51  * message url: `http://bob%40B:$RS_B@server-a.A/.*/alice/$ID` (note the HTTP basic auth password in the domain part)
     52  * message headers (what are permissible?)
     53 1. `server-b` extracts hostname from message url in post, and checks DNS A record against `server-a`
     54  * uses standard HTTP return codes for notifications
    2155  * possible per-user filter strings (whitelists, blacklists, etc.)
    22  1. server-b generates RSS feed for message for bob
    23  1. bob gets RSS from server-b
    24  1. bob gets message from server-a
     56  * the IP address of the "message url" should match the IP address of the connecting notifier
     57 1. `server-b` generates RSS feed for message for `bob`
     58
     59=== Message Fetching ==
     60 1. `bob` requests RSS feed from `server-b`
     61 1. When/if `bob` wants to read the relevant message, his RSS reader retrieves it from `server-a`
     62
     63
     64== Other links ==
     65
     66 * [http://cr.yp.to/djb.html Dan Bernstein]'s ill-fated [http://cr.yp.to/im2000.html Internet Mail 2000] proposal
     67 * [http://marnanel.livejournal.com/1090509.html Marnanel's suggestion of IMAP over REST]