Joshua Teitelbaum 10/06/2000
CryptoMail is intended to be a (tranparently) highly secure and ubiquitious mechanism for users to send messages to each other. CryptoMail is also intended to be a highly scalable, easily extensible application framework.
There are six major entities within the CryptoMail Application Framework:
1) The Client:
The client's job is to establish a secure communications channel with the Web Server that is hosting the CryptoMail Application. It performs all mail related requests, not much unlike an IMAP or POP email client. However, in this case, the underlying protocol is SeXMAP, or Secure XML Message Access Protocol. This protocol extends XMAP, or XML Message Access Protocol.
2) The Web Server:
The Web Server will serve web pages and receive and forward SeXMAP requests from the Client to the CryptoMail Application. The Web Server will also take the output of the CryptoMail Application and forward it to the Client.
3) The CryptoMail Applications:
The CryptoMail Application will take SeXMAP requests from the Web Server, process them by accessing the appropriate CryptoMail MetaBase and CryptoMail DataBase servers, and then return results back to the WebServer, which returns them to the Client. The CryptoMail Application will also take its input from the MTA when incoming mail is put into the system.
4) The Mail Transer Agent (MTA):
The Mail Transer Agent will process incoming messages intended for CryptoMail Users and input them into the CryptoMail System by way of some sort of programmatic alias.
5) The CryptoMail MetaBase Server:
The CryptoMail MetaBase Server is a store that maps users to their respective CryptoMail DataBase "home". The CryptoMail Application is the only entity which directly engages in discourse with this entity.
6) The CryptoMail DataBase Server:
The CryptoMail DataBase Server is a store that holds all mail and directory information for users. The CryptoMail user base is physically partioned by users. That is, Alice may have a different physical "home" than Bob. The CryptoMail Application is the only entity which directly engages in discourse with this entity.
The goal of CryptoMail is to employ two types of security while performing email related activities:
Session security is achieved when the Java Client negotiates and uses a blowfish key with the server, while Message Security is achieved by employing a hybrid (Symmetric/Asymmetric) encryption scheme. The algorithms for all these tasks are found here. It is worthy to note that all messages are stored encrypted on the server, so in the event unauthorized access to the server is obtained, only the encrypted form of the messages will be available. Unfortunately, the un-encrypted external messages sent to mailboxes that originated from outside the CryptoMail domain will be readable by an attacker, however, there may be extensions that can thwart this.
The protocol between the Java Client and the CryptoMail Application objects employed is called XMAP or XML Message Access Protocol. It was designed to be a subset of the functionality put forth by the IMAP specification. Although IMAP is verbose and rich in functionality, XMAP was created because IMAP was intrinsically stateful, and relatively hard to parse. With the plethora of XML parsers being made available to programmers both in binary and source form, and the straight-forwardness of XML's structure, XML not on in this application, but in general, is proving to be a worthwhile protocol vehicle. CryptoMail's MySQL version employs Jim Clark's XML parser (expat).
The CryptoMail Java Applets compose CryptoMail Messages which are Secure XMAP Messages over HTTP. The Secure XMAP Messages, in turn, are really XMAP Messages. The XMAP Messages are the IMAP like primitives composed of things like: "List all my folders", "List the contents of folder 'Inbox'", "Create a folder named 'foo'"...
It is worthy to note that SeXMAP Messages are encrypted binary blobs with HTTP headers that carry the session information (think cookies). These blobs are "POSTED" to the web server using the Java URL object suite.
The CryptoMail Datastore employs the MySQL Database. The MySQL CryptoMail application suite is composed of a set of executables that employ the MySQL C-Client Database Access Library. Database record traversal, insertions, and deletions are doing with this API. All information about a user is located within the CryptoMail database. There are actually two databases: The MetaBase, which stores the name to a particular user's data home, and the CryptoMail Database , which stores user's data homes. The CryptoMail applications use the database as a file system, but never directly use operating system's file system to store information. I am sure much discussion has gone into why or why not using the operating system as a file system is or isn't a good idea for the basis of an email messaging system. Here, I offer some reasons for using a database instead of the local file system.
In employing the local file system as a message store, mailboxes can either be done in a file-per-message format or all messages go into a single file per mailbox. Other configurations may be possible, but let's just assume these two.
Employing a file per message scheme is a fast solution, but when lots of clients are opening lots of files, one may find the system opening lots and lots of file descriptors, and consequently use too many resources negotiating all those open files.
Conversely, employing a single maildrop for multiple messages may solve the file descriptor problem, but one needs to construct an efficient way to seek to different messages. If the messages are in sequential order, and the file is large, then parsing the offsets and other information of all the messages mandates that the file be traversed in its entirety. This process may be slow, especially if some messages reach megabytes in length. To exemplify this, try pointing an IMAP server to a 100MB Inbox with 666 messages. Listing of this Inbox on a Pentium 166 probably would be classified as "stony" at best.
This is where databases come into play.
If one employs a database as a hierarchical message store, seeks to messages can be done with indices, which can be completed in constant or logarithmic time. Furthermore, the number of active and open file descriptors is determined by the number of active database connections, which can easily negotiated.
Thus, given the speed, the administrative ease of use, and pervasiveness of databases, a database was chosen as the CryptoMail message store.
MySQL was chosen because of it's open source stance, proven C-Client API, and it's pervasiveness.
CryptoMail uses the functionality of Sendmail to put messages into the message store. This works in the following way:
Another way to do this is to get Sendmail to use the CryptoMail MailDrop executable as a mailer, but this may take some wizardry. The path of least resistance is the user mapper :)
CryptoMail may not have all the functionality that you want in a mailer, or all the functionality you want in a message store. That is why it is being developed as an open-source project. Furthermore, as a product which professes security, CryptoMail.org is obligated to disclose the source. The main goal of this system is to bring a basic, ubiquitous user interface to a highly secure mail system, and We at CryptoMail.org believe in preserving an individual's right to privacy. We hope that congruous minds will help take CryptoMail to the next level.
Joshua Teitelbaum 10/10/2000