| | | Implementation Notes |
This chapter resumes thoughts that should make implementation issues more clear, and point out feasability of the model by example.
Each process in the Message Path is enlisted and corresponding notes and implementation proposals are stated.
Email "Adresses" in an im2000 can take different forms, as they can be implemented by different protocols, several posibilities that come to mind are:
A public directory service, or a directory service provided by the ISP which hosts the mail storage server and is open and hopefully trustworthy to most potential recipients holds the "personal" public key for each member (or account) which is allowed to post messges to that server. Maybe it would be helpful to the ISP, if a key pair is generated for each account when a user registers and handed out to her/him. The user signs the key with his personal "global" key (PGP or the like) to validate it. A user then can revoke the ISP/Mail-related key without impairing her/his personal key. Also the ISP/account key can be handled by other means then a "global" key of the user, thus allowing faster or more efficient handling.
The mail user client signs messages for posting with the private key validated for his/her account. The Mail Storage Server verifies the message and discards it in case it is forged (invalid signature).
Aditional header data may or may not be stored, generated or calculated on demand.
One aproached forsees a message to consist of two parts: header data and body. Various parts of a message consist of various header/body-entities, which are linked together via metadata in the headers.
Qim proposes headerless messages - the traditional headers are only created and used during transmission, required metadata like Sending Host, delivery time, etc. are conveyed via and extracted from the protocols. However collections of various headers are glued together by a "sequence"-number into a so called "block". The interpretation of the first block as a header with metadata about the other blocks is recomended but not required, and is left over to MUA's interpretation - the filosofy behind is, that Sender and Recipient "know" each other and can agree about the contents interpretation. This makes implementation of brokers and mail robots easier and more efficient.
One proposal is to encript an access key (URL) to the message and store it in the header. The notification message only says "hello - message for you at my server". The Recipients MUA authorizes via public key encryption to the sending server, retrieves the encrypted URL, decrypts it and fetches the message via the URL.
Another proposal is, to let the Mail Storage Server generate a per message key-pair, encrypt a Message Identifier and the public part of the key with a public key owned by the Notification Server (host key) - which is esentially a ssh, scp, or ssl-connection. The recipient - or it's mail collection robot - is handed out the Message Identifier against local autentication, and connects (via public-key autentication) to a Delivery Agent at the Mail Storage Server to retreive the message, it does this by showing the Delivery Agent the Message Identifier, encrypted with the per-message public-key.
However, the intermediate encryption process may be dropped. A dumb mail collection robot may retrieve the Message and the Senders public key signature (plain PGP) check the signature and drop the message without notification of the Recipient. The harm of forged Spam would be less than it is in the actual Email System. With this system, the mail collection robot needs either access to the/a private key or another autentication method to avoid message stealing, or the usual trust of users to their ISP-Provider is assumed to be granted and a per Server key allows retrieval of all messages of all users of a particular Notification Server.
While the selection of "valuable" messages in standard Email is a taunting and in practice not acchievable task, because the protocol setup does not provide any means of verifiability and by default "everything" is allowed (unless especifically prohibited), in im2000 we have the option to implement
Next step is verification of Identity, where the first step can be a simple Whitelist of personally known Identities. Each protocoll by itself lends itself to more or less specific tests.
On another level, the notifying Mail Storage Server itself can be blacklisted like in common Spam-RBL aproaches. It can be required, that the IP address of the notifying server must be the same as the retrieval address.
If at last there exists a (cryptographical) proove about a message issued by the sender (digital signature) and coutnersigned by a key known to belong to the transmitting server, there is a high probability that the message to be received is be autentic. This sounds probably dificult but boils down to transmitting a message signature via Secure Copy or a similar existing mecansim.
http has been proposed, as a transport for the message from the Mail Storage Server to the Recipients Computer. However Netstrings and PIRP would be an efficient alternative. But even a simple scp would be sufficient both in efficiency of transmission and in protection of privacy and security of the messages, while http and pirp would need secure chanels to acchieve this effect.
The notification can include information about the particular protocol to use for message retrieval. Note that there are a lot aplications, where information is not considered confidential, such as in News or List messages, and efficiency would rule over encryption methods, while in other context even personal messages would not be allowed to be encrypted because of the legal Situation of the country where the Messages are interchanged, while even there probably a reliable autentication scheme for identification of Sender and Recipient would be tolerated.
This part is mostly about remote or dialup users, which have the Notification Server retrieve and store semi-automatically the messages for them. The Recipient has to establish and assure than a secure conection to the Notification Server for retrieval of the Messages.
Also this part may be trivial by using a Secure Copy scheme, rsync, etc.
In Qim it's almost as easy as delivering an im2000 message to the traditional Email inbox, and let the user pick it up with pop3 or imap.
To comply with the Trust Chain, it is only necesary, that any host on the Internet presents the Recipient Identity and the Message Id to the Mail Storage Server. So a user can "pull" notification messages from the Notify Server to a client machine, and then issue the message collection process from there, for example by (PGP) encrypting the Message Id with it's private key, when presenting it to the Mail Storage Server.
Mailing Lists or News Servers can be set up, by allowing a Retrieve Message from any client computer. The Message Id would have to be replaced by a filter, for example the maximum age of messages the client wants to scan for in the "archive", as well as the category ("Sender Identity"). The "filter" would be (PGP) encrypted by the Recipients private key, and the Mail Storage Server would then send a notify message for each message matching the filter, as if the message would have been posted initially to the Recipient.
On the other hand, the scan mecanism would have to be extended anyway to allow message evaluation before retrieval. It should probably also be able to mark messages as undesired, or update an expiring date to a new value (I'm on vacation-hold the post meanwhile).
A natural implementation of a newsgroup like forum would be to have a list of news-categories in the form of Recipients. Messages sent to this recipients will only be stored, no notification is sent. The Sender Identity is rewriten to be the the new-category "Recipient".
If a Scan operation is performed by any otherwise unknown Recipient, it would be asking for messages to the Recipient, with a Sender Identity of the news-category.
By default, all messages newer then the default expiration time of the news-group will generate a notification to the recipient. The Scan operation could specify also a shorter or greater time range, or even a number of news messages to retrieve. - "twenty newest messages".
In Qim a new im2000 - unix user would be created with the name of the newsgroup instead of "im2000", which just implements the storage function (yet available), plus the Scan function. The normal notification function would not need to be implemented.
Lists can be implemented tecnically like News-groups, but to disclose posting in News groups or in Lists to a known list of Sender Identities would be stored
| | | Implementation Notes |