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.

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:

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:

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:

• How do I minimize filtering mail that is not Spam (false positives)?

  It is advisable to review the filtering mechanisms to make sure that you only trap mail that is considered Spam. One way to avoid discarding legitimate mail accidentally is to specify that mail always be delivered from certain domains or e-mail addresses, such as, bigboss@homeoffice.com.

  What are my PMDF filtering options?

  PMDF filtering can occur on three levels.

  1. System Level Filters System level filters are exactly as the name implies. All mail that comes into the system is run through this filter. The system level filter is applied whenever a message gets enqueued to a channel. If a message is enqueued a number of times (once, say, on tcp_local and once on conversion and then the l or msgstore channel), then the filter is processed each time. This does not cause a problem since messages can be enqueued to different channels and the amount of overhead to do this operation is minimal. Some channels, such as the conversion channel, may change the content of a message, so it can be advantageous to run through the system filter another time.

  To activate the system level filters, simply create a file called PMDF_TABLE:PMDF.FILTER or /pmdf/table/pmdf.filter (UNIX)or C:\ pmdf\ table\ pmdf.filter (Windows NT). This can be done via the PMDF Web-based interface or by using a text editor. The system level filters are part of the configuration file. When this file is changed, PMDF SMTP will have to be restarted (pmdf restart smtp). If the configuration is installed, it will need to be recompiled (cnbuild). On OpenVMS only, the configuration will need to be installed (install replace pmdf_config_data), and then restart SMTP.

  2. Channel Level Filters These filters are invoked when a message is dequeued (sourcefilter) or enqueued (destinationfilter) on a particular channel. The file names of these filters are specified by the value of the keyword. Channel filters are not part of the configuration so no restart is necessary. The channel level filters will override the system level filters. If a message is evaluated and recommended to be discarded using the system filter, and that same message is also evaluated and recommended to be kept using the channel filter, then the message will be kept.

  3. Mailbox Filters The e-mail administrator maintains the system and channel level filter files. End users maintain their own mailbox filters if the e-mail administrator enables this feature. All the mail that is destined for a particular user will run through a mailbox filter. Use of the filter keyword on the l channel, popstore or msgstore channel (what ever is appropriate for your system) activates this feature. Mailbox filters override both channel level and system level filters.

  Sometimes my email will back up with several hundred jobs that need to be processed, but my system resources are free. What can I do to prevent this?

  One of the ways of improving throughput is by adding additional queues. By default, all mail gets queued to one queue and is processed from there. On VMS, the queue is MAIL$BATCH, which is a generic queue that points to PMDF_1, PMDF_2, PMDF_3 and PMDF_4.

  UNIX and NT are slightly different. These OS's do not have a concept of "queue" or "batch jobs" or "job controller" that VMS does. To make the code and configuration consistent among multiple operating system, a job controller of for PMDF's exclusive use is included with PMDF. This information is in a file in /pmdf/table/job_controller.cnf. The default configuration shows:

  [QUEUE=DEFAULT]
  job_limit=4
  capacity=200

  DEFAULT is the queue name, job_limit is the number of processes that can run simultaneously and capacity is the limit that can be "holding in the queue" waiting to be processed. You can increase these numbers. Once changed, you will need to do a "pmdf restart" for the change to take effect.

  In both cases (VMS and UNIX/NT) only 4 jobs that process the mail can be running simultaneously. Should you be using a conversion channel that does virus checking, these queues can have conversion jobs in them for some time, preventing other jobs from running.

  To increase delivery performance, you can setup queues specific for any or all of the channels. For instance, you can setup a queue specifically for the conversion channel to run in so that it will not take up slots for, say, the top_local or the msgstore channels. This will enable other mail to be delivered in a timely fashion. Although this is a simple example for the conversion channel, you can be very creative in queue management depending on your particular situation, including configuring multiple channels to run in a single queue or enabling each channel to process in it's own queue.

  Let's assume you want to set up queues specifically for the conversion channel.

  On VMS, you would edit the SYS$STARTUP:PMDF_INIT_ QUEUES.COM; and add lines like:

  $initialize/queue/device=server/noenable_
  generic-
  /processor=pmdf_process_smb/on=NODEA::-
  /protection=(s:rwe,o:rwd, g:r, w:r)PMDF-CONV_1
  $initialize/queue/device=server/noenable_generic-
  /processor=pmdf_process_smb/on=NODEA::-
  /protection=(s:rwe,o:rwd, g:r,w:r) PMDF-CONV_2

  and so on.... then

  $initialize/queue/device=server/generic=(PMDF-CONV_1,PMDF-CONV_2) -
  CONV-MAIL$BATCH

  in SYS$STARTUP:PMDF_START_QUEUES.COM
  $ start/queue PMDF-CONV_1
  $ start/queue PMDF-CONV_2
  $ start/queue CONV-MAIL$BATCH

  (you may wish to make similar updates to PMDF_DELETE_QUEUES.COM and PMDF_STOP_QUEUES.COM

  In UNIX/NT, add the lines in job_controller.cnf

  [QUEUE=CONV-MAIL$BATCH]
  job_limit=4
  capacity=200

  Once the queues are added in VMS, make sure you run both these files before making the appropriate changes to your PMDF.CNF channel block definitions. For our conversion channel,

  conversion queue conv-mail$batch
  CONVERSION-DAEMON

  When you are done, make sure you do a

  $ pmdf cnbuild (if you run an installed configuration)
  $ install replace pmdf_config_data ( if you run an installed configuration)
  $ pmdf restart dispatcher (installed or non-installed configuration)

  in UNIX or NT
  # pmdf cnbuild
  # pmdf restart

  What is the format of a Sieve filter?

  Sieve filtering is a series of tests. These tests are structured as "if" statements. For example:

  if header :contains
    ["return-path","from","sender","
  resent-from","resent-sender"]
    ["unwanted.com","spamsite.com"]
    { discard;}
  elsif header :matches
    ["return-path","from","sender","
  resent-from","resent-sender"]
    ["trash.com"]
    { discard;}
  else { keep;}
   

  "elsif" and "else" are optional, but, if used, must follow an "if". There are a number actions that one and take on a message. Some actions require the "require" statement.

  Can you provide an example of a Sieve Filter for dealing with Spam?

  Spam is not only determined by the content of a message, but also by the "Content" header field. For example, normally messages with Content-Type of text/html are sent as text. To get around anti-spam filters, some spammers send this same message as Content-transfer-encoding at base64. This encodes the message by hiding the text from the anti-spam filters. It has been my experience that ONLY spammers do this.

  The allof test uses the "logical and" during its tests.

  if allof (header :contains "Content-type" ["text/html"],
  header :contains "Content-transfer-encoding" ["base64"])
  { discard;}
  
          

  Below is another example of a simple Sieve test:

  if body :contains
      ["You've got to see this page! It's really cool ;O)",
      "we don't want to waste your time",
      "I'll make you a promise. READ THIS E-MAIL TO THE END!",
      "CFGWIZ32.EXE",
      "Klez.E is the most common world-wide",
      "README.EXE",
      "Section 301",
  "Worlds First Absolutely FreeAdultSupersite",
      "src=3Dcid",
      "src=cid",
           "this is not virus mail"]
        { discard;}
    

  There are three different types of arguments: ":contains", ":matches", and ":is"

  This short script looks for certain phrases within the body of the message. The argument ":contains" will flag a line where the phrase is a subset of the whole line. All characters are taken as literal, including wildcards (*). So if you were to look for the phrase "this is not virus mail", you would not be able to use "this is * mail", since the test phrase does not have an asterisk in it. To use wildcards, use the argument ":matches". However, use this rule with caution. Not only would the test phrase catch the offending mail, but also legitimate mail with the following sentence:

  "Hi Bill, this is the very important client mail message you asked me about."

  The argument ":is" will flag only a line with an exact match.

  Can I perform a case-sensitive test with Sieve filters?

  By default, the tests are case-insensitive. With the :comparator argument, case sensitivity can be controlled. For example, the first line of a test would be:

  if body :contains :comparator "i;ascii-casemap" 
   
  to keep the default (case-insensitive) or use:
   
  if body :contains :comparator "i;octet"
  
  to force case-sensitive tests.
            

  For information on how to log e-mail to match the rules that cause specific messages to be filtered, go to www.process.com/techsupport/tips.html

  Is PMDF's sendmail affected by the recent CERT Advisory (CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail)?

  PMDF is not vulnerable. It doesn't use a single line of code from the actual sendmail program.

  The PMDF sendmail replacement is just that - a command-line replacement for the sendmail program. It's provided with PMDF because quite a few UNIX utilities depend on being able to call a program named "sendmail" with sendmail-style options.

  The PMDF sendmail replacement is not accessible remotely, and just places any message handed to it by a local program into the PMDF queues.

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:

1. 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:

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