The PMDF popstore is a message store streamlined for use with POP3
clients. It is distinct from the Berkeley and VMS MAIL mail box message
stores traditionally used on UNIX and OpenVMS platforms. For a given
message, a single copy is stored for all recipients. Moreover, the
message is stored in a ready-to-download format; i.e., the
server can just map the file into memory and send it down the TCP
connection without the need for any pre-processing of the message data
as is the case with many stores such as Berkeley and VMS MAIL mail
The popstore is primarily designed for scalability. Central database files, a principal cause of bottlenecks in high volume settings, are avoided.1 In a similar vein, the underlying message store itself can be spread across any number of disks.
The major components of the popstore are described below.
Legacy and popstore POP3 serverA dual-store, multi-threaded POP3 server is provided on UNIX and OpenVMS platforms which supports both the PMDF popstore and the legacy UNIX Berkeley and OpenVMS MAIL mailbox formats.
MessageStore and popstore POP3 serverA new dual-store, multi-threaded POP server is provided on all platforms which supports both the popstore and MessageStore. This server includes security and performance enhancements not possible while maintaining support for legacy mailbox formats.
Poppassd serverA multi-threaded poppassd server for users of Mulberry, Eudora, and other clients which support the ad hoc
poppassdprotocol for changing passwords.
Web-based user interfaceA basic web-based user interface is provided. This interface allows users to use a web-client to change their password as well as see basic usage information about their popstore account. They can also read and delete messages stored for their account. For details, see Chapter 5.
Web-based management utilityA web-based management utility to manage the popstore. The utility presents itself as a multi-threaded CGI accessed through the PMDF HTTP server. Popstore users with management privileges can use this interface to monitor and manage the popstore. This utility is extremely reconfigurable; the entire interface can be changed around to suit a site's needs. See Chapter 4 for a description of this interface.
Command line management utilityA command line oriented management utility. Users with operating system privileges as well as popstore users who have been granted popstore management privileges can use the utility. See Chapters 6 or 7 for information about this utility.
Migration utilityA utility is provided to migrate the mail inboxes for login accounts to the popstore. The utility can create a popstore account for each migrated user, migrate their mail inbox, and then establish mail forwarding from their login account's message store to the popstore. See Chapter 8 for details about this utility.
Forwarding databaseA forwarding database which allows mail for popstore users, fictitious or otherwise, to be automatically redirected elsewhere. Consult Section 1.5 for further details.
Delivery channelA master channel to deliver inbound messages to the popstore. Inbound messages for the popstore are queued to this channel by PMDF. The channel is then run by PMDF to deliver the messages to the popstore. See Section 10.1 for details.
Message bouncerThis is a job which runs periodically and either returns or deletes old stored messages which have "expired". This channel is best likened to the PMDF RETURN job. This job is used to "time out" old messages which popstore users have not deleted. If an old message has never been read, it is returned as undelivered. If it has been read, it is deleted. Note that the popstore can be configured to never delete old messages and just keep messages around indefinitely. See Section 10.2 for further discussion.
Rewrite ruleA special rewrite rule is used by PMDF so that it can, when presented with a popstore address, immediately check to see if it is valid or not (e.g., is it a valid recipient address, is the recipient allowed to receive new messages, etc.). This allows the various incoming mail streams to reject up front invalid messages for the popstore thereby obviating cases where the message is received only to then have to be bounced. Section 10.1.1 contains additional information on this rewrite rule.
APIAn API for sites who want to generate their own management, accounting, billing, logging, etc. facilities. In addition, agents which access the popstore or manipulate user accounts can be written using the API. See Chapter 12 for further details.
1 Note that the popstore does use some databases. However, these databases are only used to expedite management operations such as listing accounts and maintaining information about management groups. They are not used for non-management operations and therefore do not impact the performance of the popstore.
Although installed as part of the base PMDF-MTA product, the PMDF
popstore is licensed separately. The popstore can, however, be used
without a license: sites without a PMDF-POPSTORE license can create up
to ten popstore user accounts plus a
default account. A
PMDF-POPSTORE license enables a site to create more than ten user
From the interactive command line management utilities, the
-count_users command (
SHOW/COUNT_USERS on OpenVMS)
can be used to display the number of currently defined accounts as well
as the limit allowed by your license. The web-based management utility
can also display this information; see the "License limits"
link in the menu at the top of the main page.
Each user of the popstore has a popstore account. Accounts have several
|Name||The username used to identify the account.|
|Password||The secret used to access the messages stored for the account. Note that passwords are case sensitive. The popstore stores the passwords in an encrypted form.|
|Group||Management group to which the account belongs. Use of management groups is optional.|
|Quota||A storage quota which limits the total amount of messages which an account can store.|
|Usage flags||Flags used to control usage of the account. For example, whether or not the account can receive new messages.|
|Accounting information||Accounting information such as time of last connect, total connect time, current storage, etc.|
Of particular importance is the account name and password. The account
name specifies the mailbox for the popstore account. That is, if the
popstore has the domain name
sample.example.com then a
popstore account with the name
jdoe would have the e-mail
+, in the local part then the plus sign and any characters to the right of it up to the at sign are ignored. For instance, the user
jdoecan want to identify mail they receive from the HBD mailing list by subscribing themselves to that list with the address
POP users access the mail stored for their account by supplying to their POP3 client their popstore account name and password. The rules for account names and passwords are given in Section 1.3.1 and Section 1.3.2.
Note that there is a special account --- the
account --- which is created at the time that the popstore is
configured. The settings for the
default account serve as
account defaults. When new accounts are created, their defaults are
copied from the
The complete list of account fields is given in Table 1-1. Their interpretation and usage are made clear throughout the remainder of this manual.
||Data structure version number indicating what revision of the popstore account data structure is used by the account.|
||Storage type: popstore or MessageStore.|
||Account usage flags.|
Length in bytes of the value stored in the
Length in bytes of the value stored in the
Length in bytes of the value stored in the
Length in bytes of the value stored in the
||The account's name. Maximum length of this field is 32 bytes.|
||The account's password. Maximum length of this field is 32 bytes. The value stored in this field is encrypted.|
||Information about the account's owner. Maximum length of this field is 40 bytes.|
||Site-defined data field. Maximum length of this field is 64 bytes. The contents of this field can be set through the API or either of the management interfaces.|
||The account's primary storage quota measured in bytes. A value of zero indicates unlimited storage quota.|
||How long to retain messages in the popstore before returning them.|
||The account's overdraft quota measured in bytes.|
||Time when billing information for the account was last generated. When the account is created, this value is set to the creation time of the account.|
||Total number of connections made to the account.|
||Time when the user last connected to the account with a POP3 client.|
||Time when the user last changed their password.|
||Time when the user last disconnected from the account with a POP3 client.|
||Total time, in seconds, spent connected to the account.|
||Storage block days for previously stored and since deleted or returned messages. Does not include storage values for messages currently being held in the store.|
Roundoff from the
||Count of messages presently stored for the account.|
||Total size in bytes of the messages presently being stored for the account.|
||Cumulative number of messages which have been stored for the account.|
||Cumulative number of message bytes which have been stored for the account.|
Length in bytes of the value stored in the
||Management group to which this account belongs. Maximum length of this field is 16 bytes.|
1.3.1 Account Naming
The popstore supports three different naming schemes: two are
case-insensitive while the third is case sensitive. Note that the
character set used for account names is controlled with the
USERNAME_CHARSET option discussed in Section 3.4. The
choice of character set is only of relevance to
2. And, for those two, is only used when
doing case-insensitive comparisons of account names (e.g., are
the account names
188.8.131.52 The Preferred Naming Scheme
The preferred naming scheme corresponds to an option setting of
USERNAME_STYLE=3 in the popstore option file. This option
is required by the PMDF MessageStore and will be included in newly
generated PMDF configurations.
With this setting,
UTF-8characters except for
/ @ % +
- _ .
If you want to have case-insensitive behavior, create all your accounts using lower-case names, and use
security.cnffile to convert login usernames to lower case.
184.108.40.206 The Default Naming Scheme
For backwards compatability, the default naming scheme corresponds to
an option setting of
USERNAME_STYLE=2 in the popstore
option file. That option file is described in Chapter 3.
In the default scheme, account names can be up to 32 characters long and can contain any of the characters from the set
0 1 2 3 4 5 6 7 8 9 . _ - a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
annespecify the same account.3 Account names should not begin with an underscore character, "_".2
220.127.116.11 Another Obsolete Naming Scheme
A third, and largely obsolete naming scheme corresponds to the option
USERNAME_STYLE=1 in the popstore option file.
That option file is described in Chapter 3.
In this naming scheme, account names can contain any printable
character in the DEC MCS or any one of the ISO Latin 1 through Latin 9
character sets (ISO 8559-1 through ISO 8859-9). That is, any character
with decimal ordinal value in the ranges 33---126 or 161---255
(0x21---0x7E or 0xA1---0xFF in hexadecimal). On UNIX and NT platforms,
the account names can be up to 32 characters long; on OpenVMS platforms
up to 19 characters. Note that the names can contain spaces and
punctuation characters. Again, the names are treated as being case
insensitive. The account names should not begin with an underscore
_, or contain plus signs,
When a name is specified, it is converted to an account name using the following five steps:
SPACEcharacters are replaced with a single SPACE character.
The choice of character set is specified with the
USERNAME_CHARSET option as described in Chapter 3.
1.3.2 Account Passwords
Passwords are used to authenticate a would-be user of the popstore.
That is, a user wanting to access the popstore must supply a valid
popstore account username as well as the password for that account. The
user-supplied password is checked against the password stored for the
account: only if they match is access permitted.
18.104.22.168 Password Location
Each popstore account requires a password. A password can either be
stored with the popstore account's profile or it can be stored
externally outside of the popstore. Regardless of where the password is
stored, it can be set and changed with the popstore management and user
interfaces as well as with the PMDF poppassd server. PMDF's
authentication API is used by the popstore both to authenticate as well
as set or change passwords. By default, this means that when a password
is authenticated, it will be checked against
PWD_ELSEWHEREusage flag is not set for that profile;
When a password is set or changed for a popstore user, it will by default be
PWD_ELSEWHEREusage flag is not set for that profile;
The above actions are the default behavior---the behavior when PMDF's
authentication facilities are using their default configuration. Those
facilities can be reconfigured to act differently and even to use other
repositories of password information (e.g., an LDAP server or
other authentication server). For more information on PMDF's
authentication facilities, see the "Connection Authentication and
Password Management" chapter of the PMDF System Manager's
Guide. When using those facilities, the popstore uses a service
POP. When a password is stored with the account's
profile, the plain text form of the password is encrypted and stored.
Such passwords are
To store a password in an external source, mark the account with the
PWD_ELSEWHERE usage flag. This tells the popstore that the
password is stored externally. See also the information on password
migration in the PMDF System Manager's Guide.
The POP3 server uses PMDF's authentication services and as such
supports plain text as well as
authentication. Moreover, the POP3 server supports SASL (RFC 2222).
POP users can change their account passwords with PMDF's poppassd server, as described in Section 11.3, or with the web-based user interfaces described in Chapter 5. The poppassd server implements an ad hoc password changing protocol employed by several popular POP3 clients such as Eudora.
22.214.171.124 Using the Operating System's Password Database
With the default configuration of PMDF's authentication services, using
the operating system's password database is quite straightforward.
Simply set the PWD_ELSEWHERE usage flag for each popstore account which
is to use the operating system password database.4 Once this
has been done, authentication will be performed against
/etc/passwdon UNIX systems and
sysuaf.daton OpenVMS systems). Note, however, that this requires that there be an entry for the user in the operating system's password database. Usually, this means that the user will also have a login account on the system.
126.96.36.199 Password Security
If a password is stored with the account's profile, the popstore
provides several security features.
VALIDATE_PASSWORDsubroutine (see Section 14.3).
As soon as password expiration is enabled, all accounts created by versions of PMDF prior to V6.2-1 are automatically pre-expired.
1.3.3 Account Quotas
Account quotas can be used to control how much message storage a given
account can have. When an account exceeds its storage quota, as
measured in bytes of disk storage, the account can not receive new mail
messages. The user must delete some of their stored messages in order
to receive new mail messages.
Each account has two storage quotas: a primary storage quota and an overdraft quota. This two-quota scheme is used for efficiency purposes. With most message transfer protocols, the size of an incoming message is not known upfront and a message has to be received in its entirety in order to determine its size. Use of an overdraft quota allows PMDF to temporarily refuse to accept incoming messages for an over quota user. How so? If a user has just one quota limit, then odds are they will never quite attain it. For instance, if they have 100 spare bytes of storage they are not over quota and so the SMTP server will accept new messages for the user. However, most received messages will be larger than 100 bytes and will thus need to be bounced. This will continue until the user receives enough small messages to exactly use up those remaining 100 bytes. Once they have exactly consumed their quota, the SMTP server can now immediately refuse further messages without the need to first receive the message and see how large it is. But this is only possible once the user has exactly consumed their quota. An alternative is to have a "fudge" factor of some form. Once the user is somehow close to their quota, the server refuses additional messages. The popstore's overdraft quota is such a fudge factor. A user's quota is really a quota range with a lower limit given by their message storage quota and the upper limit given by the sum of their message storage quota and their overdraft quota.
All that having been said, note that by default PMDF will not reject
incoming messages for an over quota user. By default, PMDF accepts the
messages and holds onto them until either the user has available quota
to receive the messages or the messages "times out" and are
returned by PMDF's message bouncer. To have PMDF reject incoming
messages for an over quota user, specify
REJECT_OVER_QUOTA=1 in the popstore option file as
described in Section 3.4. When
specified and a user is over quota, the message copy for the over quota
user will be rejected with a temporary error message.
If desired, accounts can be granted unlimited storage quota as denoted by a primary quota value of zero.
1.3.4 Management Groups
For management and accounting purposes, you can associate with each
popstore account a group name. Use of group names is optional. You can
ignore this feature for the time being and later, if a need should
arise, then begin using it.
Group names are case-insensitive and can be zero to sixteen bytes long.
Group names are shared across all user domains. When you create a new
account and do not specify a group name for the account, the account is
placed in the same group as the
default account. By
default account is not in any group --- it
has a group name of zero length. This group with a zero length name is
referred to as the
There are two primary uses for management groups:
MANAGEflag set --- can perform management functions on only those accounts within the same user domain and management group. A privileged popstore account which is in no group (and hence is in the
worldgroup) can manage all popstore accounts within the same user domain. However, a privileged popstore account which is in no group and is in the
defaultuser domain can manage all accounts within all user domains and groups.
The actual details behind defining groups and assigning group names to
accounts is documented in Chapters 4 --- 7 as
part of the discussions of the various account management commands.
Note that only two classes of users can create, delete, or modify group
definitions. These classes are (1) users with operating system
privileges, and (2) popstore users with privileged account which
themselves are in no group [and thus are in the
group]. The first class can use the interactive command line management
utilities; the second class can use either the interactive command line
or web-based management utilities.
Groups can be nested. That is, a group can contain subgroups and those
subgroups can contain further subgroups. An account is contained in the
G if either (1) the account's group name is
G, or (2) the account's group is a subgroup
(nested arbitrarily deep) of the group
world group --- the group with zero length group name ---
is a distinguished group: it implicitly contains all other groups.
You can visualize typical group hierarchies as an inverted tree. A
hypothetical example with nine groups is shown in Figure 1-1. The
root of the tree is the
world group, which contains all
other groups. The
have no subgroups. The
students group, however, has five
Group hierarchical structure need not be a tree: in the language of
graph theory, loops are allowed. For instance, a group can be a
subgroup of more than one group. Modifying the example of Figure 1-1,
it is possible for
grad to also be a subgroup of
Figure 1-1 Example management groups
The ability to nest groups is particularly useful in regards to account
management. An account with management privileges can manage any
account within the same group as the privileged account itself. Thus,
if a privileged account has a zero length group name, then that account
can manage any and all accounts. If, however, the privileged account is
in a group with a non-zero length group name, then that privileged
account can only manage accounts contained within the same group. For
instance, a privileged account in the
students group can
manage any account in that group; i.e., any account with group
privileged account in the group
class97 can only manage
other accounts in the group
class97. If you want to have
an account which can manage both
faculty but not
students, then just create a
new group named, for instance,
dean and make
faculty be subgroups of that new
group. Then, make the group name for the privileged account be
If you want to allow an account to manage all accounts yet be in a
named group such as
manager, then create a group named
manager and make the
world group be a
subgroup of the
1.3.5 User Domains
By default, all popstore accounts are considered to be part of the same
user domain called the
default domain. This is true
regardless of the e-mail address used to reach the account's mailbox.
At some sites, however, it is useful to have distinct sets of user
communities, each differentiated by a distinct Internet host name. For
instance, one community can be the
with mail addressed to
firstname.lastname@example.org while another
community can be the
sample.com community with mail
email@example.com. In the popstore,5
each community can be assigned a different Internet host name with an
associated community name called a
user domain name.
The popstore user
user in the user domain
host has the e-mail address
host.6 The delivery channel,
which can deliver mail for several different user domains, determines
which domain or domains a message should be delivered to by examining
each envelope recipient address. The non-legacy POP server determines
which user domain a client is in from either the username presented by
the client or from the
PORT_ACCESS mapping table. In
regards to the former, the client must present a username of the form
host.7 In regards to the
latter, consult the
PORT_ACCESS mapping table
documentation in the PMDF System Manager's Guide. Use of that
table allows selection of the user domain to be based upon such
information as the client's source IP address or the TCP port which the
client has been configured to use for POP service.
When managing the popstore via the Web-based management utility, the
user domain to manage is specified by including it in the URL; for
example, to manage the
example.org user domain, use the URL
When using user domains, there will be a special user domain referred
to as the
default domain. The official host name for the
delivery channel will be mapped to the
Moreover, a privileged management account in the
domain which is in no group can manage any account within the popstore
regardless of user domain. To make this a little more clear, consider
the channel definition
popstore defragment holdexquota example.com example.org
defaultuser domain; the host example.org is identified with the
example.orguser domain.8 Mail to
firstname.lastname@example.org delivered to the account
example.comuser domain. Mail to
email@example.com delivered to the separate account
jdoein the user domain
example.org. Accounts associated with the
example.comhost are managed by managing the
defaultuser domain; accounts for the sample.com host are managed via the
See Sections 6.13 and 7.13 for detailed information on creating a user domain and managing accounts within it.
1.3.6 Account Usage Flags
Through "usage flags", account access to the popstore can be
DISMAILflag is used to prevent an account from receiving new mail messages. When this flag is set for an account, new messages are rejected and returned to their sender. The account owner can, however, read any existing messages they might have unless the account is also flagged with the
DISUSERflag is used to deny access to an account. The account can, however, continue to receive new messages unless it is either over quota or also flagged with the
DISMAILflag. When the user attempts to access their account, they will be met with an "account disabled" error message.
LOCKPWDflag prevents users from changing their account's password. The password can only be changed by a user with the management privilege or operating system privileges.
MANAGEAccounts with this flag can use the web-based interface to manage the popstore. In addition, users with unprivileged login accounts to the platform running the popstore can manage the popstore using the command line interface when their popstore account has the
MANAGEflag set. This is accomplished through the command line interface's
LOGINcommand. Section 1.3.7 for further details.
MIGRATEDThis is a flag used by the PMDF's migration utilities to track whether or not migration from an external source to the popstore has been completed for a given popstore user account.
PWD_ELSEWHEREThis flag tells the popstore that the user's password information is stored externally, outside of the popstore. The popstore's authentication mechanisms use this flag when determining how to authenticate a user password. See Section 1.3.2 for further details.
With the exception of the
flags, these flags can be set or cleared with either the web-based or
command line management interfaces. As a security precaution, the
NOMANAGE flags can only be
manipulated through the command-line interface.
Note that PMDF itself has a variety of other access control mechanisms
such as the
SEND_ACCESS mapping table to control access at
the envelope address level and the
tables to control access at an IP level. See the PMDF System
Manager's Guide for details on these and other access mapping
mechanisms provided by PMDF.
1.3.7 Privileged Accounts
The popstore has the concept of "privileged" popstore
accounts. These are popstore accounts which have the
MANAGE usage flag set. Only accounts with the
MANAGE flag set can use the web-based management
interface. As a security precaution, this flag can not be set or
cleared through the web-based interface. That means that the command
line interface must be used to grant an account management privileges.
That, in turn, requires a priviliged login account to the operating
system running the popstore. From that login account, one or more
popstore accounts can be granted management privileges. Those accounts
can then be used to manage the popstore either through the web
interface or, as described in Sections 6.14 and 7.14,
the command line utility.
Privileged accounts can only manage other accounts within the same
management group and user domain. If a privileged account is in the
world group (i.e., is not in any group or is in a
group which explicitly contains as a subgroup the
group), then it can manage any popstore account within the same user
domain. However, a privileged popstore account which is in the
world group and is in the
user domain can manage all accounts within all user domains
1.3.8 Bulk Loading
Accounts can be created en masse using the command line
management utility. This is done by creating a file of commands, one
command per line, and then directing the utility to process the
commands from that file. For further details, see Sections 6.7
(UNIX and NT) or 7.7 (OpenVMS).
1.3.9 Account Storage
The information associated with each user account is stored in a
"profile" file on disk. One file per user account is used. An
account's settings, usage information, and list of currently stored
messages is stored in its profile file. On UNIX systems, the location
of these files are determined via the
PMDF_POPSTORE_PROFILES option in the PMDF tailor file; on
NT systems, the
PMDF_POPSTORE_PROFILES registry entry is
used, and on OpenVMS systems, in the
PMDF_POPSTORE_PROFILES: directory tree.
Read and write access to these files is controlled using private locks. As such, they should only be accessed using the popstore API routines documented in Chapter 12.
Each profile file has a base size of 256 bytes plus 40 bytes per message stored for the user. Presently, the profile files are interchangeable amongst the different platforms on which the popstore runs. That is, for instance, it is presently possible to move the popstore from one platform to another without the need to reformat the profile files.9 See Section 8.1 for complete details on migrating the popstore to another platform.
The profile files must be stored on a disk with a reliable file system. The profile files must not be accessed via NFS: NFS, even with a lockd daemon, does not provide adequate file locking, integrity, or performance and is not supported.
2 A leading underscore character in a
recipient address is interpreted by the delivery agent as a request to
ignore any forwarding for that recipient. For instance, a message for
firstname.lastname@example.org is delivered to the popstore account
When PMDF receives a message for the popstore, the message is queued to the popstore's inbound delivery channel. That channel then processes each queued message and stores the resulting messages in the popstore's message store. A single message copy is stored for all recipients of a message. Once a message has been deleted by each recipient, it is deleted from the store itself.
Message storage quotas are set on a per-user basis via the quota and overdraft quota account settings. See Section 1.3.3 for further details.
Users access their stored mail messages via their POP3 client and the popstore's POP3 server. Ideally, users download their messages and delete them from the store itself. By default, if a message is not deleted within a fixed number of days, the message will be deleted silently. Should one or more of the recipients not have read the message, a non-delivery notification is sent to the message's originator prior to deleting it.
Popstore administrators can delete message files using either of the two management utilities. Optionally, when a message file is deleted, a non-delivery notification can be sent to the originator of the message. The non-delivery notification will state which recipients had not read the message.
The actual message files are binary files stored in a ready-to-download
format. On UNIX systems, these files are kept in the directory tree
specified by the
PMDF_POPSTORE_MESSAGES option in the PMDF
tailor file; on NT systems, the
registry entry is used; and, on OpenVMS systems, in the
PMDF_POPSTORE_MESSAGES: directory tree. Read and write
access to these files is controlled using private locks. The files
should only be accessed using the popstore API routines as documented
in Chapter 12.
The size of each message file varies depending upon the amount of envelope information and message content which must be stored. Presently, the message files are interchangeable amongst the different platforms on which the popstore runs. That is, for instance, it is presently possible to move the popstore from one platform to another without the need to reformat the message files. While Process Software hopes to maintain this level of portability in the future, it can not be possible, at which point a conversion utility will be provided.
The message files must be stored on a disk with a file system which supports byte range file locking. The message files must not be accessed via NFS: NFS, even with a lockd daemon, does not provide adequate file locking, integrity, or performance and is not supported.
1.5 Forwarding Mail
The popstore includes a forwarding database which can be used to
re-route mail for the popstore to other addresses. The addresses can be
either internal or external to the popstore. Moreover, forwardings need
not correspond to actual popstore accounts. For instance, if mail for
email@example.com is to be forwarded to a PMDF mailing list, then there
need not be a
staff account in the popstore. Note that
when a forwarding is established for a popstore account, the popstore
account itself will not receive copies of its forwarded messages.
Forwardings are recursive. That is, if a popstore address has a forwarding which in turn points to another popstore address, then that new address will also be checked for a forwarding. In addition, a forwarding can point to more than one address. That is, a forwarding can forward to multiple addresses and, moreover, some of those addresses can themselves be forwarded.
Forwardings are established, examined, and removed through either of
the management interfaces. The forwardings are stored in an ordinary
PMDF CRDB database --- the
If desired, the database can be manipulated using ordinary PMDF tools
as well as through the PMDF API.
Messages destined to the popstore can explicitly defeat any forwarding
by prefixing the address with an underscore character,
For instance, if the account "
jdoe" has mail
forwarded elsewhere, then a message sent to the address
firstname.lastname@example.org will bypass that forwarding and be
delivered to the "
jdoe" account. To explicitly
forbid such bypassing, the
DISMAIL usage flag can be set
for the account in which case mail to
will be returned as undeliverable.
Finally, note that it is the popstore delivery channel which actually
effects mail forwardings. When processing message files, it checks each
recipient to see if a forwarding exists. If it does, it then uses the
forwarding address instead. If the forwarding address points back to
the popstore, it then checks that address for a forwarding. This
process is iterated up to ten times; an address which is forwarded
internally more than ten times is deemed to be a forwarding loop and is
rejected. If the forwarding address is external to the popstore, then a
new message is enqueued with the forwarding address used as its