| | | Upgrading Qim |
This appendix discusses changes and extensions to the existing Qim server to make it comply with several requirements of the im2000 concept.
Qim uses a normal unix user and Qmail's extension mecanism to post messages, notifications and to retrieve messages from the mail storage.
A user has to PGP sign messages, to post them to the Qim mail storage server. The server (im2000-user) check the signature against a keyring. If the corresponding public key is not on the ring (or the signature is invalid) the post is rejected.
This approach allows creating Qim-users by adding their public key to the im2000-users keyring.
To speed up things, a key-lookup can be issued and the public key of the recipient stored in the im2000-Recipients keyring
qmtpssh can be used to transmit notifications to a notification server. This eliminates MX name lookups, but requires for each Qim storage/notification server pair to be set up to recognize each other - a key exchange has to take place.
It could be thought of putting special TXT records in DNS, which publish the im2000 server's public host key and the im2000 users private (!yes) ssh-key, for "anonymous" remote login. Look at anonymous CVS login via ssh to get the picture.
The Message Id is encrypted with the Recipients public key.
Actually, collection is done by the MUA via a reply to the notification message. The Recipient has to sign the reply with his/her private PGP key.
The Mail Storage Server has the key already on the keyring, verifys the collection message and sends the body to the original Recipient address via the same qmtpssh channel.
Is accomplished by local delivery, imap-ssl, imap, pop3d, or whatever standard MTA/MUA scheme is used by the receiver. The message should not be forwarded via other standard Email-servers.
To allow protocol distinction and convey information about sequence numbers of a message block, the Subject: field of notification messages should comply to this form:
| | | Upgrading Qim |