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
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 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
Channel block: The definition of a PMDF channel
appearing in the PMDF configuration file is called a channel block; see
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
RFC 821: RFC 821, written by Jonathan Postel, defines
SMTP, the Simple Mail Transfer Protocol, used to transfer messages over
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
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
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
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
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.