Frequently Asked Questions

Installation/Upgrade

Troubleshooting

Filtering Mail

Security

Usage

Why will PMDF not start after upgrading or installing a patch because of an expired license?

The PMDF license is issued with a "Product Release Date:"

This product release date must either be in the future or at least after the date of the patch or the PMDF version you are installing for that patch or version to run.

PMDF will continue to run after the date specified by the "Product Release Date" in your license has passed if you do not try to upgrade or install any patches.

Typically the "Product Release Date" of your license will coincide with the expiration of your Support Maintenance Contract. You will need to contact Process Software to obtain a new license if you want to install a version release or patch dated after you "Product Release Date" has passed.

Is there a way to list the individuals who have passwords entered in the PMDF password database (not the passwords themselves) so that system administrators can notify these users of planned changes?

You can list these individual users by issuing the following command:

# pmdf password -show -user='*'

Note that the command works on UNIX either with or without the quotation marks.

I want to implement a firewall at my site. Can PMDF work in this environment?

A firewall system generally controls what TCP/IP communications are allowed between internal networks and the external world. Firewalls prevent packets considered to be unsafe from passing through. Most firewalls have a messaging component but few implement many of the messaging components of PMDF. Most utilize only a few features, thereby inhibiting the ability to take advantage of PMDF's full functionality.

Additionally, firewall products generally implement a small subset of the SMTP commands available and do not support ESMTP (Enhanced SMTP) features. Generally, the firewall vendor provides a version of sendmail for the SMTP server. Historically sendmail has had many security problems and as such modifications have substantially reduced the functionality in an attempt to make sendmail more secure.

PMDF, a full function SMTP server that implements ESMTP, can be used either in conjunction with a firewall or on the firewall itself to dramatically improve the functionality and performance of a messaging firewall. PMDF provides configuration tools to assist with either operating with a firewall or acting as a messaging firewall itself.

PMDF on a firewall
PMDF can replace the modified version of sendmail providing a secure messaging server and a great deal more features. PMDF has no relationship, history or code base with sendmail. PMDF has been engineered with security in mind, and our customers have a great deal of confidence in PMDF's ability to operate on a firewall.

PMDF in conjunction with a firewall
There are several ways to setup the operation of PMDF in conjunction with a firewall. Some of these recommendations may require features more common to a router using packet filtering techniques.

Should I use MAPS RBL or other blacklists?

RBL (Real Time Blackhole List) is part of the Mail Abuse Prevention System (MAPS) organization, and can be found at http://mail-abuse.org/rbl/. A subscription to RBL can reduce Spam because it verifies the DNS address of a sender. If the DNS address cannot be verified, the e-mail will not be delivered. Often Spammers use forged e-mail addresses from non-existent domains.

Warning: Performing DNS checks may result in the rejection of some valid messages. For instance, this could include mail from legitimate sites that simply have not yet registered their domain name, or during periods of bad information in DNS.

Also, if DNS or connections to the sites being used for DNS verification become unavailable then mail delivery will be impacted. Use of these Spam blocking techniques can impact performance as well as result in unreliable mail reception due to the dependency on multiple DNS lookups for every incoming SMTP connection.

PMDF supports RBL and other blackhole lists via the dispatcher options DNS_VERIFY_DOMAIN or ENABLE_RBL. Note that ENABLE_RBL=1 is the same as DNS_VERIFY_DOMAIN=blackholes.mail-abuse.org (the MAPS RBL list). Therefore, ENABLE_RBL has effectively been obsoleted by DNS_VERIFY_DOMAIN.

The DNS_VERIFY shareable image can also be used to validate domain names or IP addresses via DNS. For example, it can be used to verify that an entry in DNS exists for the domain used in the SMTP MAIL FROM: command, or to look up an IP address in the MAPS RBL list and other blackhole lists. The message can be rejected or accepted based on the presence or absence of a corresponding DNS record, or a new header can be added to the message to indicate the problem.

DNS_VERIFY is supplied as a sharable image on VMS, as a sharable object library on UNIX, and as a DLL on NT.

DNS_VERIFY has 4 routines that can be called:

