| Previous | Next | Contents | Index |
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 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; and, 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 Validating Accounts
There is a channel keyword validatelocalmsgstore which is
enabled by default on the inbound delivery channel. This causes PMDF to
validate each envelope To: address destined for the
popstore and MessageStore. The checks consist of the following three
steps:
REJECT_OVER_QUOTA is set to 1,
check to see if the user is over quota. If so, reject the message for
that addressee using a temporary error response (e.g., an SMTP
4yz response). This handling is suppressed for the delivery channel
itself which occasionally needs to requeue messages back to itself.
Use of this channel keyword enables PMDF to perform the above checks as a message is presented to PMDF. This allows PMDF to reject outright messages which should not be accepted and thus preventing cases where a message is received only to have to be bounced back to the sender by PMDF. Since the message is never accepted, network and CPU resources are not consumed receiving it, generating a non-delivery notification, and then sending that notification back to the originator.
Account validation may be disabled by specifying the channel keyword
validatelocalnone on the inbound delivery channel.
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.
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 can 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 is possible that the message file can be left behind with no pointers to it. Such orphans are detected by the message bouncer.1
Note that the message bouncer is not used by the MessageStore.
1 When RETURN_AFTER is set to zero, the message bouncer still performs these sanity checks. |
| Previous | Next | Contents | Index |