The popstore and MessageStore share a common inbound delivery channel. The popstore also has a message bouncer process which returns or removes old, undeleted e-mail from the popstore. The function of these two agents are described in this chapter. See the PMDF Installation Guide & Release Notes for directions on configuring these agents.
10.1 The inbound delivery channel
The inbound delivery channel runs as a normal PMDF delivery channel.
Messages are queued to it by PMDF for delivery to the popstore or
MessageStore. The delivery channel then processes each inbound message,
either delivering it to the popstore or MessageStore, forwarding it
elsewhere, or returning it to its originator as undeliverable.
In the popstore, the messages are stored in a ready-to-download format so that the POP3 server can simply map them into memory and send the bytes down to the client without the need for any further processing. Envelope information is also stored in the message file.
On UNIX systems, the message files are kept in the directory tree
specified by the PMDF_POPSTORE_MESSAGES option in the PMDF tailor file;
On NT systems, the message files are kept in the directory tree
specified by the PMDF_POPSTORE_MESSAGES registry entry; amd, on OpenVMS
systems, they are stored in the PMDF_POPSTORE_MESSAGES:
directory tree. Read and write access to these files is controlled
using private locks.
In the MessageStore, the messages are stored in a ready-to download format for IMAP, and the index and cache files in the appropriate folder are updated to include pre-calculated responses to common IMAP queries. This makes the MessageStore delivery process a bit slower in exchange for making all IMAP queries much faster.
The MessageStore message files are kept in a directory subtree with the
user profiles. On UNIX systems, user profiles are located in the
directory tree specified by the PMDF_POPSTORE_PROFILES option in the
PMDF tailor file (usually /pmdf/user); on Windows NT
systems, the directory tree is specified by the PMDF_POPSTORE_PROFILES
registry entry; on OpenVMS systems, they are stored in the
PMDF_POPSTORE_PROFILES: directory tree. Read and write access to these
files is controlled using private locks.
10.1.1 Rewrite rule
The popstore and MessageStore use a special rewrite rule in the PMDF
configuration file. This rewrite rule checks each envelope To: address
destined for the popstore and MessageStore. The checks consist of the
following three steps:
10.1.2 Storage quotas
At time of delivery, the delivery channel checks the message size
against the user's current disk usage and allowed quota. If storage of
the message would exceed the sum of the user's primary and overdraft
quotas, then one of the following three actions is taken:
exquota
channel keyword, then the message is delivered to the user.
holdexquota
channel keyword, then delivery of the message is deferred until either
the user has space for the message, or the message "times
out" and is returned by the PMDF message bouncer.
noexquota
channel keyword, then the message is returned as undeliverable to its
sender.
Case 2 above is the default case. Note that users with a primary quota
value of zero have unlimited storage quota.
10.1.3 Delivery notifications
The delivery channel supports the generation of delivery notifications
as described in the NOTARY specifications, RFCs 1891 and 1894. Note
that the delivery channel itself handles the success and failure
notifications while the PMDF message bouncer process generates delay
notifications.
10.2 The message bouncer
The popstore has its own message bouncer job which runs once a day
around midnight and deletes old, stored messages whose age exceeds the
maximum allowed storage age. That age is controlled with the
RETURN_AFTER popstore option as described in Chapter 3 . By
default, messages older than 14 days are deleted. If one or more of the
message's recipients have not read the message, a non-delivery
notification is sent to the message's originator. Through the
RETURN_AFTER option, the maximum allowed age may be changed. When the
maximum age is set to zero, messages are retained until explicitly
deleted by their respective recipients or manually deleted by a
popstore manager.
In addition, the message bouncer performs sanity checks on the popstore. For instance, if the system crashes during a message delete operation, it's possible that the message file may be left behind with no pointers to it. Such orphans are detected by the message bouncer.¹
Note that the message bouncer is not used by the MessageStore.