[Cryptography] Functional specification for email client?

[Ray Dillinger]

Okay...

User-side spec:

1.  An email address is a short string freely chosen by the email user.
     It is subject to the constraint that it must not match anyone else's
     email address, but may (and should) be pronounceable in ordinary language
     and writable with the same character set that the user uses for writing.
     They require extension with a "domain" as current email addresses do,
     but not a "domain name" in the IETF sense; just a chosen disambiguator
     (from a finite set of a million or so) to make name collisions less of
     a problem.

2.  An email user may have more than one email address.  In fact s/he can
     make up more email addresses at any time.  He or she may choose to associate
     a "tagline" -- name, handle, slogan or whatever -- with the address.

3.  When an email user gets an email, s/he is absolutely sure that it comes
     from the person who holds the email address listed in its "from" line.
     S/he may or may not have any clue who that person is.  S/he is also
     sure that no one else has seen the contents of the email.  The "tagline"
     and email address are listed in the "from:" line.

4.  A user has an address book. The address book can be viewed as a whole or
     as seen by just one of the user's email addresses.  IOW, if you have an
     email address that you use for your secret society and a different email
     address that you use for your job, you can choose to "be" one or the other
     and your address book will reflect only the contacts that you have seen
     from that address or have been visible to under that address.

5.  A mail client observes all email addresses that go through it.  When a
     user receives mail from someone who has not directly sent them mail before,
     the client opens a visible entry in the address book and makes available
     a record of previous less-direct contacts with that address, for example
     from posts to mailing lists, from CC: lists on emails, etc.  The client
     also makes visible a list of possible contact sources; places where the
     correspondent may have seen the address s/he's writing to.  However, often
     enough, especially with cases where it's a "scribbled on a napkin" address,
     the client just won't know.

6.  When a user sends mail, s/he knows that no one other than the holder of
     the address/es s/he's sending it to will see the body of the mail, and also
     that the recipient will be able to verify absolutely that the mail did in
     fact come from the holder of the user's address.

7.  Routing information once obtained for a given domain is maintained locally.
     This means routing information for each email address is public knowledge,
     but also means that no one can tell from your address queries who specifically
     your correspondents are more precisely than knowing which domains they are in.
     This also means that other users may obtain routing information for that
     domain from you. You can update your routing information (ie, set the system
     to route messages for your address to the network location where you actually
     are) at any time, via a message propagated across all peers serving the domain
     of that address.  Also, your client "keeps your addresses alive" by periodically
     sending out a message that is propagated across all server peers for that domain.
     This happens at intervals you set (a few months to ten years) when you create
     the email address.  If that interval goes by without a keep-alive or a routing
     information update, the servers will drop the address.

8.  Emails are "mixed" on your machine locally, then sent out onto the network.
     The "mixing" means creating packets of a uniform size, planning a route for
     each, encrypting them once for each 'hop' on the route, and sending them.
     Routing is constrained to average less than ten 'hops'.  The packet size
     should be selected so most text emails are one packet or less.  Larger messages
     will be sent as a set of packets and reassembled at destination.  Packets will
     be released at a rate of one every few seconds; very large file attachments
     may take days to send and are discouraged.

9.  Your machine, while connected, is collecting your email.  It is also in the
     business of packet forwarding:  ie, it gets a packet, decrypts it, reads the
     next hop, waits some random number of seconds, and sends it to the next hop.

10. Finally, your mail client will occasionally create one or more packets and
     send them via some randomly selected route to another point on the network,
     where they will be received and ignored.  It will do this just about as
     often as it sends original content-bearing packets, and about five percent
     as often as it forwards packets.  This generates 'cover traffic' equal to
     about three quarters of the total network volume. Generation and receipt
     of cover traffic is completely invisible to the user.