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.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
