| Previous | 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 |