Please see Chapter 16 in the PMDF System Managers Guide for more information about how to use each of these routines.

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:

  1. 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).
  2. 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.

Why do I see "Recorded error -- Zero length SMTP status line" error?

PMDF is expecting the remote system to contain valid SMTP status code when it does not have it.

This error can be found in your mail.log_current file as well as in debug files and TCPdump files.

All SMTP status lines are required to begin with three digits, followed by a space or dash, then an optional status message. Having an SMTP status line containing no characters is a protocol violation. The usual suspect is an extra
CR or LF just before a status. PMDF treats this as a temporary error and attempts to send the mail again.

This is a problem on the server end (usually from firewall software, or some Exchange servers); however, PMDF can handle this broken behavior. All you need to do is specify the smtp_crlf or smtp_lf channel keyword rather than the default keyword smtp_crorlf (smtp is synonymous for the smtp_crorlf keyword), and PMDF no longer treats bare CRs as a terminator. A single CR or a single LF is treated as a "normal" character. Process Software recommends using the keyword smtp_crlf since RFC 821 (section 4.1.1) says that lines should be terminated by a single CRLF sequence.

There are some SMTP servers that use LF-only terminators. However, bare CR terminators are quite rare. You need
to choose between supporting the agents that use bare CRs and LFs as line terminators or supporting the ones that use them as regular characters. In general, you can not support both.

Unfortunately, this is not addressed in current RFCs. RFC821 says that lines should be terminated by a single CRLF sequence, but does not say anything about the interpretation of bare CRs and LFs. Some clients break the rules and use either LF or CR alone instead of CRLF together. So PMDF tries to deal with this by treating these as line terminators (as noted above, this treatment is configurable). The problem is that other agents expect bare CR or LF NOT to be interpreted as a terminator.

PMDF v6.0 has code that ignores such things in status responses, so one way to avoid the problem is to upgrade.

How do I calculate a byte limit?

What are some examples of Spam that PMDF can eliminate?

There are many ways PMDF can be used to eliminate Spam. Here are just a few examples:

Why do we get the errors: response to dot-stuffed message expected?

Background: SMTP [RFC 821] specifies that when transferring the body of an SMTP message, any line that begins with a “.” (dot) be prefixed, before being sent, with another dot. This is commonly referred to as “dot-stuffing”. It is necessary because the end of the body is signaled by a single dot on a line. So in the message

> Error reading SMTP packet; response to dot-stuffed message expected

The “dot-stuffed message” portion may be understood more simply as “message body”. This means that the remote side failed to respond in ten minutes after PMDF sent the last of the message.

The error text indicates that PMDF successfully connected, addresses were accepted, and the entire message body was sent. The problem is that the remote side SMTP server is either aborting or being very slow to respond or the actual network con- nection was dropped. In any case, PMDF never received a response back within the default timeout period.

As is typical with TCP channel/SMTP protocol problems, enabling debugging for the channel and generating a debug log reflecting the error often greatly clarifies what is happening. Most TCP channel or SMTP protocol error messages become clearer when seen in the context of exactly _when_ during the SMTP dialogue they occurred.

Recommendations: If you are having a consistent problem sending to a particular system, first determine it is not a network problem. If the remote end insists there is nothing wrong with their SMTP server, but is overloaded and hence very slow at accepting E-mail, you could try setting up a separate channel for sending to this system. You should also provide a more generous timeout value for that channel. This would not be advisable for the general TCP/IP channel since often waiting longer is futile and means wasting additional time before moving on to another message.

If you desire to enable debugging for the outbound tcp_ channel, put master_debug on the channel and look for the resulting the tcp_*_master.log.

See Section 23.1.2 of the V6.2 PMDF System Manager’s Guide, especially the STATUS_DATA_RECEIVE_TIME option, for more information.

Also, note that the STATUS_DATA_RECV_PER_ADDR_TIME, STATUS_DATA_RECV_PER_BLOCK_TIME,and STATUS_DATA_RECV_PER_ADDR_PER_BLOCK_TIME options may be adjusted to allow for greater timeout adjustment factors depending on the number of addresses in and size of the message, if they were factors.

How do I block emails with file attachments?

