frmailaccount

Maintainer: Messaging Team (messaging-team@zks.net)
$Revision: 1.3 $
$Date: 2000/07/21 23:24:56 $
$Author: roger $

Nyms all need to have valid e-mail accounts which can send and receive e-mail. An "account" comprises:

  1. the ability to send and receive e-mail
  2. space in the mail system to store mail they receive
  3. the configuration parameters relevant to the services to which the account is entitled

When a nym is created, we have to grant it the right to send and receive mail. We don't necessarily have to grant it space in the mail store until it first receives mail. So, broadly speaking, after a nym's mail account is first created we need to be able to recognize that the nym is a valid recipient of mail so that we can either locate or create its mail store area upon receipt of the first piece of mail to the system.

goals (in order)

  1. simplicity: if it can be explained in a couple minutes, we can hire more people to work on it. if it can't, we tie the original creator to maintaining it.
  2. robustness: it must always work even when the system is mostly broken
  3. scalability: 2 million users must be "real easy"
  4. independence: should communicate with as few other parties as possible. preferrably none
  5. efficiency: only of medium concern. it has to be fast enough that a lookup works inside a qmail-local delivery process

adopted approach

  1. by assumption, a user can authenticate to the mail system without the mail system storing any information specific to the user. the user authenticates using an authentication token signed by the PKI system, which shares secrets with the mail system.
  2. a user account in the mail system is defined exactly as a directory on a disk under the mail system's control with the user's nym as its name. that is, the phrase "user bob has an account in the mail system" can be rephrased "the directory /path/to/mailboxes/bob exists and contains a Maildir", without losing any meaning.
  3. accounts are created by the pop3 daemon upon authentication, if they do not already exist
  4. mail cannot be delivered to an account which does not exist. by definition, this means if there is no directory for a user, their mail will bounce
  5. therefore the client has the responsibility to contact the pop3 daemon on activation of a nym, to guarantee that the account (== directory) is created. if the client fails to do this, nobody will be able to send mail to the nym, even if the nym themselves can send mail to others. this asymmetry must be avoided. we put the creation responsibility in the pop3 daemon primarily because it must stat() the user's directory anyways during a pop pickup, so it must have access to the Maildir disks. the ESMTP daemon does not need direct access to the Maildir disks, so should not have responsibility for creating user directories.
  6. deleting a directory deletes the account, by definition, and that is it. if a user is to be banned from using the system permanently, authentication must fail as well. if the user re-authenticates, the pop3 daemon will simply re-create a directory for them
  7. to mitigate the thread of a deleted user re-creating themselves, we will have a block list which spans the temporary gap between deletion of an user and the natural expiry of their authentication token

Creating an Account

When the PKI system creates a nym on behalf of a client it uses the nym's mail information to construct a certificate for the nym. Refer to the Mail Certificate design document (../../frmailauth/doc/mail-cert.html) for more details on the format of the certificate. It also uses the secret key it shares with the mail system in order to create a secret MAC key to be shared between the nym and the mail system. Refer to Shared Nym-Mail System MAC Key (../../frmailauth/doc/nym-mac-key.html) for more information. Both the certificate and the MAC key are returned to the client along with the other nym information. The PKI system has no further need for the MAC key, so it can be deleted after transmission.

Given the certificate for the newly created nym, the client then attempts to authenticate itself to a Freedom POP server. Using the secret shared between the mail and PKI systems, the POP server authenticates the nym. If the nym proves to be authentic, then the server validates the presence of the nym's mail directory. If no mail directory is present, one is created (at this point the mail system could optionally send a welcome message to the nym).

What an account looks like

An account consists of a directory holding per-user config files as well as a Maildir, which is a directory multiple writers can write messages to concurrently, and is crashproof over NFS. The location of the account directory is calculated as:

    h = (32_bit_hash( nym_name ) >> 4) & 0xFFFFFF
    a = hex( first octet of h )
    b = hex( second octet of h )
    c = hex( third octet of h )

    mail_dir = ${ACCOUNT_ROOT}/a/b/c/nym_name/Maildir

The per-user config files we'll store are:

  1. non-default quota settings
  2. block list
  3. spam filter selection
  4. smallest valid password version (maybe)
  5. a .qmail file speficying delivery policy
    {It would be even better if they all shared a .qmail file}

We don't want each user to have a UID so we can use Paul Gregg's method of hosting an arbitrary number of mail accounts from a single mail system user id.

See: http://www.tibus.net/pgregg/projects/qmail/single-uid-howto.html

We don't need the password file to map to user directories or to tell the POP server that the password should be. qmail-local receives knowledge of these directories by delegating to our replacement version of qmail-getpw (see authentication section). you must remove any default entries in /var/qmail/users/assign so that qmail-local will call out qmail-getpw, otherwise you will get serious mail bouncing.

Changing the certificate

(Optional)

While we do not have an immediate requirement to do this, one way to do this would be to have the mail system remember the largest certificate version it has seen for the nym (this is mentioned at the end of the preceding paragraph). To get a new certificate, the nym could authenticate itself to the nym server, which would give it a new certificate having a higher version than the previous one. When the nym authenticates using the new certificate, the mail system updates the version stored in the nym's mail directory. If a nym tries to authenticate itself using a certificate version lower than the one stored in the version file, the authentication is rejected as invalid.

Dependencies

See also:


Copyright © 2000 Zero-Knowledge Systems Inc.
All Rights Reserved