This manual describes the configuration for the PreciseMail Anti-Spam Gateway product.
Revision/Update Information: This is a revised manual.
Operating System and Version: OpenVMS VAX V6.1 or later
OpenVMS Alpha V6.2 or later
OpenVMS I64 V8.2 or later
PMDF Version: PMDF V6.1 or later
Software Version: PreciseMail Anti-Spam Gateway V3.0
Copyright (c) 2007 Process Software, LLC. All Rights Reserved. Unpublished --- all rights reserved under the copyright laws of the United States
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language or computer language, in any form or by any means electronic, mechanical, magnetic, optical, chemical, or otherwise without the prior written permission of:
Process Software, LLC
959 Concord Street
Framingham, MA 01701-4682 USA
Voice: +1 508 879 6994; FAX: +1 508 879 0042
info@process.com
|
Process Software, LLC ("Process") makes no representations or warranties with respect to the contents hereof and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Furthermore, Process Software reserves the right to revise this publication and to make changes from time to time in the content hereof without obligation of Process Software to notify any person of such revision or changes.
Use of PreciseMail Anti-Spam Gateway software and associated documentation is authorized only by a Software License Agreement. Such license agreements specify the number of systems on which the software is authorized for use, and, among other things, specifically prohibit use or duplication of software or documentation, in whole or in part, except as authorized by the Software License Agreement.
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or as set forth in the Commercial Computer Software --- Restricted Rights clause at FAR 52.227-19.
MultiNet is a registered trademark of Process Software, LLC.
TCPware is a trademark of Process Software, LLC.
PMDF is a trademark of Process Software, LLC.
All other trademarks are the property of their respective owners.
| Contents | Index |
This guide describes how to manage PreciseMail Anti-Spam Gateway.
This manual is intended for use by the system manager or any individual responsible for configuring and maintaining the PreciseMail Anti-Spam Gateway anti-spam product.
This guide consists of five chapters and one appendix.
| Chapter 1 | Contains an overview of how PreciseMail Anti-Spam Gateway works. |
| Chapter 2 | Describes the PreciseMail Anti-Spam Gateway configuration file. |
| Chapter 3 | Describes the PreciseMail Anti-Spam Gateway rules and writing new rules. |
| Chapter 4 | Describes the PreciseMail Anti-Spam Gateway batch jobs. |
| Chapter 5 | Describes additional programs used by the PreciseMail Anti-Spam Gateway. |
| Chapter 6 | Describes the PreciseMail Anti-Spam Gateway user interface. |
| Chapter 7 | Describes the PreciseMail Anti-Spam Gateway Data Synchronization Clusters. |
| Chapter 8 | Describes the PreciseMail Anti-Spam Gateway anti-virus scanning. |
| Chapter 9 | Describes how to debug PreciseMail Anti-Spam Gateway. |
| Appendix A | Contains a list of the files created by an installation. |
You can find additional information in the following documents:
PreciseMail Anti-Spam Gateway includes parts of or makes use of the following open source software packages:
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ http://www.pcre.org/ |
http://www.info-zip.org/license.html |
http://jquery.com/ http://jquery.com/demo/thickbox/ |
The distributions of the source and associated licenses for some of these packages is available at ftp.pmas.process.com. The license texts can also by found in the directory PMAS_ROOT:[DOC.3RDPARTY].
Notwithstanding the foregoing, PreciseMail Anti-Spam Gateway is not open source software. You must purchase a license for each copy of PreciseMail Anti-Spam Gateway that you install.
PreciseMail Anti-Spam Gateway is a high-performance anti-spam solution based on proven heuristic and artificial intelligence technologies. It eliminates spam at the Internet gateway without filtering critical legitimate email messages, producing a large potential cost savings to organizations of all sizes. PreciseMail Anti-Spam Gateway has the unique ability to allow many levels of tuning and customization to meet an individual site's email spam filtering requirements.
Every site's definition of spam is unique, so PreciseMail Anti-Spam Gateway provides the highest level of flexibility as compared to other products. Systems administrators can adjust the weight of each Process Software-supplied spam definition, as well as add new spam definitions or modify existing ones. A combination of rules can trigger a positive score, which indicates an email message is spam. For example, the total score of the phrases "low interest rates" and "click below" would indicate that a message is spam. Systems administrators can set the threshold beyond which a message is considered spam.
Process Software provides customers with regular spam definition updates that can be downloaded and installed at the customer's discretion. There is no need for a site to disclose any information about their mail system or open their firewall to install updates.
In parallel to the spam definition rules, PreciseMail Anti-Spam Gateway uses an artificially intelligent Bayesian engine to identify spam. The Bayesian engine is automatically "taught" how to separate spam messages from your site's legitimate email. By combining heuristic and artificial intelligence technologies, PreciseMail Anti-Spam Gateway is able to accurately identify spam while making it extremely difficult for spammers to circumvent the filters.
When a message is identified as spam, it is quarantined until further review by the recipient. At a set interval (usually twice daily), users are automatically notified via email with a summary of their quarantined messages. At this point, recipients can choose to release quarantined messages that they wish to receive. Email recipients can also use this automated process to set up individual allow and block lists. Since users control their own quarantined messages, there is no need for system administrators to spend time reviewing thousands of quarantined emails to identify potentially legitimate mail.
PreciseMail Anti-Spam Gateway requires minimal configuration and deployment time, making it an ideal "drop-in" solution for spam filtering. The product integrates seamlessly with PMDF, Sun Messaging Server, and Sendmail. With the addition of the Pass-Through SMTP proxy server, PreciseMail Anti-Spam Gateway can be used to protect any existing mail system.
The PreciseMail Anti-Spam Gateway product files reside in a special directory tree, normally pointed to by the logical name PMAS_ROOT:. The following directories exist in the tree and contain the described files:
On OpenVMS, a special logical name, PMAS_EXE:, is defined to point
to the appropriate executable directory (Alpha, I64, or VAX).
1.2 PMAS Configurations: PTSMTP and PMDF
PreciseMail Anti-Spam Gateway can be configured to run as a PMDF channel or as a pass-through SMTP proxy server (PTSMTP) that sits in front of whatever SMTP server you're currently running. Each solution offers advantages and disadvantages over the other.
Running PMAS as a PMDF channel lets you take full advantage of the message-handling capabilities of PMDF. You can control which messages are passed through PMAS by setting up SCRIPT or CONVERSIONS mappings entries that specify the input and output channels, or by defining PMDF aliases that route certain addresses to the PMAS channel.
The Pass-Through SMTP Server solution offers a number of advantages
over the PMDF channel configuration, including increased performance
and the ability to reject messages during the SMTP session, preventing
some messages from even entering into your mail system. Because
messages are scanned as they're being received from the SMTP client,
messages that are quarantined, discarded, or rejected are never
actually handled by PMDF, reducing the system overhead incurred when
PMDF processes messages. In addition, the always-running PTSMTP worker
processes keep the PMAS rule set in memory at all times, reducing disk
I/O over the PMDF channel version, which must read in the PMAS rules
every time a new process is created to process a message.
1.3 Starting PreciseMail Anti-Spam Gateway
The PreciseMail Anti-Spam Gateway startup procedure should be run from your system startup. The following line should be added to SYS$MANAGER:SYSTARTUP_VMS.COM:
$ @sys$startup:pmas_startup.com |
The placement of that line depends on which way you're running PMAS.
PreciseMail Anti-Spam Gateway is integrated with Process Software's PMDF product, allowing PreciseMail Anti-Spam Gateway to be easily added to existing PMDF installations. PreciseMail Anti-Spam Gateway includes a new PMDF channel called "pmas".
Messages are routed from PMDF to PreciseMail Anti-Spam Gateway by means of a CONVERSIONS or SCRIPT entry in the PMDF MAPPINGS. file in PMDF_TABLE:. (The SCRIPT entry is only available in versions of PMDF after V6.2 or in PMDF V6.2 via a downloadable ECO.) The special CHANNEL= keyword is used to specify the "pmas" channel. A typical entry will look like this:
CONVERSIONS IN-CHAN=tcp_*;OUT-CHAN=l;CONVERT CHANNEL=pmas,Yes IN-CHAN=*;OUT-CHAN=*;CONVERT No |
In this example, all messages coming in from SMTP channels ("tcp_*") and destined for local users (delivered via the "l" channel) will first be routed to the pmas channel.
If you already have a CONVERSIONS entry, you must decide if you want messages routed to the pmas channel before or after they're processed by the conversion channel. This is accomplished by specifying the proper values for IN-CHAN and OUT-CHAN. To have messages routed to the conversion channel first, then to the pmas channel, lines like the following would be used:
IN-CHAN=tcp_*;OUT-CHAN=l;CONVERT Yes IN-CHAN=conversion;OUT-CHAN=l;CONVERT CHANNEL=pmas,Yes |
or to have PreciseMail Anti-Spam Gateway run first, use lines similar to these:
IN-CHAN=tcp_*;OUT-CHAN=l;CONVERT CHANNEL=pmas,Yes IN-CHAN=pmas;OUT-CHAN=l;CONVERT Yes |
If you're using the SCRIPT channel entries, you have the option of restricting which messages are processed by PreciseMail Anti-Spam Gateway based on the message size. The MAXBLOCKS and MAXLINES keywords are used to restrict the sizes of messages that will be processed by PreciseMail Anti-Spam Gateway. Since spam messages are typically small messages, these keywords can be used to prevent needless processing of large messages that aren't likely to be spam.
SCRIPT IN-CHAN=tcp_*;OUT-CHAN=l;SCRIPT CHANNEL=pmas,maxblocks=200,maxlines=2000,yes IN-CHAN=*;OUT-CHAN=*;SCRIPT No |
To run the PMAS Pass-Through SMTP Server (PTSMTP), you must define the
appropriate PMAS configuration variables as described in Section 2.2.9, Pass-Through SMTP Server keywords.
There are three additional steps in configuring PMAS PTSMTP.
1.5.1 MX records
If you choose to run PMAS PTSMTP on a separate system from the one on
which your primary SMTP server is running, you will need to modify the
DNS MX records for your domain name to point to the system that's
running the PMAS PTSMTP server. Details on doing this are beyond the
scope of this guide; please consult the documentation for your TCP/IP
software for details on changing the MX record.
1.5.2 Identifying internal IP addresses
PreciseMail Anti-Spam Gateway adds a "Received:" header to every message that passes through the PTSMTP server. This header will resemble the following example:
Received: from pc.example.com(1) ([123.45.67.89](2) EXTERNAL(3)) (EHLO pc.example.com)(4) by alpha.example.com(5) ([10.10.10.10])(6) (PreciseMail V2.1);(7) Tue, 24 Aug 2004 09:30:06 -0500(8) |
The following pieces of information are available in the "Received:" header that PMAS adds:
The choice of "INTERNAL" or "EXTERNAL" for the IP address is determined based on the contents of the file PMAS_DATA:INTERNAL_IP.TXT. This file should list all of the IP addresses and/or subnets that should be considered and marked as "INTERNAL". Each line of the file should specify either an IP address or a CIDR-format subnet IP address, which is a four-octet address followed by a slash and the number of significant bits:
# Each line should specify either an IP address or a CIDR-format IP # address, a slash, and the number of significant bits: # 110.10.10.10 # # The high 29 bits are significant (so IP addresses .40 through .47 # are considered internal). # 110.10.10.40/29 |
Once internal systems are identified, an Allow_Regex rule can be added to your system-wide allow and block list (described in Section 1.6.2) to automatically allow messages originating internally to bypass being scanned by PMAS:
Allow_Regex Received: from \S+ \(\[(?:\d+\.){3}\d+\] INTERNAL\).*
|
In addition to the "Received:" header, PMAS PTSMTP now adds a separate header that indicates whether or not the source was internal or external. The header will be named either "X-PMAS-Internal:" or "X-PMAS-External:", depending on whether or not the sending IP address is listed in INTERNAL_IP.TXT. (Note that the "PMAS" part of the header name is actually the value of the configuration variable HEADER_PREFIX.) The format of the line is:
X-PMAS-Internal: system-name [IP-address] (HELO/EHLO helo-text) |
The "system-name" is the name returned by DNS for the connecting IP address. The "[IP-address]" is the dotted-decimal, numeric IP address of the sending system. The "(HELO helo-text)" reflects the actual HELO or EHLO line used during the SMTP dialogue. As defined by RFC 2821, the HELO/EHLO parameter is supposed to be the name of the sending system, but many spammers will incorrectly use your host's system name or IP address, providing another opportunity to block spam or score it appropriately.
An alternative to the Allow_Regex rule offered above is:
rule allow header:X-PMAS-External noexists |
That will allow any message that does not have an X-PMAS-External:
header, which would be any message from an internal system. This test
is safer than checking for the existence of X-PMAS-Internal: as a
spammer could provide a fake X-PMAS-Internal: header.
1.5.3 Enabling SMTP-Over-TLS Support
If you want the PTSMTP Server to support SMTP-over-TLS, you will need to create TLS certificates. If you do not already have a set of TLS certificates for the system that the PTSMTP Server is running on, you can use the PMAS_EXE:TLS_CERTREQ utility to create them.
The PTSMTP Server expects the public certificate to be named PMAS_DATA:SERVER-PUB.PEM and the private key to be named PMAS_DATA:SERVER-PRIV.PEM . These are the default locations of the certificate files generated by the tls_certreq utility.
The filenames can be overridden by defining the configuration variables PTSMTP_TLS_PUBLIC_CERT and PTSMTP_TLS_PRIVATE_CERT.
Once the TLS certificates are in place, enable the PTSMTP Server's TLS support by specifying values for the ptsmtp_listen_port_tls, ptsmtp_mailserver_host_tls, and ptsmtp_mailserver_port_tls configuration variables.
TLS support over the normal SMTP port (25) is provided using the
STARTTLS command in the SMTP dialogue. To enable STARTTLS support in
the PTSMTP server, define the configuration variable
ptsmtp_enable_starttls as "yes".
1.5.4 DNSBL "DNS Blackhole List" Support
DNSBL (DNS-based Blackhole List) servers maintain lists of IP addresses of known spam systems and open relays. The PMAS PTSMTP proxy server includes support for accessing DNSBL systems to identify incoming email that is being sent by one of these known spam systems. If the sending system is listed in the DNSBL, the message can be rejected during the SMTP session, or a special header can be added to the message's RFC822 headers.
DNSBL lookups work by taking the IP address of the sending system, reversing the order of the address and appending it to the name of the DNSBL system, and performing a DNS (Domain Name System) query. For example, to query the SpamHaus DNSBL for IP address 168.10.20.30, a DNS query is conducted using the system name "30.20.10.168.sbl.spamhaus.org". The response that comes back either indicates that the system is not listed, or a special value in the loopback address range is returned (for example, 127.0.0.2). Different sites return different addresses, which sometimes indicate why a particular site is listed in the DNSBL.
For information on how DNSBL lookups are implemented and the history of DNSBLs, please see the Wikipedia description:
|
A myriad of DNSBL sites exist on the Internet. Some of the sites offer free access to their lists, while others are commercial enterprises. Please check each service's web site for the usage requirements. Process Software does not endorse any particular DNSBL site, but you can find a large list of DNSBL servers at this Open Directory URL:
http://dmoz.org/Computers/Internet/Abuse/Spam/Blacklists/ |
PMAS can be configured to consult multiple DNSBL servers for each
message.
1.5.4.1 Configuring PMAS DNSBL support
To activate the PMAS DNSBL support, simply create the configuration file PMAS_DATA:PTSMTP_DNSBL.CONF and restart PMAS. For your convenience, a sample DNSBL configuration template is provided in PMAS_DATA:PTSMTP_DNSBL.TEMPLATE. You can copy the .TEMPLATE file to .CONF and then edit it as needed.
The configuration file is a simple text file consisting of lines
containing keywords and their parameters. The keywords are described in
the following section. To consult multiple DNSBL servers, simply add a
line for each desired server.
1.5.4.2 DNSBL commands
The format for each line in the DNSBL configuration file is as follows:
dnsbl_block site[=value,...] "Message" dnsbl_reject site[=value,...] "Message" dnsbl_warn site[=value,...] "Header to add to message" dnsbl_accept site dnsbl_allow_host IP-address dnsbl_disallow_host IP-address "Message" dnsbl_allow_email email-address dnsbl_block_email email-address "Message" |
The following table describes each of the DNSBL keywords and their meanings.
| Keyword | Description |
|---|---|
| DNSBL_BLOCK |
Consults the named DNSBL site as soon as the connection is accepted. If
the sender's IP address is listed, a "554" rejection message
(the text of which is taken from the message parameter) is issued
instead of the normal "220" welcome banner. No other commands
will be accepted from the client except "QUIT" (and if a
"QUIT" command is not received within 30 seconds, the
connection is closed by the PMAS PTSMTP proxy server).
Connections blocked using DNSBL_BLOCK are handled by the PMAS PTSMTP proxy server itself and never involve the PMAS PTSMTP worker processes. The client is immediately informed of the rejection and MAIL FROM: and RCPT TO: commands are never received by PMAS. This greatly improves efficiency when receiving large numbers of connections from DNSBL-listed clients. Connections blocked using DNSBL_BLOCK are logged to the file PMAS_LOG:PTSMTP_DNSBL.LOG. New log files are created daily. |
| DNSBL_REJECT | Consults the named DNSBL site and, if the sender's IP address is listed, a "550" rejection message (the text of which is taken from the message parameter) is issued for each received RCPT TO: command. The optional comma-separated list of values can be used to limit matches to specific return addresses from the DNSBL (i.e, 127.1.0.1). |
| DNSBL_WARN |
Consults the named DNSBL site and, if the sender's IP address is
listed, the specified header text is added to the message's headers.
The specified text must be an RFC822-compliant string similar to this
example:
X-PMAS-DNSBL: Sender %%IPADDR%% listed in xxx.xxx |
| DNSBL_ACCEPT | Turns the specified DNSBL site from a list of addresses to block to a list of addresses to accept. |
| DNSBL_ALLOW_HOST | Causes the specified IP address to be accepted regardless of its possible listing in a DNSBL. May be needed to allow a host that has been incorrectly listed with the DNSBL site. |
| DNSBL_DISALLOW_HOST | Works like dnsbl_reject, but no DNSBL site is consulted. All mail from the specified IP address is rejected with "550" SMTP replies containing the specified message text. |
| DNSBL_ALLOW_EMAIL | Causes email with a MAIL FROM: address that matches the email-address parameter to be accepted regardless of the possible listing of the IP address in a DNSBL. May be used to allow specific email through from sites that are often incorrectly listed by DNSBL sites. The email-address parameter may contain wildcards. |
| DNSBL_DISALLOW_EMAIL | Works like dnsbl_reject, but no DNSBL site is consulted. All mail from the specified email address is rejected with "550" SMTP replies containing the specified message text. |
In the "Message" and "Header" strings, two variables can be specified. If present, these variables will be replaced by the resulting values:
| Variable | Description |
|---|---|
| %%IPADDR%% | The sending IP address being checked |
| %%RESULT%% | The resulting IP address returned by the DNSBL |
For DNSBL_WARN, local PMAS rules can be created to assign a score based on the presence of the specified header in the message. For example, assume you specify a header that looks like this:
X-PMAS-DNSBL-XYZ: Sending site listed in XYZ DNSBL |
The following sample rule shows how a score can be added to a message if that header is present.
header XYZ_DNSBL exists:X-PMAS-DNSBL-XYZ describe XYZ_DNSBL Sending system listed in XYZ DNSBL score XYZ_DNSBL 50.000 |
RHSBL (Right-Hand-Side Blackhole List) servers maintain lists of domain names that do not conform to all of the Internet RFCs. The PMAS PTSMTP proxy server includes support for accessing RHSBL systems to identify incoming email that is being sent by one of these known non-compliant systems. If the mail is from a domain listed in the RHSBL, the message can be rejected during the SMTP session, or a special header can be added to the message's RFC822 headers.
RHSBL lookups work by taking the domain name (the right-hand side) of the MAIL FROM: address, appending the name of the RHSBL server, and performing a DNS (Domain Name System) query. For example, to query the abuse.rfc-ignorant.org RHSBL for domain name example.com, a DNS query is conducted using the system name "example.com.abuse.rfc-ignorant.org". The response that comes back either indicates that the system is not listed, or a special value in the loopback address range is returned (for example, 127.0.0.2). Different sites return different addresses, which sometimes indicate why a particular site is listed in the RHSBL.
For information on how RHSBL lookups are implemented and the history of RHSBLs, please see the DNSBL Wikipedia description:
|
Several RHSBL sites exist on the Internet. Some of the sites offer free access to their lists, while others are commercial enterprises. Please check each service's web site for the usage requirements. Process Software does not endorse any particular RHSBL site, but you can find several RHSBL servers listed at this Open Directory URL:
http://dmoz.org/Computers/Internet/Abuse/Spam/Blacklists/ |
PMAS can be configured to consult multiple RHSBL servers for each
message.
1.5.5.1 Configuring PMAS RHSBL support
RHSBL support uses the same configuration file as the DNSBL support (PMAS_DATA:PTSMTP_DNSBL.CONF). For your convenience, a sample DNSBL configuration template is provided in PMAS_DATA:PTSMTP_DNSBL.TEMPLATE. You can copy the .TEMPLATE file to .CONF and then edit it as needed.
The configuration file is a simple text file consisting of lines
containing keywords and their parameters. The keywords are described in
the following section. To consult multiple RHSBL servers, simply add a
line for each desired server.
1.5.5.2 RHSBL commands
The format for each line in the DNSBL configuration file is as follows:
rhsbl_reject site[=value,...] "Message" rhsbl_warn site[=value,...] "Header to add to message" rhsbl_accept site rhsbl_allow_host IP-address rhsbl_disallow_host IP-address "Message" |
The following table describes each of the RHSBL keywords and their meanings.
| Keyword | Description |
|---|---|
| RHSBL_REJECT | Consults the named RHSBL site and, if the sender's IP address is listed, a "550" rejection message (whose text is taken from the message parameter) is issued for each received RCPT TO: command. The optional comma-separated list of values can be used to limit matches to specific return addresses from the RHSBL (i.e, 127.1.0.1). |
| RHSBL_WARN |
Consults the named RHSBL site and, if the sender's IP address is
listed, the specified header text is added to the message's headers.
The specified text must be an RFC822-compliant string similar to this
example:
X-PMAS-RHSBL: Sender %%IPADDR%% listed in xxx.xxx |
| RHSBL_ACCEPT | Turns the specified RHSBL site from a list of addresses to block to a list of addresses to accept. |
| RHSBL_ALLOW_HOST | Causes the specified IP address to be accepted regardless of its possible listing in a RHSBL. May be needed to allow a host that has been incorrectly listed with the RHSBL site. |
| RHSBL_DISALLOW_HOST | Works like rhsbl_reject, but no RHSBL site is consulted. All mail from the specified IP address is rejected with "550" SMTP replies containing the specified message text. |
In the "Message" and "Header" strings, three variables can be specified. If present, these variables will be replaced by the resulting values:
| Variable | Description |
|---|---|
| %%DOMAIN%% | The sending domain name being checked |
| %%RESULT%% | The resulting IP address returned by the RHSBL |
| %%SENDER%% | The full email address of the sender |
For RHSBL_WARN, local PMAS rules can be created to assign a score based on the presence of the specified header in the message. For example, assume you specify a header that looks like this:
X-PMAS-RHSBL-XYZ: Sending site listed in XYZ RHSBL |
The following sample rule shows how a score can be added to a message if that header is present.
header XYZ_RHSBL exists:X-PMAS-RHSBL-XYZ describe XYZ_RHSBL Sending system listed in XYZ RHSBL score XYZ_RHSBL 50.000 |
The PMAS PTSMTP server includes anti-relay support to prevent unwanted relaying of mail messages through your system. An SMTP relay is a system that accepts and forwards mail that is neither to nor from a local user. Spammers often make use of open relays, so it is important to prevent your system from being used in that manner.
When the PMAS PTSMTP proxy server is used, anti-relay support in the backend server cannot be used, as all incoming mail appears to be coming from a single host (the system running the PTSMTP server, which may be the same system running the backend server). By configuring the PMAS PTSMTP anti-relay support, you can safely make use of the PMAS PTSMTP configuration without opening your system up as an open relay.
1.5.6.1 How the PMAS PTSMTP Anti-Relay works
To configure the anti-relay support, you will need to create a file,
PMAS_DATA:LOCAL_DOMAINS.TXT, listing all of the local domains for which
mail should be accepted. Optionally, you can also create a file,
PMAS_DATA:LOCAL_ADDRESSES.TXT, that contains all of the valid email
addresses for specific local domains. If the file doesn't exist, or if
a domain is not represented in that file, all addresses for the local
domains are accepted.
When a new connection is accepted, the IP address of the sending system is checked to see if it's an internal IP address. If it is, it's allowed to relay and send messages. The list of internal IP addresses is stored in PMAS_DATA:INTERNAL_IP.TXT.
If it's an external IP address, each of the RCPT TO: commands received from the sending client is checked to see if the recipient address is in one of the local domains (as defined by LOCAL_DOMAINS.TXT). If the RCPT TO: address is not in one of the local domains, the RCPT TO: command is rejected (and never sent to the backend SMTP server).
If the recipient is in the local domain and the LOCAL_ADDRESSES.TXT files exists, each address is also verified against the list of valid addresses for that domain, if any are defined. The usefulness of LOCAL_ADDRESSES.TXT really only comes into play when you have an SMTP server that relays for a domain but knows nothing about the valid addresses for that domain, so it accepts any and all addresses to forward on. You can use LOCAL_ADDRESSES to restrict the addresses that are accepted.
1.5.6.2 Configuring the Anti-Relay support
The following steps must be taken to enable the PMAS PTSMTP Anti-Relay
support:
The LOCAL_DOMAINS file lists the local domains for which mail should be accepted. Each line in the file should list a domain name, with optional wildcards. Lines beginning with "#" are ignored as comments. A sample LOCAL_DOMAINS.TXT file would look like this:
# Our domains # example.com *.example.com # # Another domain for which we accept mail: # someotherdomain.com |
For information on the format of the INTERNAL_IP.TXT file, please see Section 1.5.2, Identifying internal IP addresses.
The optional LOCAL_ADDRESSES file lists the valid addresses for one or more local domains. Each line in the file specifies an email address. Wildcards can be used in the addresses, and lines beginning with "#" are ignored as comments. For example:
# Accept mail for postmaster postmaster@example.com |
To list multiple addresses for a given domain, you can create a line using the "domain" keyword, followed by lines listing the valid users for that domain (and omitting the domain name). For example:
# # Valid example.com addresses # domain example.com postmaster abuse system joe.user |
All the addresses listed above will have an implicit "@example.com" appended when the address checks are performed. To list multiple domains in the LOCAL_ADDRESSES file, simply repeat the sequence above as needed, specifying the various domains and addresses.
There are also two configuration variables that let you control the reject messages sent to the remote client:
ptsmtp_norelay_reply 550 5.7.1 Relaying not allowed: %s ptsmtp_nouser_reply 550 5.1.1 Illegal or unknown user: %s |
The "%s" in the variable values is replaced with the address
being rejected.
1.6 Message Scoring for Spamicity
PreciseMail Anti-Spam Gateway opens each email message and runs a variety of tests
against the message headers and the text portions of the message body.
Each of these tests has a score associated with it that represents the
likelihood that that test indicates a spam message. Scores can be
positive (spam-like) or negative (non-spam-like); the sum of scores for
all the matching rules represents the message's final score, which is
then used to determine the message's fate (see Section 1.7, Email Message Disposition).
1.6.1 Matching rules
Most of the rules consist of regular expressions that are matched
against the message's headers and body parts. These rules are defined
in files in the PMAS_DATA: directory. It is possible to change the
scores for any of the rules and add new, site-specific rules. See
Chapter 3, The PreciseMail Anti-Spam Gateway Rules, for full details on modifying these rules.
1.6.2 Allow and Block Lists
It is not desirable for all email to pass through PreciseMail Anti-Spam Gateway. Messages from local users, from known users or domains, and from public mailing lists are examples of messages that most sites will not want processed for spamicity, either to avoid the overhead of checking messages that won't be spam or to avoid the risk of a spam-like message from a trusted source being treated as spam.
PreciseMail Anti-Spam Gateway allows sites to specify rules for messages that should always be accepted (allow rules) and rules for messages that should always be rejected (block rules). Both system-wide and user-specific rules are supported. The system-wide rules are defined in the file 00_ALLOWBLOCKLISTS.CF in PMAS_DATA:. This text file can be edited to specify addresses and header-matching regular expressions to determine which messages should always be kept or rejected.
User-defined allow and block rules are normally created by users through the PreciseMail Anti-Spam Gateway Processor, an email-based command processor. They can also be edited with a text editor by system administrators. The user-specific files are stored in PMAS_USERS: and are named like USER.SYSTEM_DOMAIN.
More information on the allow and block rules can be found in
Section 3.9, Adding Allow, Block, Quarantine, and Reject Rules.
1.7 Email Message Disposition
PreciseMail Anti-Spam Gateway can be directed to do several things with a message it
determines to be spam: the message can be discarded; the message can be
quarantined; or the message can have X-PMAS headers added to it or have
its subject line modified and be passed on for delivery.
1.7.1 Quarantining Messages
By default, PreciseMail Anti-Spam Gateway will "quarantine" messages that have a score above a certain threshold (5.0, by default). When a message is quarantined, it is written to the PreciseMail Anti-Spam Gateway quarantine directory (PMAS_ROOT:[QUARANTINE]) and an entry for the message is logged to a quarantine index file. PreciseMail Anti-Spam Gateway then directs the PMDF pmas channel to discard the message instead of forwarding it on for delivery.
At site-defined times of the day, a batch job is executed to process the messages in the quarantine directory. This batch job, "PreciseMail Anti-Spam Gateway Notify," processes the quarantine index file and sends a mail message to each user for whom messages have been quarantined. The mailed message shows the user the Date:, From:, and Subject: of each message that has been quarantined on his or her behalf and includes instructions that allow the user to retrieve a quarantined message.
Quarantined messages are kept for a certain site-defined number of days
(14 is the default), after which time they are automatically deleted
from the system.
1.7.2 Discarding Messages
PreciseMail Anti-Spam Gateway can be configured to discard messages that have a score above a certain discard threshold value. If discarding is enabled, discarded messages are not really deleted by default. Instead, they are written to the PreciseMail Anti-Spam Gateway discard directory (PMAS_ROOT:[DISCARD]), where they are kept for a site-defined number of days (14 is the default). The difference between the discard and quarantine directories is that users are not notified of messages that are discarded.
The discard directory is maintained for emergency retrieval of messages that scored above the discard threshold. Because spam detection is not an exact science, and because legitimate message contents vary from site to site, it is possible that a message might trigger enough rules to be discarded, but still be considered legitimate by a site. Instead of such messages being thrown away, they are kept in the discard directory to allow system administrators to retrieve them, if necessary.
As of PMAS V2.3, a discard index file is maintained (as is done for the quarantined messages) and PMAS system administrators can view the discarded messages via the PMAS admin GUI web interface. Administrators can also choose to allow users to view their own discarded messages, but that will probably confuse most novice users.
If a message was mistakenly discarded, it can be released via the PMAS admin GUI web interface or by sending a message to the PreciseMail Processor to release the message. |
Messages that are not quarantined or discarded are forwarded on for delivery to their target recipients. By default, PreciseMail Anti-Spam Gateway will add X-PMAS headers to the RFC822 headers of messages that have a non-zero score to indicate which rules were triggered by a particular message. Typical headers that are added will look like this:
X-PMAS-BDY-MAILTO_LINK: Includes a URL link to send an email (0.100) X-PMAS-META-MANY_EXCLAMATIONS: Subject has many exclamations (1.097) X-PMAS-Final-Score: 1.197 |
The first two lines indicate two of the rules the message triggered, and the last line shows its final score.
PreciseMail Anti-Spam Gateway can also be configured to modify the subject lines of messages that have scores above a certain threshold. If enabled, "[SPAM]", or any site-defined string, will be prepended to subject lines of messages.
Depending on the mail clients in use, users can configure their mail
clients or PMDF Sieve files to automatically route messages with
certain X-PMAS headers or a modified subject line to "spam
suspect" folders.
1.7.4 Rejecting Messages
PreciseMail Anti-Spam Gateway can be configured to reject messages that have a score above a certain reject threshold value if the PMAS Pass-Through SMTP Server (PTSMTP) is used. By rejecting messages, you eliminate the overhead of having those messages processed by your primary mail software, and you might encourage spammers to drop that particular address (though that's probably not very likely).
Messages that are rejected are never stored on your system, so it is not possible to recover rejected messages. Care should be taken to ensure that the rejection threshold is set to an appropriate level.
By default, enabling the rejection of messages causes PMAS to reject blocklisted messages instead of silently discarding them. You can adjust the BLOCK_SCORE keyword to prevent this from happening, if you don't want blocklisted messages rejected. |
PreciseMail Anti-Spam Gateway maintains a log file showing the disposition of each message processed. The log file is named PMAS.LOG and can be found in PMAS_LOG:. Each entry in the log file is made up of nine different fields, all separated by a vertical bar "|":
The disposition codes that may be found in the file are shown in the table below.
| Code | Meaning | Description |
|---|---|---|
| N | Nada | Nothing was done to the message, which was forwarded to the user; only found if there was a severe error during processing |
| O | Opt-out | User opted-out of PMAS scanning |
| F | Forward | Message was forwarded to the user |
| D | Discard | Message was discarded |
| Q | Quarantine | Message was quarantined |
| q | Quarantine | Message was quarantined by a user-defined rule |
| T | Tag | Message was tagged |
| A | Allowed | Message matched a system-wide allow rule and was forwarded |
| B | Blocked | Message matched a system-wide block rule and was discarded |
| a | User Allowed | Message matched a user-defined allow rule and was forwarded |
| b | User Blocked | Message matched a user-defined block rule and was discarded |
| R | Rejected | Message was rejected during SMTP session |
| L | Listed | Message was rejected via a DNSBL or RHSBL lookup |
A nightly batch job creates a new PMAS.LOG file each day. The
previous day's log file is renamed to .LOG-yyyy-mm-dd.
1.9 Statistics
Statistics about the messages processed by PreciseMail Anti-Spam Gateway can be generated using the pmas_stats program in PMAS_EXE:. On VMS, a foreign symbol should be defined to execute the file. It takes two parameters: the name of the log file and an optional output file name. If an output file name is not specified, the statistics information is written to your terminal.
$ PMASTATS :== $PMAS_EXE:PMAS_STATS.EXE $ PMASTATS PMAS_LOG:PMAS.LOG-2003-06-26 X.X |
When processing messages, PreciseMail Anti-Spam Gateway will look for an alias file (aliases.txt in PMAS_DATA:, by default). This file specifies alternate addresses that are to be used when quarantining messages for certain recipients. For example, the quarantine notification messages for a mailing list should typically be directed to an alternate user and not to the mailing list itself.
Beginning with PMAS V2.4, the PMAS alias file is included in the compiled configuration global section produced by PMAS_COMPILE.EXE. Any time the PMAS alias file is updated, the global section should be recompiled:
|
Each entry in the file consists of two to four items separated by whitespace:
An entry in the alias file to route quarantine notices to another address might look like:
info-apes@example.com owner-info-apes@example.com |
Quarantine notification messages for mail destined for "info-apes" will be sent to "owner-info-apes" instead.
Alias lookups are case-insensitive. Wildcards are supported for the incoming address (the left-side of an entry); valid wildcard characters are "*" to match any number of characters and "?" to match any single character.
Other sample aliases might look like these lines:
# # Various aliases for Galen # galen@nodea.example.com galen@example.com sales@example.com galen@example.com # info-*@example.com galen@example.com |
The alias file is also consulted by PreciseMail Anti-Spam Gateway when it looks for user-defined allow/block files. Using the example above, a message coming in for "sales" will be compared against the allow/block rules for "galen@example.com".
Finally, the alias file is also consulted by the PreciseMail Anti-Spam Gateway User
Interface when a user logs in. By performing alias lookups, users with
multiple email addresses that all point to the same account can log in
under any of those addresses by specifying the proper password for the
resulting alias. Using the example above, a user can log in to
"sales@example.com" by specifying the password for
"galen@example.com".
1.10.1 Regular expressions
For more sophisticated wildcard matching and substitution, regular expressions are also supported. To specify that an address (the value on the left) is a regular expression, it should begin and end with a vertical bar "|". The regular expression matching is caseless (lowercase and uppercase are treated the same). You can use parentheses within the expression to assign matching substrings to variables named $1, $2, through $9 for substitution in the resulting alias. For example, the following entry will convert all email addresses of the form "First.Last@example" to "last@example":
|.+\.(.+)@example\.com| $1@example.com |
The parentheses above capture the substring between the "."
and the "@", assigning it to variable $1. For the email
address "Joe.User@example.com", the resulting alias would be
"User@example.com".
1.10.2 Special Mailing List Aliases
There is one special case for the alias address (the right side). When a user releases a message listed in a quarantine notice, the message is released to the original envelope address; in the case of a mailing list with no alias entry, the message would be released to the mailing list address. It may be desirable to allow quarantine notices to be sent to a mailing list (and thus to all the members of that list) and allow any one of those recipients to release the quarantined message without having the message released to all recipients. You can designate such a list using the special "*" alias address:
info-apes@example.com * |
With that entry, mail sent to "info-apes" that is to be quarantined will result in the quarantine notice being sent to "info-apes@example.com". Any recipient of that notice can release the message, but the released message will be sent only to the requesting user and not to the list.
As a security measure, the PreciseMail Anti-Spam Gateway Processor will only release messages to the original envelope To: address, regardless of the return address for the release request. A malicious user could request the release of a message (if he or she knows the filename for a message), but the message will only be mailed to the original recipient and not to the malicious user. The special "*" alias above circumvents this process, allowing anyone to release and receive one of these special messages if he or she knew the filename to release. This is a very unlikely scenario, but you should be aware of it when setting up such an alias. |
The optional third and fourth values on a line in the alias file are used for authenticating access via the web-based PreciseMail Anti-Spam Gateway User Interface. They can be specified to allow access to quarantine areas for addresses that do not actually have a direct user correlation. For example, you might want to redirect mailing list quarantine notices to a special address like this:
info-*@example.com owner-info-blah@example.com |
For all the "info-*" lists, quarantine notices and allow/block lookups will use the address "owner-info-blah". While you could specify a particular user's email address, that would result in a quarantine notice possibly mixing that user's personal mail with the mailing list mail. The alias above will generate a separate quarantine notice, but there also would not be a way to use the web-based user interface if "owner-info-blah" isn't a real account. By using an authentication alias, you can specify the user account against which the user interface should authenticate. For example:
info-*@example.com owner-info-blah@example.com joe@example.com |
User "joe" can log into the user interface using the email address "owner-info-blah@example.com" and supplying the password for account "joe@example.com". As long as the password matches, the user will be logged in as "owner-info-blah@example.com".
The various authentication methods are defined using the PMAS configuration variable AUTH_METHODS ( Section 2.2.12.1). Those methods can be overridden for a particular alias by specifying a particular method as the optional fourth parameter. For example, if user "joe" should be authenticated via IMAP4 from a particular system, the following entry can be used:
joe@example.com joe@example.com joe@imap4.somewhere.com imap4 |
When this user logs in, PMAS will use IMAP4 authentication using the IMAP4 server "imap4.somewhere.com" and the username "joe". IMAP4 and POP3 servers usually authenticate using only the username portion of an address. However, some servers support virtual domains and require the full email address for authentication. To effect this requirement, the qualifier "/virtual" can be appended to "imap4" or "pop3":
joe@example.com joe@example.com joe@imap4.somewhere.com imap4/virtual |
The PreciseMail Anti-Spam Gateway Processor is an email-based user interface to PreciseMail Anti-Spam Gateway. Users can send mail to a special email address that's routed to the processor via the PIPE channel or a command alias (please see the PreciseMail Anti-Spam Gateway Installation Guide for details). Processor commands are included in the body of the message. The PreciseMail Anti-Spam Gateway Processor can be used to release quarantined messages and to create and manage user-defined allow/block files.
This chapter describes the PreciseMail Anti-Spam Gateway configuration file and the configuration keywords.
All of the configuration files are stored in the directory
PMAS_DATA:.
2.1 Configuration file
The primary PreciseMail Anti-Spam Gateway configuration file is named PMAS_CONFIG.DAT. It is a text file that consists of keywords and their associated settings. To change a setting, simply add or modify a line to specify a new value for a given keyword.
When PreciseMail Anti-Spam Gateway is installed, a PMAS_CONFIG.TEMPLATE file is provided that lists and documents all of the available configuration settings. If you wish to customize the PreciseMail Anti-Spam Gateway configuration, simply copy this .template file to PMAS_CONFIG.DAT and edit it as desired.
Comments can be included in the file by starting the line with "#" or "!". A partial sample file looks like this:
# # PreciseMail Anti-Spam Gateway Config File # Last modified: 26-JUN-2003 00:55 by GOATHUNTER # add_headers yes quarantine_messages yes discard_messages yes discard_threshold 20.0 |
Table 2-1 and Table 2-2 list the configuration keywords, while the subsequent subsections describe the keywords in some detail.
| Keyword | Section | Description |
|---|---|---|
| ADD_HEADERS | Section 2.2.2.1 | Controls if X-PMAS headers are added |
| ADD_SPAM_YES_HEADER | Section 2.2.2.2 | Controls if "X-PMAS-Spam: Yes" header is added |
| ADD_SPAM_YES_THRESHOLD | Section 2.2.2.3 | Threshold for adding "X-PMAS-Spam: Yes" header |
| ADMIN_EMAIL_ADDRESS | Section 2.2.11.15 | The system administrator email address |
| ALIAS_FILE | Section 2.2.15.1 | Specifies the address alias filename |
| ALLOW_USER_DISCARD | Section 2.2.11.18 | Allow users to discard messages |
| ALLOW_USER_OPTIN | Section 2.2.11.17 | Allow users to opt in or out |
| ALLOW_USER_QUARANTINE | Section 2.2.11.19 | Allow users to quarantine messages |
| ALLOW_USER_TAGGING | Section 2.2.11.20 | Allow users to tag messages |
| ANTIVIRUS_ENABLED | Section 2.2.10.1 | Enables anti-virus scanning in PTSMTP proxy server |
| ANTIVIRUS_DIR | Section 2.2.10.3 | Specifies the location of the anti-virus data files |
| ANTIVIRUS_PACKAGE | Section 2.2.10.2 | Specifies the name of the anti-virus package |
| AUTH_IMAP4_HOSTS | Section 2.2.12.4 | List of IMAP4 authentication hosts |
| AUTH_METHODS | Section 2.2.12.1 | Lists the available authorization methods |
| AUTH_POP3_HOSTS | Section 2.2.12.2 | List of POP3 authentication hosts |
| AUTOBAYESIAN_HAM_THRESHOLD | Section 2.2.13.3 | Autotraining for ham threshold |
| AUTOBAYESIAN_SPAM_THRESHOLD | Section 2.2.13.4 | Autotraining for spam threshold |
| AUTOTRAIN_BAYESIAN | Section 2.2.13.2 | Controls the autotraining of the Bayesian engine |
| AUTOUPDATE_ADDRESS | Section 2.2.18.5 | Specifies email address used for email-based updates |
| AUTOUPDATE_RULES | Section 2.2.18.1 | Controls whether or not automatic ruleset updates are performed |
| AUTOUPDATE_SOPHOS | Section 2.2.18.3 | Controls whether or not Sophos AV database updates are performed |
| AUTOUPDATE_STATS | Section 2.2.18.4 | Controls the uploading of spam-related statistical data to Process Software |
| AUTOUPDATE_TIMES | Section 2.2.18.2 | Specifies specific times to check for PMAS rules updates |
| BAYESIAN_MULTIPLIER | Section 2.2.13.5 | Multiplier for the Bayesian spamicity rating |
| BLOCK_SCORE | Section 2.2.5.3 | Specifies the score assigned to messages that are blocked. May be adjusted to reject blocked messages instead of discarding them. |
| CLU_CLIENTS | Section 2.2.19.1 | Specifies secondary nodes of a Data Synchronization Cluster. |
| CLU_SERVER | Section 2.2.19.2 | Specifies the primary node of a Data Synchronization Cluster. |
| CLU_SERVER_CLIENT | Section 2.2.19.3 | Enables Data Synchronization Cluster functionality. |
| DEBUG_LEVEL | Section 2.2.14.1 | The debug message output level |
| DEBUG_LOGFILE | Section 2.2.14.2 | Specifies the name of the debug log file |
| DISCARD_DIRECTORY | Section 2.2.4.4 | Specifies the discard directory tree |
| DISCARD_MESSAGES | Section 2.2.4.1 | Controls the discarding of messages |
| DISCARD_MSG_LIFETIME | Section 2.2.4.3 | The number of days discarded messages are kept |
| DISCARD_THRESHOLD | Section 2.2.4.2 | The score threshold for discarding messages |
| DYNAMIC_URI_SCANNING | Section 2.2.7.1 | Enable dynamic URI filtering |
| DYN_URI_CONNECT_TIMEOUT | Section 2.2.7.8 | Specifies a connect timeout for dynamic URI checks |
| DYN_URI_PHISH_DOMAIN_SCORE | Section 2.2.7.2 | Score assigned to a known phishing domain |
| DYN_URI_SPAM_DOMAIN_SCORE | Section 2.2.7.3 | Score assigned to a known spam domain |
| DYN_URI_SPAMVERTISED_DOMAIN_SCORE | Section 2.2.7.4 | Score assigned to a domain that appears in spam messages |
| DYN_URI_HONEYPOT_DOMAIN_SCORE | Section 2.2.7.5 | Score assigned to a domain that appears in spams sent to a honeypot |
| DYN_URI_INTERNAL_ERROR_SCORE | Section 2.2.7.6 | Score assigned to a domain that causes an error in the checking system |
| DYN_URI_OK_URL_SCORE | Section 2.2.7.7 | Score assigned to an OK domain |
| GATHER_STATS | Section 2.2.15.2 | Enables or disables the gathering of PMAS statistics. |
| GUI_ALLOW_DISCARD_VIEW | Section 2.2.11.11 | Allow users to view their discarded messages |
| GUI_ALLOW_QUARALL_DEFAULT | Section 2.2.11.7 | Allow users to set their default quarantined message display to "all" |
| GUI_ALLOW_QUARANTINE_ALL | Section 2.2.11.6 | Allow users to display all their quarantined messages |
| GUI_COOKIE_LIFETIME | Section 2.2.11.1 | Specifies the lifetime in hours of the PMAS login cookie |
| GUI_DEFAULT_QUARANTINE_ALL | Section 2.2.11.8 | Change the default display for quarantined messages to ALL |
| GUI_DELETE_UPON_RELEASE | Section 2.2.11.9 | Causes released messages to be deleted from the quarantine |
| GUI_FORCE_JAVA_SORT_OPERA | Section 2.2.11.13 | Forces usage of the Javascript quarantine sort with the Opera browser |
| GUI_JAVA_SORT_MAXMSG | Section 2.2.11.12 | Specifies the maximum number of messages for a quarantine view in which the Javascript sort is used |
| GUI_RENAME_UPON_DELETE | Section 2.2.11.10 | Causes deleted messages to actually be renamed to _DELETED |
| GUI_URI_HOST | Section 2.2.11.2 | Specifies the host name used in PMAS URLs |
| GUI_URI_PATH | Section 2.2.11.4 | Specifies the path name for PMAS URLs |
| GUI_URI_PROTOCOL | Section 2.2.11.5 | Specifies the protocol for the served pages |
| GUI_URI_SCRIPT_PATH | Section 2.2.11.3 | Specifies the script path name for PMAS URLs |
| HEADER_PREFIX | Section 2.2.2.4 | The prefix appended to message headers added by PMAS |
| IMAP4_CONNECT_TIMEOUT | Section 2.2.12.5 | Specifies a connect timeout for IMAP4 authorization requests |
| LDAP_AUTH_FILTER | Section 2.2.12.8 | The LDAP search filter |
| LDAP_AUTH_SERVER | Section 2.2.12.6 | LDAP server name |
| LDAP_BASE_DN | Section 2.2.12.7 | The LDAP base distinguished name |
| LDAP_GROUP_FILTER | Section 2.2.12.9 | The LDAP search filter for user groups |
| LDAP_GROUPMEMBER_ATTR | Section 2.2.12.10 | The name of the attribute that contains a group member's DN |
| LDAP_SEARCHACCT_DN | Section 2.2.12.11 | The Distinguished Name of the LDAP search user |
| LDAP_SEARCHACCT_PASSWORD | Section 2.2.12.12 | The password for the LDAP search user |
| LDAP_USE_TLS | Section 2.2.12.13 | Enables use of LDAPS for user authentication |
| LOCAL_DOMAIN_NAME | Section 2.2.1.2 | Specifies the default local domain name |
| MASTER_LOGFILE | Section 2.2.15.3 | Specifies the master log file name |
| MIME_HELP_MESSAGE | Section 2.2.17.5 | Specifies that the HELP reply is a MIME message |
| MIME_QUARANTINE_MESSAGE | Section 2.2.16.1 | Controls the type of quarantine notification messages |
| MODIFY_SUBJECT | Section 2.2.2.5 | Controls if Subject: lines are modified |
| MODIFY_SUBJECT_APPEND | Section 2.2.2.6 | Appends the subject_tag to Subject: lines |
| MODIFY_SUBJECT_THRESHOLD | Section 2.2.2.7 | The score threshold for modifying Subject: lines |
| NOTIFY_DEBUG_LEVEL | Section 2.2.16.7 | The debug message level for the notify job |
| NOTIFY_JOB_NAME | Section 2.2.16.6 | Specifies the notification batch job name |
| NOTIFY_MSG_SUBJECT | Section 2.2.16.2 | Specifies the Subject: line for quarantine notification messages |
| NOTIFY_QUEUE | Section 2.2.16.3 | Specifies the queue for the notification batch job |
| NOTIFY_RUN_USER | Section 2.2.16.5 | Specifies the username under which the notification batch job runs |
| NOTIFY_TIMES | Section 2.2.16.4 | Specifies the times the notification batch job is run |
| OPT_IN_BY_DEFAULT | Section 2.2.11.16 | Specifies the "opt-in" default for users |
| POP3_CONNECT_TIMEOUT | Section 2.2.12.3 | Specifies a connect timeout for POP3 authorization requests |
| PMAS_SYSTEM_NAME | Section 2.2.2.8 | The system name added to the X-PMAS-Software: header |
| PROCESSOR_USER_ADDRESS | Section 2.2.17.2 | The full email address for the PreciseMail Anti-Spam Gateway Processor |
| PROCESSOR_USER_NAME | Section 2.2.17.1 | The local username for the PreciseMail Anti-Spam Gateway Processor |
| PTSMTP_BASE_PRIORITY | Section 2.2.9.14 | Specifies the VMS base priority for the PMAS PTSMTP controller process. |
| PTSMTP_ENABLE_STARTTLS | Section 2.2.9.8 | Enables STARTTLS support in the PMAS PTSMTP server. |
| PTSMTP_IDLE_TIME | Section 2.2.9.13 | Specifies the number of seconds a temporary PMAS PTSMTP process is idle before it exits. |
| PTSMTP_LISTEN_HOST | Section 2.2.9.1 | Specifies the interface IP addresses on which the PMAS PTSMTP Server listens for incoming SMTP connections. |
| PTSMTP_LISTEN_PORT | Section 2.2.9.2 | Specifies the port on which the PMAS PTSMTP Server listens for incoming SMTP connections. |
| PTSMTP_LISTEN_PORT_TLS | Section 2.2.9.5 | Specifies the port on which the PMAS PTSMTP Server listens for incoming SMTP-over-TLS connections. |
| PTSMTP_MAILSERVER_HOST | Section 2.2.9.3 | Specifies the hostname for the system on which the primary SMTP server is running. |
| PTSMTP_MAILSERVER_HOST_TLS | Section 2.2.9.6 | Specifies the hostname for the primary SMTP server that supports TLS. |
| PTSMTP_MAILSERVER_PORT | Section 2.2.9.4 | Specifies the port number for the primary SMTP server. |
| PTSMTP_MAILSERVER_PORT_TLS | Section 2.2.9.7 | Specifies the port number that the primary SMTP server listens to for incoming TLS connections. |
| PTSMTP_QUARANTINE_REPLY | Section 2.2.9.15 | Specifies the SMTP-dialogue message that's sent to the SMTP client when a message is quarantined. |
| PTSMTP_NORELAY_REPLY | Section 2.2.9.19 | Specifies the SMTP-dialogue message that's sent to the SMTP client when a message is rejected due to anti-relay. |
| PTSMTP_NOUSER_REPLY | Section 2.2.9.20 | Specifies the SMTP-dialogue message that's sent to the SMTP client when a message is rejected because the specified address is not a valid local address. |
| PTSMTP_REJECT_REPLY | Section 2.2.9.16 | Specifies the SMTP-dialogue message that's sent to the SMTP client when a message is rejected. |
| PTSMTP_TLS_PRIVATE_CERT | Section 2.2.9.9 | Specifies the filename of the TLS private certificate. |
| PTSMTP_TLS_PUBLIC_CERT | Section 2.2.9.10 | Specifies the filename of the TLS public certificate. |
| PTSMTP_WORKER_MIN | Section 2.2.9.11 | Specifies the number of permanent PTSMTP worker processes that run to handle incoming SMTP connections. |
| PTSMTP_WORKER_MAX | Section 2.2.9.12 | Specifies the maximum number of PTSMTP worker processes that can run at any one time to handle incoming SMTP connections. |
| QUARANTINE_DIRECTORY | Section 2.2.3.4 | Specifies the quarantine directory tree |
| QUARANTINE_INDEX_FILE | Section 2.2.3.5 | Specifies the name of the quarantine index file |
| QUARANTINE_MESSAGES | Section 2.2.3.1 | Controls the quarantining of messages |
| QUARANTINE_MSG_LIFETIME | Section 2.2.3.3 | The number of days quarantined messages are kept |
| QUARANTINE_RFC822_FROM | Section 2.2.3.6 | Controls which From: address is used for quarantine notification |
| QUARANTINE_RFC822_TO | Section 2.2.3.7 | Controls which To: address is displayed in quarantine notifications |
| QUARANTINE_THRESHOLD | Section 2.2.3.2 | The score threshold for quarantining messages |
| PMAS_PROCESS_DEBUG_LEVEL | Section 2.2.17.3 | The debug message output level for the PreciseMail Anti-Spam Gateway Processor |
| PMAS_PROCESS_DEBUG_LOGFILE | Section 2.2.17.4 | The name of the Processor debug log file |
| REJECT_MESSAGES | Section 2.2.5.1 | Enables the rejection of messages by the PMAS PTSMTP Server. |
| REJECT_THRESHOLD | Section 2.2.5.2 | Specifies the spam score threshold at which incoming SMTP messages are rejected. |
| REPUTATION_URI_ENABLED | Section 2.2.8.1 | Enables reputation URI filtering |
| REP_URI_MULTIPLIER | Section 2.2.8.2 | Specifies a multiplier that is applied to the reputation URI results |
| REP_URI_NONSPAM_EFFECTS | Section 2.2.8.3 | Causes non-spam reputation URI results to affect the score |
| REP_URI_PHISH_SCORE | Section 2.2.8.4 | Additional score for a phishing site |
| REP_URI_ADULT_SCORE | Section 2.2.8.5 | Additional score for an adult site |
| SMTP_MAILSERVER_HOST | Section 2.2.9.17 | Specifies the SMTP server hostname for messages generated by PMAS. |
| SMTP_MAILSERVER_PORT | Section 2.2.9.18 | Specifies the listen port for the SMTP Server that receives messages generated by PMAS. |
| SPAM_LEVEL_CHAR | Section 2.2.2.11 | Specifies the character used for X-PMAS-Spam-Level header |
| SPAM_LEVEL_STARS | Section 2.2.2.10 | Controls if X-PMAS-Spam-Level header is added |
| STATS_USE_THRESHOLDS | Section 2.2.4.5 | Enables pmas_stats program to use configuration file threshold values when not quarantining or discarding |
| SUBJECT_TAG | Section 2.2.2.9 | Specifies the text prepended to modified Subject: lines |
| UPDATES_CONNECT_TIMEOUT | Section 2.2.18.6 | Specifies a connect timeout for rule update checks |
| USE_BAYESIAN | Section 2.2.13.1 | Enables or disables use of the Bayesian engine |
| USE_CURRENT_ENVELOPE_TO | Section 2.2.1.1 | Selects which envelope to address is used |
| USER_DATABASE | Section 2.2.11.14 | The name of the PMAS user preferences database |
| USER_RULES_DIRECTORY | Section 2.2.15.4 | Specifies the directory in which user allow/block files are stored |
| USERLIST_SUBDIR_LEVEL | Section 2.2.15.5 | Specifies the number of subdirectories used for storing user allow and block list files |
| VERIFY_MAIL_FROM_ADDRESSES | Section 2.2.6.1 | Enables verification of envelope MAIL FROM: addresses |
| VERIFY_MAIL_FROM_TIMEOUT | Section 2.2.6.2 | Specifies the timeout in seconds for MAIL FROM: verification connections |
| VIRUS_DISPOSITION | Section 2.2.10.4 | Specifies the action to take for virus-laden messages |
| VMF_CONNECT_TIMEOUT | Section 2.2.6.10 | Specifies a connect timeout for VMF checks |
| VMF_ERROR_SCORE | Section 2.2.6.3 | Score assigned on a MAIL FROM: verification error |
| VMF_NO_DNS_SCORE | Section 2.2.6.4 | Score assigned for no DNS entry during MAIL FROM: verification |
| VMF_NO_ADDRESS_SCORE | Section 2.2.6.5 | Score assigned for rejection during MAIL FROM: verification |
| VMF_NO_MAILFROM_SCORE | Section 2.2.6.6 | Score assigned for invalid address during MAIL FROM: verification |
| VMF_NO_MX_SCORE | Section 2.2.6.7 | Score assigned for no MX record during MAIL FROM: verification |
| VMF_NO_SMTP_SCORE | Section 2.2.6.8 | Score assigned for no SMTP server during MAIL FROM: verification |
| VMF_OK_SCORE | Section 2.2.6.9 | Score assigned for accepted address during MAIL FROM: verification |
| Keyword | Section | Description |
|---|---|---|
| Modifying Messages | ||
| ADD_HEADERS | Section 2.2.2.1 | Controls if X-PMAS headers are added |
| ADD_SPAM_YES_HEADER | Section 2.2.2.2 | Controls if "X-PMAS-Spam: Yes" header is added |
| ADD_SPAM_YES_THRESHOLD | Section 2.2.2.3 | Threshold for adding "X-PMAS-Spam: Yes" header |
| HEADER_PREFIX | Section 2.2.2.4 | The prefix appended to message headers added by PMAS |
| MODIFY_SUBJECT | Section 2.2.2.5 | Controls if Subject: lines are modified |
| MODIFY_SUBJECT_APPEND | Section 2.2.2.6 | Appends the subject_tag to Subject: lines |
| MODIFY_SUBJECT_THRESHOLD | Section 2.2.2.7 | The score threshold for modifying Subject: lines |
| PMAS_SYSTEM_NAME | Section 2.2.2.8 | The system name added to the X-PMAS-Software: header |
| SUBJECT_TAG | Section 2.2.2.9 | Specifies the text prepended to modified Subject: lines |
| SPAM_LEVEL_STARS | Section 2.2.2.10 | Controls if X-PMAS-Spam-Level header is added |
| SPAM_LEVEL_CHAR | Section 2.2.2.11 | Specifies the character used for X-PMAS-Spam-Level header |
| Quarantining Messages | ||
| QUARANTINE_DIRECTORY | Section 2.2.3.4 | Specifies the quarantine directory tree |
| QUARANTINE_INDEX_FILE | Section 2.2.3.5 | Specifies the name of the quarantine index file |
| QUARANTINE_MESSAGES | Section 2.2.3.1 | Controls the quarantining of messages |
| QUARANTINE_MSG_LIFETIME | Section 2.2.3.3 | The number of days quarantined messages are kept |
| QUARANTINE_RFC822_FROM | Section 2.2.3.6 | Controls which From: address is used for quarantine notification |
| QUARANTINE_RFC822_TO | Section 2.2.3.7 | Controls which To: address is displayed in quarantine notifications |
| QUARANTINE_THRESHOLD | Section 2.2.3.2 | The score threshold for quarantining messages |
| Discarding Messages | ||
| DISCARD_MESSAGES | Section 2.2.4.1 | Controls the discarding of messages |
| DISCARD_THRESHOLD | Section 2.2.4.2 | The score threshold for discarding messages |
| DISCARD_MSG_LIFETIME | Section 2.2.4.3 | The number of days discarded messages are kept |
| DISCARD_DIRECTORY | Section 2.2.4.4 | Specifies the discard directory tree |
| Rejecting Messages (PMAS PTSMTP only) | ||
| REJECT_MESSAGES | Section 2.2.5.1 | Enables the rejection of messages by the PMAS PTSMTP Server. |
| REJECT_THRESHOLD | Section 2.2.5.2 | Specifies the spam score threshold at which incoming SMTP messages are rejected. |
| BLOCK_SCORE | Section 2.2.5.3 | Specifies the score assigned to messages that are blocked. May be adjusted to reject blocked messages instead of discarding them. |
| User Interface Keywords | ||
| GUI_COOKIE_LIFETIME | Section 2.2.11.1 | Specifies the lifetime in hours of the PMAS login cookie |
| GUI_URI_HOST | Section 2.2.11.2 | Specifies the host name used in PMAS URLs |
| GUI_URI_PATH | Section 2.2.11.4 | Specifies the path name for PMAS URLs |
| GUI_URI_PROTOCOL | Section 2.2.11.5 | Specifies the protocol for the served pages |
| GUI_URI_SCRIPT_PATH | Section 2.2.11.3 | Specifies the script path name for PMAS URLs |
| GUI_ALLOW_QUARALL_DEFAULT | Section 2.2.11.7 | Allow users to set their default quarantined message display to "all" |
| GUI_ALLOW_QUARANTINE_ALL | Section 2.2.11.6 | Allow users to display all their quarantined messages |
| GUI_DEFAULT_QUARANTINE_ALL | Section 2.2.11.8 | Change the default display for quarantined messages to ALL |
| GUI_DELETE_UPON_RELEASE | Section 2.2.11.9 | Causes released messages to be deleted from the quarantine |
| GUI_FORCE_JAVA_SORT_OPERA | Section 2.2.11.13 | Forces usage of the Javascript quarantine sort with the Opera browser |
| GUI_JAVA_SORT_MAXMSG | Section 2.2.11.12 | Specifies the maximum number of messages for a quarantine view in which the Javascript sort is used |
| GUI_RENAME_UPON_DELETE | Section 2.2.11.10 | Causes deleted messages to actually be renamed to _DELETED |
| GUI_ALLOW_DISCARD_VIEW | Section 2.2.11.11 | Allow users to view their discarded messages |
| USER_DATABASE | Section 2.2.11.14 | The name of the PMAS user preferences database |
| ADMIN_EMAIL_ADDRESS | Section 2.2.11.15 | The system administrator email address |
| OPT_IN_BY_DEFAULT | Section 2.2.11.16 | Specifies the "opt-in" default for users |
| ALLOW_USER_OPTIN | Section 2.2.11.17 | Allow users to opt in or out |
| ALLOW_USER_DISCARD | Section 2.2.11.18 | Allow users to discard messages |
| ALLOW_USER_QUARANTINE | Section 2.2.11.19 | Allow users to quarantine messages |
| ALLOW_USER_TAGGING | Section 2.2.11.20 | Allow users to tag messages |
| User Authentication Keywords | ||
| AUTH_METHODS | Section 2.2.12.1 | Lists the available authorization methods |
| AUTH_POP3_HOSTS | Section 2.2.12.2 | List of POP3 authentication hosts |
| POP3_CONNECT_TIMEOUT | Section 2.2.12.3 | Specifies a connect timeout for POP3 authorization requests |
| AUTH_IMAP4_HOSTS | Section 2.2.12.4 | List of IMAP4 authentication hosts |
| IMAP4_CONNECT_TIMEOUT | Section 2.2.12.5 | Specifies a connect timeout for IMAP4 authorization requests |
| LDAP_AUTH_FILTER | Section 2.2.12.8 | The LDAP search filter |
| LDAP_AUTH_SERVER | Section 2.2.12.6 | LDAP server name |
| LDAP_BASE_DN | Section 2.2.12.7 | The LDAP base distinguished name |
| LDAP_GROUP_FILTER | Section 2.2.12.9 | The LDAP search filter for user groups |
| LDAP_GROUPMEMBER_ATTR | Section 2.2.12.10 | The name of the attribute that contains a group member's DN |
| LDAP_SEARCHACCT_DN | Section 2.2.12.11 | The Distinguished Name of the LDAP search user |
| LDAP_SEARCHACCT_PASSWORD | Section 2.2.12.12 | The password for the LDAP search user |
| LDAP_USE_TLS | Section 2.2.12.13 | Enables use of LDAPS for user authentication |
| Bayesian Engine keywords | ||
| USE_BAYESIAN | Section 2.2.13.1 | Enables or disables use of the Bayesian engine |
| AUTOTRAIN_BAYESIAN | Section 2.2.13.2 | Controls the autotraining of the Bayesian engine |
| AUTOBAYESIAN_HAM_THRESHOLD | Section 2.2.13.3 | Autotraining for ham threshold |
| AUTOBAYESIAN_SPAM_THRESHOLD | Section 2.2.13.4 | Autotraining for spam threshold |
| BAYESIAN_MULTIPLIER | Section 2.2.13.5 | Multiplier for the Bayesian spamicity rating |
| MAIL FROM: verification keywords | ||
| VERIFY_MAIL_FROM_ADDRESSES | Section 2.2.6.1 | Enables verification of envelope MAIL FROM: addresses |
| VERIFY_MAIL_FROM_TIMEOUT | Section 2.2.6.2 | Specifies the timeout in seconds for MAIL FROM: verification connections |
| VMF_CONNECT_TIMEOUT | Section 2.2.6.10 | Specifies a connect timeout for VMF checks |
| VMF_ERROR_SCORE | Section 2.2.6.3 | Score assigned on a MAIL FROM: verification error |
| VMF_NO_DNS_SCORE | Section 2.2.6.4 | Score assigned for no DNS entry during MAIL FROM: verification |
| VMF_NO_ADDRESS_SCORE | Section 2.2.6.5 | Score assigned for rejection during MAIL FROM: verification |
| VMF_NO_MAILFROM_SCORE | Section 2.2.6.6 | Score assigned for invalid address during MAIL FROM: verification |
| VMF_NO_MX_SCORE | Section 2.2.6.7 | Score assigned for no MX record during MAIL FROM: verification |
| VMF_NO_SMTP_SCORE | Section 2.2.6.8 | Score assigned for no SMTP server during MAIL FROM: verification |
| VMF_OK_SCORE | Section 2.2.6.9 | Score assigned for accepted address during MAIL FROM: verification |
| Dynamic URI filtering keywords | ||
| DYN_URI_PHISH_DOMAIN_SCORE | Section 2.2.7.2 | Score assigned to a known phishing domain |
| DYN_URI_SPAM_DOMAIN_SCORE | Section 2.2.7.3 | Score assigned to a known spam domain |
| DYN_URI_SPAMVERTISED_DOMAIN_SCORE | Section 2.2.7.4 | Score assigned to a domain that appears in spam messages |
| DYN_URI_HONEYPOT_DOMAIN_SCORE | ||