Process Software: PMDF FAQ: Installation/Upgrade

Why should I not use the Leave Mail on the server option in a POP3 client?

There are two main reasons why you should not:

You may see the same messages over and over again. If the users are pure POP3 users, they will have no way of telling the server to either refill mail into a read mail folder, when they choose to leave mail on the server. Moreover, the POP3 client does not delete the mail after retrieving it, so they may see the messages over and over again until leave mail on the server is turned off. The only use for this is as a temporary setting when someone has to use another PC on the road. (Note that POP3 ties you up with a particular PC).
Server performance will degrade. The UIDL command allows the clients to keep track of which messages have or have not been read while not deleting them from the server. But, be warned that the mail will be left in the newmail area on the server forever and performance will suffer badly because the POP3 server has to read them every time! Thus, as more and more messages build up in the new mail area, performance will degrade.

Creating Shared Folders via MessageStore

In order to successfully create shared top-level folders using these instructions, you must first meet the following requirements:

Shared folder must already exist (this tech tip is for creating additional shared folders)
An IMAP client is needed to create share folders.
Only top-level folders can be created

There are two required options within the PMDF_TABLE:MSGSTORE_OPTION. file.

DEFAULT_ACL=anyone lrsp
POST_USER=post

Specify the folder name as a subaddress when sending mail or in an alias.
For example, send to >myacct+Test@mysys.process.com> where myacct is my msgstore account name.
If you are using an alias in the aliases file to direct your username over to the msgstore channel, you must have an entry that preserves the subaddress.
```
myacct+*: myacct+*@msgstore.mysys.process.com
```
There must be a POST ACL on the folder for the username anonymous or anyone. This must be set via the IMAP protocol.
The username, password, and folder are all case sensitive.

 
$ telnet localhost 143
* OK system PMDF IMAP4rev1 V6.7 (Message store V6.7)
111 login username password
111 OK User logged in
222 setacl folder anyone +lrsp
222 OK Completed
333 logout
* BYE LOGOUT received
333 OK Completed

Msgstore mailbox access rights are defined as follows:

l (lookup) - The user may see that the mailbox exists.
r (read) - The user may read the mailbox. The user may select the mailbox, fetch data, perform searches, and copy messages from the mailbox.
s (seen) - Keep per-user seen state. The "Seen" and "Recent" flags are preserved for the user.
w (write) - The user may modify flags and keywords other than "Seen" and "Deleted" (which are controlled by other sets of rights).
i (insert) - The user may insert new messages into the mailbox.
p (post) - The user may send mail to the submission address for the mailbox. This right differs from the i right in that the delivery system inserts trace information into submitted messages.
c (create) - The user may create new sub-mailboxes of the mailbox, or delete or rename the current mailbox.
d (delete) - The user may store the "Deleted" flag, and perform expunges.
a (administer) - The user may change the ACL on the mailbox.

The access rights may be combined in different ways.

lrs - The user can read the mailbox.
lrsp - The user can read the mailbox and can post to it through the delivery system. Most delivery systems do not provide authentication, so the p right usually has meaning only for the anonymous user.
lr - The user can see the mailbox and can read it, but the server does not preserve the "Seen" and "Recent" flags. This set of rights is primarily useful for anonymous IMAP.
rs - The user can read the mailbox and the server preserves the "Seen" and "Recent" flags, but the mailbox is not visible to the user through the various mailbox listing commands. The user must know the name of the mailbox to be able to access it.
lrsip - The user can read and append to the mailbox, either through IMAP or through the delivery system.

For public folders, something like lrsp should be used for anyone to allow people to read the messages in the mailbox, but not allow them to copy messages into it using their IMAP client and also not allow them to delete messages from it. Messages can then only get into the folder by sending mail to it.

What is the simplest way to restrict access to a distribution list?

The quickest and more efficient way would be to use AUTH_LIST where the users in the list are the only ones having access to the distribution list.

Example:

1. Add an entry to the ALIASES. file for the list name:

$ TYPE ALIASES.
list_name: <pmdf_table:distro_name.lis,[auth_list] pmdf_table:auth_name.lis

2. Create AUTH_NAME.LIS where you specify the list of addresses to be allowed to use the list:

$ TYPE PMDF_TABLE:auth_name.lis
address-1
address-2
...
$

To test this you would need to also specify /from=user that is allowed to send to the list:

$ pmdf test/rewrite/from=address-1 list_name@domain

All of PMDF received mail needs to be archived for future retrieval in case of litigation? Is there any way to do that?

The MESSAGE-SAVE-COPY mapping table can be used to make copies of mail as it is removed from channels. Customers can then run batch jobs nightly to ZIP and move it all off the system.

Can I prevent the PMDF mail gateway from delivering mail to our Exchange server while PMDF still receives incoming mail by stopping the dedicated channel or by some other means?

On VMS, you can do that by defining the logical PMDF_HOLD to specify the channel(s) you want to hold/stop:

$ define/system/exec pmdf_hold channelname

On all platforms you can add the slave keyword to the channel that is delivering mail to Exchange.

Is there a tool to trace a particular message in the PMDF mail log?

Use the LOG_CONDENSE utility. It scans the MAIL.LOG file, combining the two or more lines, which describe a single message into a single one-line summary.

You can find the LOG_CONDENSE utility in the PMDF System Manager's Guide, Chapter 32 (Monitoring).

When PMDF reaches its daily license limit (e.g. 5000 msgs/day) it continues to process messages, but displays a warning. Where are the messages logged on Linux/UNIX?

On Linux and UNIX, the messages are written to syslog.

The exact location of where these messages go is determined by the syslog config file, usually at /etc/syslog.conf.

This may or may not be the same location on all servers, depending on how the configuration is defined. It is usually the file /var/adm/messages.

Are rejected (J) messages counted against the license limit?

The "messages processed so far today" value shown on the Monitoring Web page does not include the J messages.

A message can have both valid and invalid recipients. Valid recipients generate E records, invalid recipients generate J records. If a message has no valid recipients it isn't accepted and doesn't count as a processed message. However, if it has at least one valid recipient, it does get counted. So in some sense there can be J records associated with a message that increments the "processed message" count. But they never make the count any higher.

What does a "Y" record in the PMDF connection log signify?

Connection try failed before being established.