Glossary

APOP: RFC 1939, POP3, defines the APOP command. This is an alternate method for authenticating the user which, rather than sending the username and password in the clear over the network, encodes the password.

Authentication mechanism: An authentication mechanism is a particular method for a client to prove its identity to a server. APOP, PLAIN and CRAM-MD5 (mechanism names are as defined by RFC 2222, SASL), are examples of authentication mechanisms. Another, but non-standard, mechanism is the LOGIN mechanism. For discussions of particular mechanisms, see for instance RFC 2195 documenting CRAM-MD5, and RFC 1939 documenting APOP.

Authentication source: An authentication source is a file, database, interface to an LDAP directory, etc., accessible to the server wherein are stored authentication verifiers for users. The system password file, PMDF user profile passwords (PMDF MessageStore or PMDF popstore profile passwords) and the PMDF password database are examples of authentication sources.

Authentication verifier: An authentication verifier (e.g., password) is stored on the server and contains information used to verify a user's identity. The format of the authentication verifier can restrict which mechanisms can be used. The term authentication verifier is preferred in place of password, since while passwords are the most common instance of authentication verifiers, an authentication verifier could also be something like a certificate in an LDAP directory or the like; usually, however, one can think "password" wherever one sees "authentication verifier".

Certificate: In the security context, a certificate is a guarantee, signed by some trusted authority, that says that a piece of information is what it purports to be. For instance, certificates are often needed and encountered when using a public key pair.

Certificate Authority: A Certificate Authority is a recognized, generally well-trusted authority that is willing to sign other organization's certificates. A Certificate Authority has a well-published certificate (containing their public key) that other organizations can use to verify the Certificate Authority's signature on other certificates. Assuming that an organization trusts the Certificate Authority, this then gives them confidence in certificates that include a valid signature from the Certificate Authority. Verisign, Inc., and Thawte Consulting are two of the better known commercial Certificate Authorities. Large corporations will sometimes, for their own internal purposes, act as their own Certificate Authority.

Certificate request: A certificate request is a special form of a site's public key suitable for signing by a Certificate Authority. The signing of a certificate request generates a certificate.

Channel block: The definition of a PMDF channel appearing in the PMDF configuration file is called a channel block; see Section 2.3.2.

Channel keyword: A large number of channel keywords are available for use in PMDF channel definitions (channel blocks) to control and modify the action of the channel to which a keyword is applied; see Section 2.3.4.

Channel program: Loosely speaking, any program which enqueues or dequeues messages to or from PMDF's message queues.

Common name: In X.500 terminology, the common name or commonName or CN attribute is a multi-valued attribute that describes an entry; typically it is something like a person's name, "First Middle Last", etc. The term is also used in other contexts, such as in a certificate, and in non-X.500 directories, especially LDAP directories.

CRAM-MD5: RFC 2195, IMAP/POP AUTHorize Extension, defines the CRAM-MD5 mechanism (Challenge-Response Authentication Mechanism using the MD5 digest algorithm) for authenticating using an encoded password, rather than sending the user's password in the clear over the network.

Dequeue: The act of removing a mail message from PMDF's message queues.

Distinguished name: In X.500 terminology, the distinguished name or distinguishedName or DN attribute uniquely identifies an object in the Directory Information Tree. The term is also used in other contexts, such as in a certificate, and in non-X.500 directories, especially LDAP directories, and hence is a much used term in PMDF-DIRSYNC.

Enqueue: The act of submitting for transmission a mail message to PMDF.

Envelope: The message's transport layer To: and From: addressing information is contained in the message envelope.

GUI: A Graphics User Interface or GUI is a visually oriented interface, such as typically seen on Mac or Windows systems.

IETF: The IETF, Internet Engineering Task Force, is the Internet standards body.

Keyword: See Channel keyword.

Private key: A private key is the secret half of a public key pair.

Public key: A public key is the published half of a public key pair.

Public key encryption: So-called public key encryption refers to encryption and decryption using a pair of keys, referred to as a public key pair. One key is referred to as the public key, and is generally published (visible to the outside world); the other key is referred to as the private key and is secret and known only to the owner of the public key pair. User A can encrypt data to send to user B using user B's public key, and then only user B will be able to decrypt the data by using user B's own private key.

Public key pair: Public key encryption uses pairs of keys, one kept secret and one published (made accessible) to the outside world. What the public key encrypts, the private key decrypts, and vice-versa. The keys together are called a public key pair.

Mailbox filter: Mailbox filters are rules for individual users, for PMDF channels, or for the PMDF system specifying screening of incoming messages; see Section 16.2.

Mapping table: Many components of PMDF make use of one or another mapping table: a table mapping input strings to output strings. All PMDF mapping tables are stored in the PMDF mapping file; see Chapter 5.

Master channel program: Any program which enqueues messages to PMDF's message queues.

MIME: See RFCs 2045--2049.

MTA: Message transfer agent; e.g., PMDF.

MUA: Mail user agent; see UA.

NOTARY: See RFCs 1891--1894.

RFC: Request For Comments; the Internet's method of publishing documents.

RFC 821: RFC 821, written by Jonathan Postel, defines SMTP, the Simple Mail Transfer Protocol, used to transfer messages over the Internet.

RFC 822: RFC 822, written by David Crocker, is the Internet standards document entitled Standard for the Format of ARPA Internet Text Messages. Messages in PMDF's message queues conform to this standard; i.e., RFC 822 is the format which PMDF uses internally.

RFC 1123: RFC 1123, edited by Robert Braden, is the Internet standards document entitled Internet Host Requirements --- Application and Support. PMDF adheres to the requirements put forth by this document.

RFC 1566: RFC 1566, sometimes referred to as MADMAN, written by Steve Kille and Ned Freed, is the Internet standards track protocol entitled Mail Monitoring MIB. PMDF accumulates the necessary message traffic statistics needed for this MIB. The concept of "group" used in the MIB is identified with a PMDF channel. The PMDF_get_channel_stats routine can be used to access the messages traffic statistics, referred to as channel statistics.

RFCs 1891--1894: RFCs 1891--1894, sometimes referred to as NOTARY, written by Keith Moore and Greg Vaudreuil, are the Internet standards track documents for the format and handling of notification messages.

RFCs 2045--2049: RFCs 2045--2049, commonly referred to as MIME, written by Nathaniel Borenstein and Ned Freed, are the Internet standards track documents describing the format of Internet message bodies. PMDF uses the specifications laid out in this document when forming multipart messages, encoded messages, etc. Note that RFCs 2045--2049 replaced RFCs 1521--1522 and 1431, previous drafts of MIME.

RFC 2222: RFC 2222, SASL (Simple Authentication and Security Layer), describes methods for adding authentication mechanisms, encryption, and data integrity checking to protocols such as POP, IMAP, and SMTP.

RFC 2246: RFC 2246 defined TLS (Transport Layer Security), a protocol for providing data integrity and encryption for reliable data connections (such as TCP).

SASL: See RFC 2222.

Security rule set: In the PMDF security configuration file context, a security rule set is a set of rules determining which authentication mechanisms and sources are permitted or used by the server. In PMDF the PORT_ACCESS mapping is used to determine the security rule set to apply to an incoming connection, based on IP addresses and ports.

Sign: In the context of a TLS certificate, to say that a certificate is signed means that a Certificate Authority has generated a hash of the contents of the certificate and used their own private key to encrypt that hash and then appended that encrypted hash to the original certificate. Then other sites that want to check on the validity of your certificate can use the Certificate Authority's well-published certificate (containing the Certificate Authority's public key) to verify the hash and thus verify that the contents of your supposed certificate match the contents that were seen and signed off on by the Certificate Authority. Assuming that the other site trusts the Certificate Authority, this then gives them confidence in your certificate.

Slave channel program: Any program which dequeues messages from PMDF's message queues.

SMTP (Simple Mail Transfer Protocol): See RFC 821.

SSL (Secure Sockets Layer): This protocol was developed by Netscape and has been superseded by TLS which is backward compatible with SSL.

Symmetric encryption: When encryption is done such that the same key encrypts and decrypts the data, it is said that the encryption is symmetric. This does require that the key that is used to encrypt the data must be given to the decryption side in a secure fashion.

TLS (Transport Layer Security): See RFC 2246.

UA: User agent; e.g., the VMS MAIL utility or the Pine utility.

User domain: A user domain is an independent set of users known to the server. This is useful, for example, if a server wants to support multiple sets of users possibly with overlapping user names. In PMDF the PORT_ACCESS mapping is used to determine the user domain for each incoming connection, based on IP addresses and ports. Currently only the PMDF popstore authentication source supports multiple user domains; for all other sources, or if no user domain is explicitly specified in the PORT_ACCESS mapping, the default user domain is assumed. Currently only the PMDF POP server supports authentication using a user domain.

Virtual domain: When a system hosts multiple domain names, it is considered to be supporting virtual domains---pseudodomain names that do not correspond to a system dedicated to only that domain name. PMDF's directory channel, etc., and user domain support for PMDF popstore users, are examples of PMDF features helpful in supporting virtual domains.