To set up your conversion channel to remove unwanted file types that come through as attachments, you want to first create a CONVERSION table in your PMDF_ TABLE:MAPPINGS. file:

CONVERSIONS
IN-CHAN=TCP_*;OUT-CHAN=*;CONVERT Yes
IN-CHAN=*;OUT-CHAN=*;CONVERT No

The actual conversions performed by the conversion channel are controlled by rules specified in the PMDF conversions file. The conversions file is located via the PMDF_CONVERSION_FILE logical name (OpenVMS), or PMDF tailor file option
(UNIX), or Registry entry (NT), and is usually the file PMDF_TABLE:CONVERSIONS. On OpenVMS, or /pmdf/table/con- versions on UNIX, or C:\pmdf\table\conversions on NT.

You have to be very precise about the format of this file. The first line begins flush left in column 1, while the second and subsequent lines are indented at least 1 space. Each entry block is separated by a blank line. The correct form of the conver- sions would then be:

! CONVERSIONS - Table of conversions for the CONVERSION channel to perform
!
! For getting rid of the .exe attachments
out-channel=*; in-type=application; in-subtype=*;
in-parameter-name-0=name; in-parameter-value-0=*.exe;
delete=1
out-channel=*; in-type=application;in-subtype=*;
in-dparameter-name-0=name;in-dparameter-value-0=*.exe;
delete=1

How to detemine which section of your Sieve file caught your spam. Also, this tech tip covers how to bypass filters.

To log your tests to determine what types of words or phrases cause messages to be filtered, use one or all of the following actions: "debug", "discard", and/or "reject".

{debug "Sieve: message contains in BODY-3 - discard"; discard;}

This will place the text of the debug action into the slave or master log file (e.g. tcp_local_slave.log) for those messages that matched a value in that particular test. If you keep these files for one day, you can write a script that writes these messages out to a log file. Please note that the "debug" action is a PMDF extension, and not part of the RFC. You will also need to have the slave_debug key word on the tcp_local channel and MM_DEBUG=2 in the option.dat file

By default, should a message get trapped, it will be discarded (if that is the action) immediately. Since no system is perfect, you will get some "false positives" or, mail that was discarded that should not have been. Process Software recommends that you quarantine e-mail on your system for a period of time so that it can be reviewed. To accomplish this, follow the steps below:

  1. Add more entry in to your Sieve file. It is best if you place this near the top:

    if exists "X-Filter-File" { keep; stop;}

  2. Discarded mail should be filed into the "filter_discard" channel. You may have to defined this channel in your pmdf.cnf file. I should be defined as:

    ! Filter channel
    filter_discard notices 7
    FILTER-DISCARD

    The "notices 7" says that the message will be kept in the filter discard channel for 7 days until it is deleted.

  3. So that PMDF is aware of the filter discard channel, add or change

    filter_discard=2

    In your option.dat file.

    Since these two files are in you configuration file, you will have to recompile your configuration.

  4. To review what is in the filter discard channel got into pmdf qm maint:

    qm.maint> dir/env filter_discard

    This will show you what messages, including the envelope from and to addresses for easy identification.

If you find a message that you suspect should not have been flagged (e.g. message number 34), then the following is recommended:
  1. determine what the message filename is for that message:

    qm.maint> read 34
    or
    qm.maint> read/content 34
    to read the content of the message

    The file name will be a ZZnnnn.00 name

  2. edit the file and somewhere in the headers add the line:

    X-Filter-File: x

    the value after the ":" is immaterial, but 'header: value' is the required syntax. Put this header tag just before the "MIME-Version: 1.0" header line. Make sure not to leave any blank lines.

  3. save this edited file to the pmdf_queue:[process] (/pmdf/queue/process/) directory but change the extension to something other than 00, say 05. You can also use the reprocess channel.
  4. perform a pmdf cache /sync (pmdf cache -sync)
  5. then run or submit the pmdf process channel:
    pmdf submit process or pmdf run process

    The mail will bypass all the filters (since the X-Filter-File header is found) and be delivered.

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, such as Netscape 7.1, 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.1 (Message store V6.1)

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 if you are running PMDF on OpenVMS, Solaris, or Tru64 UNIX. 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).

Home > Support > PMDF > FAQs

Search: