BMX 2.2 User Manual - fortantispam · • Avast!, ClamAV, and F-Prot anti-virus support • "Client-Is-MX" heuristics for PTR and IP in name checks • Concurrent connection limits

2009

USERS GUIDE

Step-by-step instructions for installing , Configuring

and using BarricadeMX

USERS GUIDE

step instructions for installing , Configuring

BarricadeMX version 2.2.

BarricadeMX Users Guide

Includes installation, operation and troubleshooting information

© Fort Systems Ltd. All Rights Reserved

Under the copyright law, this manual may not be copied, in whole or in part without the

written consent of Fort Systems Ltd.

The BarricadeMX logo is a pending Trademark of Fort

any purpose without the p

The FSL logo is a pending Trademark of Fort

any purpose without the p

Fort Systems Ltd.

3807 Fulton Street N.W.

Washington, DC 20007

+1-202-595-7760

www.FSL.com

The “BarricadeMX” name and the shield device are

Systems Ltd. and may only be reproduced in whole or in part in any way with the express

written permission of Fort Systems Ltd.

SpamAssassin is a registered Trademark of Deersoft, Inc.

Microsoft is a registered Tradema

countries.

While we have made every effort to assure the accuracy of this manual, we cannot be

responsible for clerical or typesetting errors.


For BarricadeMX 2.x

Systems Ltd. All Rights Reserved and SnertSoft


Systems Ltd. and SnertSoft

a pending Trademark of Fort Systems Ltd. and may not be used for

any purpose without the prior written consent of Fort Systems Ltd.

a pending Trademark of Fort Systems Ltd. and may not be

any purpose without the prior written consent of Fort Systems Ltd.

Systems Ltd.

3807 Fulton Street N.W.

Washington, DC 20007-1345

7760

The “BarricadeMX” name and the shield device are pending registered trademarks of Fort


written permission of Fort Systems Ltd.

SpamAssassin is a registered Trademark of Deersoft, Inc.

Microsoft is a registered Trademark of Microsoft Corporation in the United States and/or


responsible for clerical or typesetting errors.

Page 2 of 73



Systems Ltd. and may not be used for

Systems Ltd. and may not be used for

pending registered trademarks of Fort


rk of Microsoft Corporation in the United States and/or other



Table of Contents

1 ABOUT THIS GUIDE ........................................................................................................................ 5

1.1 WHO SHOULD USE IT ................................................................................................................ 5

1.2 TYPOGRAPHICAL CONVENTIONS ................................................................................................ 6

2 ABOUT THIS SOFTWARE .............................................................................................................. 7

2.1 DESCRIPTION ............................................................................................................................ 7

2.2 OPERATION AND FEATURES ....................................................................................................... 7

2.3 REQUIREMENTS ........................................................................................................................ 8

2.4 CONFIGURATIONS ..................................................................................................................... 9

3 INSTALLATION .............................................................................................................................. 11

3.1 STANDALONE INSTALLATION .................................................................................................... 11

3.1.1 Updating the operating system ..................................................................................... 11

3.1.2 Installing the rpms ......................................................................................................... 12

3.1.3 Starting smtpf ................................................................................................................ 12

3.2 INSTALLING ADDITIONAL SYSTEMS IN A CLUSTER ...................................................................... 13

3.3 DEFENDERMX 1.93 AND SMTPF ............................................................................................... 15

4 INITIAL CONFIGURATION ............................................................................................................ 16

4.1 CONFIGURATION ON CENTOS AND REDHAT EL 3.X AND 4.X ..................................................... 16

4.1.1 Configuration Files ........................................................................................................ 16

4.1.2 Modifying the configuration files .................................................................................... 17

4.1.3 Configuring /etc/smtpf/smtpf.cf ...................................................................................... 17

4.1.4 Configuring /etc/smtpf/route.cf ...................................................................................... 18

4.1.5 Configuring /etc/smtpf/access.cf ................................................................................... 19

4.2 CONFIGURATION ON CENTOS AND RED HAT 5.X ...................................................................... 27

4.2.1 Starting the Web Interface ............................................................................................ 27

4.2.2 Using the Web interface ................................................................................................ 29

4.2.3 Configuration Tab .......................................................................................................... 30

BarricadeMX Users Guide Page 4 of 73

4.2.4 The Routing and Relay Tab .......................................................................................... 38

4.2.5 The Route Stats Tab ..................................................................................................... 41

4.2.6 The Access Controls Tab .............................................................................................. 42

4.2.7 The Cache Tab .............................................................................................................. 51

4.2.8 The Search Logs Tab .................................................................................................... 53

4.2.9 The Users Tab ............................................................................................................... 53

4.2.10 The Licensing Tab ......................................................................................................... 54

5 ADMINISTRATIVE TOOLS AND OPTIONS .................................................................................. 55

5.1 COMMAND LINE OPTIONS ........................................................................................................ 55

5.2 RUNTIME CONFIGURATION ....................................................................................................... 55

5.3 STATISTICS ............................................................................................................................. 57

APPENDIX A: BARRICADEMX/SMTPF RECOMMENDED SETTINGS ........................................... 58

APPENDIX B: SMTPF 2.2 RELEASE NOTES ................................................................................... 71


1 About this guide

This document is divided into the following chapters:

• Chapter 1, “ABOUT THIS GUIDE”.

• Chapter 2, “ABOUT THIS SOFTWARE” gives an overview of the key features of smtpf and

BarricadeMX.

• Chapter 3, “INSTALLATION”, explains how to get started by installing the software.

• Chapter 4, “INITIAL CONFIGURATION”, describes configuring smtpf using the text files in

/etc/smtpf (CentOS / Red Hat 3.x or 4.x) and the BarricadeMX web interface (CentOS /

Red Hat 5.x)

• Chapter 5, “ADMINISTRATIVE TOOLS AND OPTIONS”, describes additional advanced

administrative tools

• Appendix A: BarricadeMX/smtpf Recommended Settings

1.1 Who Should Use It

• System / E-mail Administrators: This guide is intended for system administrators with at least

some degree of knowledge and experience with the Linux operating system

Installation help and support for configuration is available by sending a request to

[email protected]


1.2 Typographical Conventions

This document uses the following typographical conventions:

• Command and option names appear in bold type in definitions and examples. The names of

directories, files, machines, partitions, and volumes also appear in bold.

cd /etc/smtpf

• Variable information appears in italic type. This includes user-supplied information on

command lines.

cd /home/username

• Screen output and code samples appear in monospace type.

ls /tmp

-rw-r--r-- 1 root root 2660 Dec 17 06:10

DMX_DEMO.tar.gz

drwx------ 3 steve steve 4096 Dec 11 11:11 gconfd-steve

drwx------ 2 steve steve 4096 Nov 18 12:16 keyring-0k1wUz

In addition, the following symbols appear in command syntax definitions.

• Square brackets [ ] surround optional items.

• Angle brackets < > surround user-supplied values.

• Percentage sign % represents the regular command shell prompt.

• Pipe symbol | separates mutually exclusive values for an argument.

ifconfig interface [aftype] options | address ...

• IMPORTANT NOTES will be formatted in this Format:

IMPORTANT!

Essential instructions


2 About this Software

2.1 Description

BarricadeMX provides complete anti-spam protection. Typically it is installed as two

RPM packages, smtpf (simple mail transfer proxy) and BarricadeMX.

The smtpf RPM provides the smtpf binary application which typically listens on the SMTP

port 25 and acts as a proxy, filtering and forwarding mail to one or more MTAs, which

can be on the same machine or different machines.

BarricadeMX is a separate RPM which provides a web interface for maintaining the text

files used to configure smtpf and also provides access to smtpf statistics and mail log

entries.

2.2 Operation and Features


smtpf sits in front of one or more MTAs on SMTP port 25. It acts as a proxy, filtering and

forwarding mail to one or more MTAs, which can be on the same machine or different

machines.

By using an independent SMTP pre-filter in the form of a proxy we avoid portability

differences and limitations of MTA extension methods (milters, plug-ins, rule sets, etc.)

and tightly couple & integrate tests to improve performance & message throughput.

smtpf supports a variety of well blended anti-spam filtering techniques that can be

individually enabled or disabled according to the rigors of the postmaster's local filtering

policy. Some of the tests available are:

• Avast!, ClamAV, and F-Prot anti-virus support

• "Client-Is-MX" heuristics for PTR and IP in name checks

• Concurrent connection limits

• Connection rate throttling

• DNS real-time black, grey, and white lists

• Enhanced grey-listing

• HELO claims to be us

• Local black/white list by IP, host name, domain, MAIL, RCPT

• Message limit & size controls

• Recipient verification using call-ahead

• Sender verification using call-back

• SIQ protocol support for reputation services

• SMTP command & greet pause

• SpamAssassin anti-spam support

• SPF Classic support

• Tar pitting negative SMTP responses

• URI blacklist test of PTR, HELO, and MAIL

• URI blacklist testing of message con-tent

• White wash & backscatter prevention with EMEW (Enhanced Message-ID as Email Watermark)

Another feature of smtpf is the multicast / unicast cache, which provides a fast, simple,

and efficient means to share cache updates across multiple machines on the same

network segment or to a set of remote hosts. The multicast / unicast cache use a

broadcast-and-correct model and support IPv4 & IPv6.

2.3 Requirements

Hardware (minimum):

• 1 GHz 32-bit (x86) or 64-bit (x64) processor

• 1 GB of system memory

• 20 GB hard drive with at least 15 GB of available space


• Internet access

Operating Systems for smtpf (smtpf application with text configuration files):

• Red Hat Enterprise Linux versions 3.x, 4.x and 5.x

• CentOS Linux, versions 3.x, 4.x and 5.x

Operating Systems for BarricadeMX / smtpf (smtpf application with web interface):

• Red Hat Enterprise Linux version 5.x

• CentOS Linux, version 5.x

2.4 Configurations

In its simplest configuration, smtpf runs on the same system that acts as an email

gateway and mail hub. This is a very normal configuration since smtpf will substantially

reduce the load on the existing mail hub by rejecting most of the spam before it is

accepted for delivery:

In a much more complex, large scale configuration, smtpf runs on multiple clustered

gateways which share centralized configuration data and cache data. Routing email to

different gateways or mail hubs can be based on email address or destination domain.

The shared cache allows for the multiple gateways to share a consistent view of grey-

listing and EMEW data. Additionally, BarricadeMX web access, centralized

configuration files and centralized email logging can be off-loaded to a separate

server.



3 Installation

First verify that your hardware and operating system can support smtpf or smtpf and

BarricadeMX. Please see Section 2.3 requirements.

Next determine whether you will be installing a standalone systems or clustered email

gateways.

And finally you will need the following information for each domain that you will be

processing email for.

3.1 Standalone Installation

If you are installing a standalone systems or clustered email gateways, this section will

explain how to install a standalone system or the first system in a cluster. After installing

the first system in a cluster, please follow the instructions in Section 3.2 Installing

Additional Systems in a Cluster.

Before you begin, you will need to have:

1. (For CentOS Systems)The file fsl.repo to allow your system to access the FSL yum

repositories.

2. (For Red Hat Systems) The RPM files you intend to install

3. A Permanent or Demo license file (lickey.txt).

If you do not have these Items please contact [email protected] .

3.1.1 Updating the operating system

Before starting the installation you should make sure that your Operating System is fully

up to date. Note that commands listed below should be run on the new BarricadeMX /

smtpf gateway as user root.

For CentOS systems you will need to login to the system and run:

yum –y update

For Red Hat systems you will need to have a current subscription to the Red Hat update

system before you can update your system. Once you have registered your subscription

please follow the Red Hat instructions for updating your version of the operating system.


3.1.2 Installing the rpms

For all CentOS and RedHat EL 5.x systems: first login to the system and make sure

that the fsl.repo file supplied to you by FSL is installed as:

/etc/yum.repo.d/fsl.repo

For all CentOS 3.x or 4.x systems: You may only install the smtpf rpm. The

BarricadeMX web interface is not supported on these operating systems. To install the

smtpf operations system login to the system and run the command:

yum –y install smtpf

For a RedHat EL 3.x or 4.x systems: You may only install the smtpf rpm. The

BarricadeMX web interface is not supported on these operating systems. To install the

smtpf operations system download the smtpf rpm file using the instructions provided to

you by FSL.. Then change directory to the same directory where you downloaded the

rpm and run:

rpm –ivh smtpf*

CentOS 5.x and RedHat EL 5.x systems: The BarricadeMX web interface is supported

on CentOS 5.x and Red Hat 5.x systems. To install the smtpf and BarricadeMX rpms

login to the system and then run:

yum –y install smtpf BarricadeMX

3.1.3 Starting smtpf

Before continuing, please install the permanent or demo license key file, lickey.txt or it’s

its contents as:

/etc/smtpf/lickey.txt

Before starting smtpf you will need to configure the local Mail Transport Agent ( MTA) to

listen on and alternate port. Typically this will be port 26. Directions for configuring

sendmail, Postfix, Exchange MDaemon, Qmail and Exim may be found at:

www.no-ip.com .

Restart your MTA after reconfiguring.

Next configure smtpf to start on system boot. Login to the system and run:

chkconfig smtpf on


Then start smtpf. Run:

service smtpf start

At this point you should be able to telnet to port 25 and connect to the smtpf process.

Run:

telnet localhost 25

You should see a response similar to:

Trying 127.0.0.1...

Connected to localhost.localdomain (127.0.0.1).

Escape character is '^]'.

220 bmx.domain.net ESMTP #632 (kBH9FS192755070400)

Enter quit to exit telnet.

And you should be able to telnet to port 26 and connect to the MTA process. Run:

telnet localhost 26

You should see a response similar to:

Trying 127.0.0.1...



220 sendmail.domain.net ESMTP Sendmail 8.13.8/8.13.7; Thu, 18 Dec 2008 09:18:00 -0500

Enter quit to exit telnet . Trying 127.0.0.1...



220 sendmail.domain.net ESMTP Sendmail 8.13.8/8.13.7; Thu, 18 Dec 2008 09:18:00 -0500

If this is the only gateway you are installing please skip to section 4 Configuring smtpf.

3.2 Installing Additional Systems in a Cluster

You will need to make additional changes to the system you have just installed if it is to

be the first (or master) system in a clustered gateway installation. The master system will

need to be able to runs commands using ssh on the slave systems. There are two

methods of configuring this access.

Authorized keys: On the master server as user root run:


ssh-keygen –t dsa

In the following dialogue press “Enter” twice

Generating public/private dsa key pair.

Enter file in which to save the key (/root/.ssh/id_dsa):

Enter passphrase (empty for no passphrase): <Enter>

Enter same passphrase again: <Enter>

Your identification has been saved in /root/.ssh/id_dsa.

Your public key has been saved in /root/.ssh/id_dsa.pub.

The key fingerprint is:

ad:19:d9:11:a2:2e:ad:60:e3:b0:ac:4d:66:3e:57:10

Once the ssh keys have been generated simply copy the contents of

/root/.ssh/id_dsa.pub to /root/.ssh/authorized_keys on each of the

slave smtpf servers in the cluster.

An alternate method is to install keychains. To install keychains please follow the

instructions found at: http://www.gentoo.org/proj/en/keychain/. Please note that when

using this method with an ssh passphrase, the passphrase must be manually entered

after each reboot of the master smtpf gateway.

The next step is to install two additional files in /etc//smtpf to automatically synchronize

changes to the access.cf and route.cf files to the slave servers. Run

cp /usr/share/examples/smtpf/sync.sh /etc/smtpf/

And create the file /etc/smtpf/serverlist. This file is simply a text file list of the

hostnames or IP addresses of the slave servers, one per line.

The setup of the master smtpf gateway should now be complete. To add the slave

servers simply setup each slave as described in Section 3.1. After installing the software

on the slave you only need to:

1. Copy the contents of /root/.ssh/id_dsa.pub from the master to

/root/.ssh/authorized_keys f the slave smtpf server.

2. Copy the file /etc/smtpf/smtpf.cf from the master to /etc/smtpf/ on

the slave.


IMPORTANT!

After making any changes to /etc/smtpf.cf on the master gateway, the smtpf process

must be restarted for any changes to take effect. The smtpf.cf file must also be

copied to all of the slave gateways and the smtpf process must be restarted on each

of the slaves after the copy.

3.3 DefenderMX 1.93 and smtpf

DefenderMX may be installed on a Gateway that is running FSL anti-spam software

DefenderMX version 1.93. The Installation of BarricadeMX on the DefenderMX system

will typically be performed by the FSL Support team. Please see Section below for

instructions on configuring and running BarricadeMX on a DefenderMX gateway.


4 Initial Configuration

4.1 Configuration on CentOS and RedHat EL 3.x and 4.x

This section will explain how to initially setup BarricadeMX installed on CentOS and

RHEL 4.0 Systems including those running DefenderMX.

4.1.1 Configuration Files

Three files control the operation, options and configuration of BarricadeMX. These files

are:

/etc/smtpf/smtpf.cf: This file controls the options and behavior of BarricadeMX.

/etc/smtpf/route.cf: this file controls the routing of email and which hosts or sites

are allowed to relay

/etc/smtpf/access.cf: This file controls:

• Concurrency Controls, defaults and exceptions

• Greylist Controls: defaults and exceptions

• Message Length Controls: defaults and exceptions

• Message Limit Controls; defaults and exceptions

• Client Connection Rate Control: defaults and exceptions

• SMTP Greet Pause: defaults and exceptions

• URI Whitelist/Blacklist: defaults and exceptions

• SMTP Command Pause: defaults and exceptions

• White and Black listing

Important for DefenderMX Systems!

Please note that when BarricadeMX is installed with DefenderMX, the route.cf file and the

access.cf file are automatically generated from data stored in DefenderMX. These files are

normally rebuilt every 5 minutes by the /etc/cron.d/bmx_connector.cron job.


4.1.2 Modifying the configuration files

Whenever either access.cf or route.cf are modified – to apply the changes the following

command must be run:

make –C /etc/smtpf

This will build the SQLite database files and the changes will be applied immediately. If

you have multiple BarricadeMX servers configured, then edits should only be made on

the Master server and when the command above is run the configuration will be copied

and built on the slave servers automatically.

Note: changes to smtpf.cf are not copied to slave servers automatically, these must be

copied manually as necessary.


Please note that when BarricadeMX is installed with DefenderMX, it is not necessary

to manually run the `make` commence to rebuild the SQLite database. You may only

want to run the `make` command if the access.cf file is modified by hand (see

below).

4.1.3 Configuring /etc/smtpf/smtpf.cf

The default smtpf.cf file, as installed, will be a good starting point for most sites. However

if you are installing a BarricadeMX cluster of gateways you will need to configure the

cache-multicast-ip=, cache-unicast-hosts= = and cache-secret=

options which must be set.

Shared Cache is used when you have multiple BarricadeMX gateways running and it

allows these gateways to share their cache information (this is essential when greylisting

is used or connection rate / limit controls used).

A value for cache-secret= must be supplied and must be identical on each system

sharing a cache. The value may be any text string. The value must be enclosed in

double quotes if it contains white spaces.

Two methods may be used for the shared cache, multicast or unicast. Multicasting can

be used when the machines are on the same physical subnet and is the most efficient

method of cache sharing. It is enabled whenever the cache-multicast-ip option is

set to a multicast address, typically 239.0.0.1.


The unicast cache can be used whenever the multicast cache is not suitable and is

enabled by supplying a space or comma separated list of host names and/or IP

addresses with optional colon separated port numbers.

Important!

When making changes to the access.cf or route.cf files on a group of Clustered

BarricadeMX servers, the changes should be made on the master server.

Please do not change any other default options until you have read and understand

Appendix A, BarricadeMX/smtpf Recommended Settings or the detailed documentation

available http://www.snertsoft.com/smtp/smtpf/

4.1.4 Configuring /etc/smtpf/route.cf

All sites will need to modify the default route.cf file to correctly deliver and relay email for

their domains.

To deliver the mail from the local MTA running on the gateway, the following entry MUST

exist in the route.cf file:

route:127.0.0.1 FORWARD: 127.0.0.1:26; RELAY

To route email for example.net to mail.somewhere.net to the localhost for processing by

a local MTA , e.g. MailScanner (listening on port 26), but verify recipient is valid at

mail.elsewhere.net before accepting the message and to allow relaying from any

machine with rDNS in the somewhere.net domain, add the following line to the route.cf

file (note the following example should be entered as a single line of text):

route:somewhere.net FORWARD: 127.0.0.1:26;

RCPT:mail.somewhere.net; RELAY

To route email for abc.com directly to mailhub.abc.com after verifying the recipient is

valid at mailhub.abc.com and to allow relaying from abc.com , add the following line to

the route.cf file (note the following example should be entered as a single line of text):

route:abc.com FORWARD: mailhub.abc.com;

RCPT:mail.somewhere.net; RELAY

To allow relaying from the host 10.1.1.10, add the following line to the route.cf file:

route:10.1.1.10 RELAY

To allow relaying from the 192.168.1 subnet, add the following line to the route.cf file:

route:192.168.1 RELAY


To allow relaying from any host with rDNS in the fsl.com domain, add the following line to

the route.cf file:

route:fsl.com RELAY

Please note that using IP addresses rather than domain names when specifying relays is

preferred and safer. When using domain names BarricadeMX will only allow relay from

hosts with rDNS that can be verified (e.g. IP: 1.2.3.4 -> rDNS: host.domain.com -> DNS:

1.2.3.4) as not being forged.

Important!

When making changes to the route.cf file on a group of Clustered BarricadeMX

servers, the changes should be made on the master server.

After Making changes to the route.cf file on a master BarricadeMX server or a

standalone BarricadeMX server, you must run the command:

make –C /etc/smtpf

to implement the changes. On a standalone server, this updates the SQLite

databases used by smtpf. On a group of clustered gateways, this updates and

synchronizes the SQLite databases across all of the clustered servers


There is no need to modify the route.cf file on a system running DefenderMX as it is

automatically generated. In fact any changes made to the route.cf file will be overwritten

the next time the bmx_connector.php script is run from cron.

4.1.5 Configuring /etc/smtpf/access.cf

All sites will need to review the default access.cf file to ensure mail is correctly received

for their domains.


Please note that when BarricadeMX is installed with DefenderMX, it is not normally

necessary to modify the access.cf file bay hand to add white list entries. White list entries

are automatically synchronized with the data in DefenderMX. You will see these entries

in the access.cf file between the lines:

### BEGIN CONNECTOR

and


### END CONNECTOR

However this file may be edited manually to change other configuration values. If the file

is manually edited, you may run the make- C /etc/smtp command to rebuild the SQLite

database immediately or wait until the next automatic rebuild which will occur in less than

15 minutes.

The access.cf text file consists of lines of key-value pairs. Each line consists of a key

field separated by white space from the value field, which is the remainder of the line.

Comments start with a hash (#) on a line by themselves. The key lookups are case

insensitive, while the values are case sensitive. The order in which keys are looked up is

outlined by the access-map option.

There are essentially three types of keys used in the access-map. Many of the tags

available will use one or more of these lookup sequences.

Key Values: IP Address Lookups

An IP address lookup is typically applied to the connected SMTP client. It will

start with a complete IPv4 or IPv6 address and break it down on delimiter

boundaries from right to left.

IPv4 Lookup IPv6 Lookup

tag:192.0.2.9 tag:2001:0DB8:0:0:0:0:1234:5678

tag:192.0.2 tag:2001:0DB8:0:0:0:0:1234

tag:192.0 tag:2001:0DB8:0:0:0:0

tag:192 tag:2001:0DB8:0:0:0

tag:2001:0DB8:0:0

tag:2001:0DB8:0

tag:2001:0DB8

tag:2001

Note that the compact form of an IPv6 address, "2001:0DB8::1234:5678",

cannot be used. Only the full IPv6 address format, with all intervening zeros, is

currently supported.


Key Values: Domain Name Lookups

A domain lookup may be applied to either the connected SMTP client, where

the client's host name found through a DNS PTR record is searched for, or

using the domain portion of an mail address (see below). A domain lookup will

try the IP-domain literal if applicable, then continue with the FQDN, breaking it

down one label at a time from left to right.

tag:[ipv6:2001:0DB8::1234:5678]

tag:[192.0.2.9]

tag:sub.domain.tld

tag:domain.tld

tag:tld

tag:

Note that the bare tag is often used to specify system wide defaults.

Key Values: Mail Address Lookups

A mail address lookup is similar to a domain lookup, but the search first starts

with a complete mail address, before trying the address's domain, and finally

only the local part of the address.

tag:[email protected]

tag:sub.domain.tld

tag:domain.tld

tag:tld

tag:account@

tag:

Note that the bare tag is often used to specify system wide defaults.

Key Values: Supported Values for the Network Control Actions include:


OK white list, by-pass one or more tests

CONTENT white list as far as, but not including, the content filters; used only

with Connect:

DISCARD accept & discard message

NEXT resume lookup, opposite of SKIP

SKIP stop lookup & return no result

SPF-PASS white list sender if SPF returns Pass; used only with

Connect:From: and From:

TEMPFAIL report a temporary failure condition

REJECT black list, either reject or drop

IREJECT immediate REJECT, ignore smtp-delay-checks;

SAVE save a copy of message, if delivered, for debugging or archiving

TRAP accepts and save message to a trap-dir, but do not deliver;

intended for spam trapping and learning

TAG Instead of rejecting a message for policy reasons, simply tag the

subject header, add a X-Spam-Reason: header and by-pass the

remaining tests.

Important!

Please note that case is important for key values – the action words must be upper-

case.

In most instances, the above forms of key lookup and action are sufficient. However,

there may be times when finer granularity of control is required; in which case pattern

lists can be used. A pattern list is a white space separated list of pattern-action pairs

followed by an optional default action. Appendix A, BarricadeMX/smtpf Recommended

Settings or the detailed documentation available http://www.snertsoft.com/smtp/smtpf/

http://www.snertsoft.com/smtp/smtpf/access-map.html

for directions on how to use Pattern Matching


Site Defaults:

The access.cf file distributed with BarricadeMX contains sensible default values for most

sites but the values should be examined and understood before putting the system into

production.

Important!

Please note that case is not important in tags and keys :

connect: is the same as CONNECT: is the same as Connect:

However action values are case-sensitive and must be upper-case e.g. OK, TAG,

REJECT etc.

Concurrency Control Tags:

Concurrent-Connect:ip

Concurrent-Connect:domain

This is used to specify the maximum number of concurrent connections an SMTP

client is permitted at any one time. Specify an integer or zero (0) to disable. The bare

tag can be used to specify a global setting. If an SMTP client exceeds the allotted

number of connections, then the incoming connection is dropped, while existing

connections continue.

Examples:

This limits the default to 5 concurrent connections for any sending site:

concurrent-connect: 5

This limits any host with a PTR record ending in ‘yahoo.com’ to 10 concurrent

connections

concurrent-connect:yahoo.com 10

This limits goodguys.com to unlimited concurrent connections

concurrent-connect: goodguys.com 0

Message Length Controls:


Length-Connect:ip

Length-Connect:domain

Length-From:mail

Length-To:mail

Used to limit the maximum length of a message in octets. It is expressed as a

number with an optional scale suffix K (kilo), M (mega), or G (giga). If no length is

given or is -1, then the message can be any length.

When there are multiple message length limits possible, then the limit applied, in

order of precedence is:

a. Length-To:. If there is more than one Length-To:, then the maximum limit specified will

be used.

b. Length-From:

c. Length-Connect:

Examples:

This specifies that the default maximum message size of 24 Megabytes.

Length-Connect: 24M

This specifies that the maximum message size to domain 'example.com' is 1

Megabyte.

Length-To:example.com 1M

Message Limit Controls:

Msg-Limit-Connect:ip

Msg-Limit-Connect:domain

Msg-Limit-From:mail

Msg-Limit-To:mail

Used to limit the number of messages a SMTP client, sender, or recipient can

send/receive in a given time period. A message limit is given as:

messages '/' time [unit]

which is the number of messages per time interval. The time unit specifier can be one of

week, day, hour, minute, or seconds (note only the first letter is significant). A negative

number for messages will disable any limit.


When there are multiple message limits possible, then the limit applied, in order of

precedence is: Msg-Limit-To:, Msg-Limit-From:, and Msg-Limit-Connect.

Examples:

Allow 50 messages per hour by default.

Msg-Limit-Connect: 50/1h

Allow a maximum of 1000 messages per day to domain 'example.com'.

Msg-Limit-To:example.com 1000/1d

Client Connection Rate Control:

Rate-Connect:ip

Rate-Connect:domain

This is used to specify the number of connections per minute a host is allowed.

Simply specify an integer or zero (0) to disable. The bare tag can be used to specify

a global setting. If an SMTP client connects too frequently in excess of this limit, then

the incoming connection is dropped.

Examples:

Allow 5 connections per host per minute.

Rate-Connect: 5

Allow any host in the 'example.com' domain an unlimited number of connections.

Rate-Connect:example.com 0

URI Whitelist/Blacklist:

Body:domain

Used to black (REJECT) or ignore (OK) domains that make up mail addresses or URLs

found within the header or body content of a message. See uri-bl and uri-dns-bl.

Examples:

Black list the message if domain bad.domain.com is found within a message.

Body:bad.domain.com REJECT

White list the domain 'example.com' so that it will never be rejected by a URI blacklist.

Body:example.com OK

White and Black listingTags


Tag Connect:ip

Tag Connect:domain

Used to black or white list an SMTP client. If black listed (REJECT), the connection will

be dropped. If white listed (OK), then the messages from this connection by-passes all

the filtering except anti-virus.

Examples:

Blacklist all mail from spammer.com.

Connect:spammer.com REJECT

White list all mail from microsoft.com.

Connect:Microsoft.com OK

Tag From:mail

Used to black or white list a sender's mail address. If black listed (REJECT), mail from

this sender is refused. If white listed (OK), then the messages from this sender will by-

pass all the filtering except anti-virus. Black listing using this tag is fine, but white listing

is not recommended as it is too easy for someone to fake the sender address.

Examples:

Blacklist all mail from [email protected].

From:[email protected] REJECT

White list all mail from microsoft.com.

From:[email protected] OK

Tag To:mail


Used to black or white list a recipient's mail address. If black listed (REJECT), mail to

this recipient will be refused; the current message transaction is permitted to specify

additional recipients or abandon the transaction. If white listed (OK), then the

message will by-pass all the filtering except anti-virus.

Examples:

Blacklist all mail to [email protected].

To:[email protected] REJECT

White list all mail to [email protected].

To:[email protected] OK

Tag From:To

Used to match a specific From and To Pair. If black listed (REJECT), mail To the

matching Tag and From the matching Tag will be refused; the current message

transaction is permitted to specify additional recipients or abandon the transaction. If

white listed (OK), then the message will by-passes all the filtering except anti-virus.

Examples:

Blacklist all mail to [email protected] and from [email protected]

To: [email protected]:From:[email protected] REJECT

Whitelist all mail to [email protected] and from [email protected]

To: [email protected]:From:[email protected] OK

4.2 Configuration on CentOS and Red Hat 5.x

While configuration of BarricadeMX on CentOS and Red Hat 5.x systems is usually

accomplished by using the BarricadeMX web interface, it should be noted that all of the

text file configuration options described in Section 4.1 can also be used on CentOS and

Red Hat 5.x systems.

4.2.1 Starting the Web Interface

After installation of the packages, the web interface can be accessed from any system

that has a web browser that can connect to the IP address or hostname of the

BarricadeMX server. Go to

http://<server name or IP>/barricademx/

And you will be prompted to create an initial user:


Once you have added the user, click the ‘Licensing’ tab and you w

in. Use the username and

After successfully logging in you will be presented with the Licensing page. Click

'Browse' and navigate to the license file that you will have been sent separately, this file

will be called 'lickey.txt' and its name must not be modified

refuse to load it.

Click 'Upload' and the license key file will be uploaded to the server and the license will

be shown once it has successfully loaded.

Once you have added the user, click the ‘Licensing’ tab and you will be prompted to log

in. Use the username and password that you just created



will be called 'lickey.txt' and its name must not be modified or the web interf


be shown once it has successfully loaded.

Page 28 of 73

ill be prompted to log-



the web interface will



After you have loaded the license, you are ready to configure the system. Click the

'Domains & Relays' and refer to the 'Domains & Relays' section below for further

information on configuring the system.

4.2.2 Using the Web interface

After you login, you are presented with the contents of the Statistics Tab. This page

shows the current statistics for the BarricadeMX system that you have just logged into:


This page is entirely informative except for the Stop | Restart (or if BarricadeMX has

been stopped, the Start | Restart) links at the top left of the screen.

The functions provided by the other Tabs at the top of the page include:

Configuration: Provides access to the smtpf.cf settings that control which tests and

features BarricadeMX will use.

Routing and Relay: Used to setup domains for which the system will receive email, how

to forward email received for those domains, how to determine valid recipients for each

domain and which systems should be allowed to relay mail out through the system.

Route Stats: For information only. Shows by-domain statistics for messages processed.

Access Controls: Controls how each connecting system will be treated. Allows for

complete control of each connection by Connecting IP or hostname, Sender or Recipient

parameters.

Cache: Allows searching, viewing and deletion of current cache entries.

Search Logs: Allows searching of Mail Logs.

Users: Add, Delete or Modify users who can access the web interface.

Licensing: Load a new license or review license details.

Important for Clustered Servers!

Each server in a cluster maintains its own statistics. You must collect cluster statistics by

querying the SQLite databases on each server in the cluster. Please contact

[email protected] for specific setup instructions.

4.2.3 Configuration Tab

The configuration page lists all the frequently modified options listed by category. If any

of the key options in a category are disabled or not configured, then the options within

the category are not shown. To expand or hide a section then tick or untick the box next

to the heading name.

Each option is listed within the category and a traffic-light color scheme is used to

attribute a 'risk' factor to some options as to how likely it is to accidentally reject a

legitimate mail. Option names that are underlined can be left clicked to show or hide the

help for each option.


In the figure above, using dns-bl has a medium risk of false positives while using dns-gl

or dns-wl has a low risk of false positives.

The Load Defaults drop down can be used to load our recommended defaults for each

of the different risk levels..

4.2.3.1 For Clustered Gateways

The default smtpf.cf file, as installed, will be a good starting point for most sites. However

if you are installing a BarricadeMX cluster of gateways you will need to configure the

cache multicast ip, cache unicast hosts and cache secret options

which must be set to allow the synchronization of the Shared Cache between systems.

The Shared Cache is used when you have multiple BarricadeMX gateways running and

it allows these gateways to share their cache information (this is essential when

greylisting is used or connection rate / limit controls used).

A value for cache secret must be supplied and must be identical on each system

sharing a cache. The value may be any text string. The value must be enclosed in

double quotes if it contains white spaces.

Two methods may be used for the shared cache, multicast or unicast. Multicasting can

be used when the machines are on the same physical subnet and is the most efficient


method of cache sharing. It is enabled whenever the cache multicast ip option is

set to a multicast address, typically 239.0.0.1.

The unicast cache can be used whenever the multicast cache is not suitable and is

enabled by supplying a space or comma separated list of host names and/or IP

addresses with optional colon separated port numbers.

Important!

When making changes to Configuration on a group of Clustered BarricadeMX servers,

the changes should be made on the master server. After making any Configuration

changes, the /etc/smtpf/smtpf.cf file should be copied to the other servers in the cluster

and the smtpf service needs to be restarted on each of the servers in the cluster.

Please do not change any other default options until you have read and understood

Appendix A, BarricadeMX/smtpf Recommended Settings or the detailed documentation


4.2.3.2 Setting Specific Configuration Options

Additional information for each option can be found in Appendix A, BarricadeMX/smtpf

Recommended Settings or at http://www.snertsoft.com/smtp/smtpf/. Only the most

important and commonly changed configuration options are described below.

Sender Verification

When call back is enabled then BarricadeMX will contact one of the sender's MX

servers to validate if their server and mail address is known and in good standing and

the message will be rejected if not. This test is intentionally run after all other pre-DATA

tests have run to reduce the number of call and all results from this test are cached to

prevent multiple lookups to the same host however temporary failures are typically

cached for a shorter period.

If call back pass grey is enabled and a call back succeeds then grey-listing will be

skipped to avoid any delays. With the enhanced grey-listing as implemented in

BarricadeMX, this is not recommended, since spam can trivially forge the sender with a

valid mail address expressly for this purpose passing the call-back and grey-listing.


Important!

Call-backs are a very unpopular technique with many mail administrators. They are seen

to consume their system resources and as an abuse vector for anonymous proxy

dictionary attacks used in harvesting mail addresses or a distributed denial-of-service.

As a result, some services may choose to locally black list servers that they think are

performing call-backs.

Clam Anti-Virus

If ClamAV is configured either locally on the same machine as BarricadeMX or set-up on

a separate server then clamd socket can be set to either a local path to a socket e.g.

/var/run/clamd.sock or to a host:port of a separate server running the

'clamd' process or ‘SCAN’ which allows local scanning by file path and allows for an

efficiency gain. With any of these set, all mail passing through BarricadeMX will be

scanned for viruses and rejected accordingly.

DNS Lists

BarricadeMX supports multiple DNS lists for black or white listing purposes and each of

the three available options takes a comma or whitespace separated list of DNS suffixes

to consult.

The dns bl option is used to supply a list of black lists that will cause the connection to

be rejected if the connecting client's IP is listed on one of them. An example for this

option would be 'zen.spamhaus.org,bl.spamcop.net'.

The dns gl option is used to supply a list of white lists that will cause the connection to

be white listed through all pre-DATA tests performed by BarricadeMX is the connection

client's IP is listed and is used for lists that you do not trust 100% so that content filtering

(e.g. SpamAsssassin) is still carried out if it is enabled. An example setting for this

option would be 'list.dnswl.org'.

The dns wl option is identical to the dns gl option except that the connection is exempt

from all tests except Virus Scanning, this would typically be used for DNS white lists that

you run internally within your company.

The DNS lists are run in the following order dnl wl, dns gl then dns bl.


E-Mail Watermarking

This function uses a unique feature called EMEW (Enhanced Message ID as Electronic

Watermark) to provide a means to eliminate back-scatter that is caused when a

spammer or virus impersonates a mail address which causes some poorly set-up foreign

systems to bounce the messages back to the faked sender, it also allows for the

automatic white listing of replies to messages that have been relayed through

BarricadeMX. This function works without the use of a database and simply modifies the

existing Message-ID header to add a secret hash to the front.

As a message is processed by BarricadeMX, it checks for a matching hash within the

References or In-Reply-To headers. If the message is from the null-sender and the hash

does not match then the message is rejected otherwise if the hash matches then the

message is automatically white listed.

This feature is enabled by supplying an emew secret which is used to generate the

hashes and the auto white listing feature described above is automatically enabled. If

multiple BarricadeMX systems are in use, then this secret must be the same across each

system.

Important

To enable the rejection of back-scatter, the emew dsn policy must be set to reject

and you must ensure that all outbound mail for each domain handled by BarricadeMX

must traverse a BarricadeMX system otherwise bounce messages generated by

outbound mail sent from other systems will be rejected as they will not contain the

correct hashes. This option should not be switched on at the same time as enabling the

E-Mail Watermarking feature as mail that has been sent can be queued for up to 5 days

before it is returned as undeliverable by a remote system, and these messages would be

incorrectly rejected. It is therefore recommended that this option be enabled at a

minimum of 5 days after enabling the E-Mail Watermarking feature.

EMEW can be enabled on a per-domain basis by configuring an emew secret using the

‘EMEW Secrets’ section of the ‘Access Controls’ tab.

Greylisting

This works by keeping a record of key information to do with the mail transaction and

temporarily rejection any messages from hosts that have never been seen before. This

test is used to prove that the sending system correctly implements a retry-queue which

many spammers and bulk-mailers do not.


The implementation of grey listing in BarricadeMX is unique and was designed to

remove a lot of the problems associated with traditional grey listing methods.

To enable grey listing and use the enhancements set grey key to ptr,mail,rcpt

and set grey temp fail period to the number of seconds that grey listing should be

enforced for. The recommended period for grey listing is 900 seconds (15 minutes), this

is to allow for any DNS black lists in use to be refreshed with new data during the grey

listing period to allow for maximum efficiency.

HELO checks

Enabling helo claims us rejects any connections which send a HELO that contains one

of the domains in the route-map and the connecting system is not defined as a relay.

helo ip mismatch rejects any connections which send a HELO containing an IP address

that does not match the actual IP address of the connecting system.

rfc2821 strict helo enforces the rule that a HELO argument should be a fully-qualified

domain or hostname (e.g. HELO host.domain.com) or an IP-domain literal (e.g. HELO

[1.2.3.4]) and rejects the connection if not.

SpamAssassin

BarricadeMX can be configured to use SpamAssassin via spamd running locally or on

another server. Specify spamd socket as the local path to the socket (e.g.

/var/run/spamd.sock) or the host:port of a system running spamd. Specify

spamd max size to skip scanning message over a certain size. Messages that are

considered to be spam by spamd will be subject tagged , so it is important to set the

SpamAssassin required_score to a sensible value that reflects this. Scores equal to or

above the spamd score reject value will be rejected.

SPF

This set of options enforces the 'Sender Policy Framework' specification which specifies

which systems may send mail for a domain.

spf helo policy allows for the rejection of a message that is from the null-sender where

the sending server is not authorized to mail for the domain specified by its HELO

argument. This is commonlymis-configured so is not recommended that it be activated.

spf mail policy allows for the rejection of a message that fails the SPF test when set to

fail-reject.


Note: it is not recommended to specify 'softfail-reject' for either of these options as this is

against the specification.

Enabling spf received spf headers adds a header for both HELO and MAIL SPF tests

to the message containing all the relevant test information and status.

URI Blacklisting

URI blacklisting scans the message body of a mail message and extracts any URIs

contained within a message (e.g. http:// https:// mailto:// or bare links such a

www.domain.com).

The uri bl option which takes a comma or space separated list of black lists to check

(e.g. multi.surbl.org,black.uribl.com) and extracts the domain name from

any URIs found within a message and looks them up on each specified list. Any positive

result causes policy specified by the uri bl policy option to be applied (the default being

to reject the message).The uri dns bl option takes a comma or space separated list of

black lists to check (e.g. sbl.spamhaus.org) and takes any URIs found and looks up

the IP address of any hosts or domains found within them. Each IP address found is

tested against the black list and any positive result returned causes the policy specified

by the uri bl policy option to be applied, the default being to reject the message.

The uri bl helo, uri bl mail and uri bl ptr options allow the URI black lists test to be

used as pre-DATA tests instead of having to look through the entire body of each

message and would apply the test to the HELO argument, MAIL FROM argument or the

rDNS name if available.

The uri max limit option specifies the maximum number of different URIs that a

message may contain before being rejected while the uri max test option specifies the

maximum number of URIs that will be tested within a message.

The access control tag Body: can be used to white list a specific URI.

4.2.3.3 SMTP Configuration Options

These options specify various SMTP level options.

auth delay checks delays some tests until after the 'MAIL FROM' stage of the SMTP

transaction to allow clients to authenticate using SMTP AUTH as authenticated

connections are automatically white listed.

client ip in ptr rejects connections where the rDNS of the connecting IP contains all or

part of the connecting IP address. BarricadeMX automatically excludes hosts that are an


MX for the domain they are sending from or when then the connection passes SPF if the

client is mx option is enabled.

client ptr required rejects connections which have no rDNS except when the host is an

MX for the domain they are sending from or when the connection passes SPF if the

client is mx option is enabled.

one rcpt per null rejects messages from the null-sender which have more than one

recipient.

reject unknown tld rejects connections or messages where the connecting rDNS or

'MAIL FROM' argument contain an invalid top-level domain.

require sender mx rejects messages where the domain specified in the 'MAIL FROM'

argument does not have any valid MX records specified.

rfc2606 special domains rejects messages where the HELO argument or 'MAIL FROM'

argument contains a domain as specified by rfc2606 (e.g.

.test,.example,.invalid,.localhost, .example.* and includes .localdomain and .local),

however the .local domain is excluded from rejections to the HELO argument.

rfc2822 7bit headers rejects any message containing headers which contain 8bit

characters.

smtp drop after drops any connection that has generated more than the specified

number of errors.

smtp drop unknown drops any connection that sends unknown commands excluding

commands starting with 'XXX'.

Setting a value for smtp dsn reply allows the specification of a Reply-To address that

will be added to any delivery service notification (bounce) messages.

Setting smtp enable esmtp allows extended SMTP (ESMTP) to be enabled or disabled.

If you do not need extended SMTP functions such as SMTP AUTH then it is

recommended that this option should be disabled as it enables several reliable tests to

be applied. When disabled, the EHLO command arguments are stored and the

command is rejected (as per the RFC). Normal mail servers will then send a HELO

command instead, however in some causes it causes some incorrectly implemented

clients to become out-of-sync and other implementations to send a HELO with a different

argument than was sent with the EHLO that was rejected, both of which cause the

connection to be rejected.


smtp reject delay imposes an exponential delay prior to each error message returned

during the SMTP session.

4.2.3.4 Saving the configuration

Use the save and restart button at the bottom of the page to save configuration changes

and restart the smtpf process.

4.2.4 The Routing and Relay Tab

All sites will need to modify the default route.cf file to correctly deliver and relay email for

their domains.

Five pieces of information will need to be entered for each domain for which the gateway

will accept or forward email:

• Domain or IP address: The domain name to accept email for or the IP address to

allow relaying from. for; (**Incomplete??**)

• Deliver to Host: localhost (127.0.0.1) or the Fully Qualified Domain name or IP

address of a remote mail server or mail hub.

• SMTP Port: The port to connect to on the “Deliver to Host” typically 26 if the

“Deliver to Host” is localhost and typically 25 if the “Deliver to Host” is not the

BarricadeMX gateway.

• Verification Host: the Fully Qualified Domain name or IP address of a remote

mail server or mail hub which smtpf will use to verify that the email address is

valid or to verify clients using SMTP AUTH from this domain. NOTE: This value

should not be set to the same host as the ‘Deliver to Host’.

To deliver the mail from the local MTA running on the gateway, the following entry MUST

exist in the route.cf file:

• route:127.0.0.1 FORWARD: 127.0.0.1:26; RELAY


In the example screen above, The three text boxes at the bottom of the page, from left to

right are for entering the following information:

• Domain or IP address

• Deliver to Host (mail hub) : Port Number

• Verification Host

These are used to Add or search for data in the Routing and Relay configuration. After

specific Routing or Relay information has been found, the Edit | Delete choices at the

end of each entry line may be selected to change or delete the data.

The Y / N check box for Relay? is used to allow relaying from the ‘Deliver to Host”.

Selecting Y enables mail relaying back from the “Deliver to Host” through the gateway

while selecting N denies relaying out through the Gateway for the same host.

Selecting the Add button adds the data entered to the routing configuration.

To Search for specific entries, simply enter the Data to match in the appropriate text box

and select the Search button at the right end of the line.

4.2.4.1 Routing and Relay Examples

To route email received for example.net to mail.somewhere.net to the localhost for

further processing and delivery by the local MTA , e.g. processing by MailScanner (with

sendmail listening on port 26), but verify recipient is valid at mail.elsewhere.net before


accepting the message and to allow relaying from mail.somewhere.net, enter the

following information in the text boxes:

Domain or IP address: somewhere.net

Deliver to Host: 127.0.0.1:26

Verification Host: mail.somewhere.net

Relay?: Y

And then select the Add button.

To route email for abc.com directly to mail to mailhub.abc.com after verifying the

recipient is valid at mailhub.abc.com and to allow relaying from abc.com , enter the

following information in the text boxes:

Domain or IP address: abc.com

Deliver to Host: mailhub.abc.com

Verification Host: mail.somewhere.net

Relay?: Y


To allow relaying from the host 10.1.1.10, enter the following information in the text

boxes:

Domain or IP address: 10.1.1.10

Relay?: Y


To allow relaying from the 192.168.1 subnet, enter the following information in the text

boxes:

Domain or IP address: 192.168.1

Relay?: Y


To allow relaying from any host with rDNS in the fsl.com domain, enter the following

information in the text boxes:

Domain or IP address: fsl.com


Relay?: Y


Please note that using IP addresses rather than domain names when specifying relays is

preferred and safer. When using domain names BarricadeMX will only allow relay from

hosts with rDNS that can be verified (e.g. IP: 1.2.3.4 -> rDNS: host.domain.com -> DNS:

1.2.3.4) as not being forged.

Important – Clustered gateways!

When making changes to the route.cf file on a group of Clustered BarricadeMX

servers, the changes should be made on the master server. This will automatically

update the Routing and Relay information used by the Slave servers.

4.2.5 The Route Stats Tab

The Route Stats tab shows statistics for the gateway that the web browser is connected

to:

Selecting the Show Details button for any Domain in the list will display detailed

connection for that Domain:


Entering a search string in the Text box after Domain or Part : at the top of the screen

will list any configured Domains which mach match all or part of the search string.

Starting with version 2.2 , several advanced options have been added to allow

centralized collection and processing of Statistics for a single or multiple gateways.

Please see appendix B - SMTPF 2.2 RELEASE NOTES, the additional documentation

available at http://www.snertsoft.com/smtp/smtpf/ or by contacting [email protected].

4.2.6 The Access Controls Tab

The Access Control tab is used to manage a variety of options such as black & white

listings, message limits & sizes, concurrency & rate throttling. Many elements can be

specified by IP, subnet, host name, and/or sender & recipient address or domain.


The various possible grouping of Access Controls are accessed by first selecting a group

from the Network Controls sub-menu. The possible selections are:

• Network Access: connect, to, from, connect:from, connect:to, from:to,

• Client Connection Rate & Concurrency Control : rate-connect , concurrent-

connect

• Greylist Controls: grey-connect, grey-to

• Message Length Controls: length-connect, length-from, length-to

• Message Limit Controls: msg-limit-connect, msg-limit-from, msg-limit-to

• URI Whitelist/Blacklist: body

• Null-Rate Controls: null-rate-to

• Spamd User Controls: spamd

• EMEW Secrets: emew

4.2.6.1 Network Controls

Selecting Network Access from the pull down menus at the top of the page allows

control of which hostnames / IP addresses, From, To: or From and To: Keys are white or

black listed by the smtpf application.

The four test boxed at the bottom of the screen allow you to enter the:

• Tag: connect, to, from, connect:from, connect:to: or from:to

• Key: what to match (see below)

• Value: the Action to take (See below)


Clicking on the Tag column on the last line of the Network Controls page list show the

possible values for the Network Controls tag. Selecting the appropriate Tag fills in the

Tag text box.

Once the Tag has been selected the Key and the Action the text boxes need to be filled

in and the Add button selected for the entry to be added and immediately effective on

the Gateway or Gateways if the gateways are clustered.

Possible Key values include any of the following three types:

• IP Address Lookups

• Domain Name Lookups

• Mail Address Lookups

Many of the same tags will be available for other Access Control option:

Key Values: IP Address Lookups

An IP address lookup is typically applied to the connected SMTP client. It will start with a

complete IPv4 or IPv6 address and break it down on delimiter boundaries from right to

left.

IPv4 Lookup IPv6 Lookup

tag:192.0.2.9 tag:2001:0DB8:0:0:0:0:1234:5678

tag:192.0.2 tag:2001:0DB8:0:0:0:0:1234

tag:192.0 tag:2001:0DB8:0:0:0:0

tag:192 tag:2001:0DB8:0:0:0

tag:2001:0DB8:0:0

tag:2001:0DB8:0

tag:2001:0DB8

tag:2001

Note that the compact form of an IPv6 address, "2001:0DB8::1234:5678", cannot be

used. Only the full IPv6 address format with all intervening zeros is currently supported.


Key Values: Domain Name Lookups

A domain lookup may be applied to either the connected SMTP client, where the client's

host name found through a DNS PTR record is searched for, or using the domain portion

of a mail address (see below). A domain lookup will try the IP-domain literal if applicable,

then continue with the FQDN, breaking it down one label at a time from left to right.

tag:[ipv6:2001:0DB8::1234:5678]

tag:[192.0.2.9]

tag:sub.domain.tld

tag:domain.tld

tag:tld

tag:

Important !

Note that the bare tag is often used to specify system wide defaults. Please be sure that

you understand all the ramifications of changing the system-wide defaults before

changing them!

Key Values: Mail Address Lookups

A mail address lookup is similar to a domain lookup, but the search first starts with a

complete mail address, before trying the address's domain, and finally only the local part

of the address.

tag:[email protected]

tag:sub.domain.tld

tag:domain.tld

tag:tld

tag:account@

tag:

Important !

Note that the bare tag is often used to specify system wide defaults. Please be sure that

you understand all the ramifications of changing the system-wide defaults before

changing them!


Note that the Key values described above will be used for all of the controls listed in this

Section. Tag and Key values are not case-sensitive.

Values:

Supported Values for the Network Controls include:

OK white list, by-pass one or more tests

CONTENT white list as far as, but not including, the content filters; used only

with Connect:

DISCARD accept & discard message

NEXT resume lookup, opposite of SKIP

SKIP stop lookup & return no result

SPF-PASS white list sender if SPF returns Pass; used only with

Connect:From: and From:

TEMPFAIL report a temporary failure condition

REJECT black list, either reject or drop

IREJECT immediate REJECT, ignore smtp-delay-checks;

SAVE save a copy of message, if delivered, for debugging or archiving

TRAP accepts and save message to a trap-dir, but do not deliver;

intended for spam trapping and learning

TAG Instead of rejecting a message for policy reasons, simply tag the

subject header, add a X-spam-reason: header and by-pass the

remaining tests.

Important !

The Values listed above are case-sensitive.

In most instances, the above forms of key lookup and actions are sufficient. However,

there may be times when finer granularity of control is required; in which case pattern

lists can be used. A pattern list is a white space separated list of pattern-action pairs

followed by an optional default action. Please refer to the detailed documentation


http://www.snertsoft.com/smtp/smtpf/access-map.html

for directions on how to use Pattern Matching.


Please see Section 4.1.5. Configuring /etc/smtpf/access.cf for example entries

4.2.6.2 Concurrency Controls

This is used to specify the maximum number of concurrent connections an SMTP client

is permitted at any one time. Specify an integer or zero (0) to disable. The bare tag can

be used to specify a global setting. If an SMTP client exceeds the allotted number of

connections, then the incoming connection is dropped, while existing connections

continue.

In the example screen above; The default rate connect is 5 and the default concurrent-

connect value is 2. The IP address 82.69.204126 is allowed unlimited concurrent

connections and unlimited rate-connections.

4.2.6.3 Greylist Controls

The Value sets the amount of time in seconds a correspondent's grey-list record will be

temporarily rejected before being accepted. If several Keys are possible for a given

message, then the minimum Value is used. Specify an integer number of seconds or

zero (0) to disable.

There are two options for the Tag:

grey-connect: Takes an IP address, a hostname or an IP address type Key

grey-to: Takes an email address type Key


In the example screen above grey-listing from scd.yahoo.com and to any address at

fsl.com has been disabled.

4.2.6.4 Message Length Controls

Used to limit the maximum length [size] of a message in octets. The Value is expressed

as a number with an optional scale suffix K (kilo), M (mega), or G (giga). If no length is

given or is -1, then the message can be any length (ULONG_MAX).

When there are multiple message length limits Values possible, then the limit applied, in

order of precedence is:

1. Length-To:. If there is more than one Length-To:, then the maximum limit

specified will be used.

2. Length-From:

3. Length-Connect:

There are three options for the Tag:

msg-length-connect: Takes an IP address, a hostname or an IP address type Key

msg-length-from: Takes an email address type Key

msg-length-to: Takes an email address type Key

In the example screen above, the Default for the Maximum message size that will be

accepted is 10 Mbytes, messages to FSL.com are not limited and messages from

[email protected] are limited to 25 Mbytes.


4.2.6.5 Message Limit Controls

Used to limit the number of messages a SMTP client, sender, or recipient can

send/receive in a given time period. A message limit is given as:

messages '/' time [unit]

which is the number of messages per time interval. The time unit specifier can be one of

week, day, hour, minute, or seconds (note only the first letter is significant). A negative

number for messages will disable any limit.

When there are multiple message limits possible, then the limit applied in, order of

precedence: Msg-Limit-To:, Msg-Limit-From:, and Msg-Limit-Connect.

msg-limit-connect: Takes an IP address, a hostname or an IP address type Key

msg-limit-from: Takes an email address type Key

msg-limit-to: Takes an email address type Key

In the example screen above, there is no limit for the connections from the 192.168.1

subnet. The default message-limit is 1 message per minute and only 25 messages per

hour can be sent to yahoo.com.

4.2.6.6 URI Whitelist/Blacklist

The Body Tag is used to black (REJECT) or ignore (OK) domains that make up mail

addresses or URLs found within the header or body content of a message.

The Body Tag will accept IP address, Domain names or hostname type Keys.

In the example screen above URIs containing the words apple.com or aracmax.com will

be allowed but URIs containing the words spamalot.com will be rejected.


4.2.6.7 Null-Rate Controls

Spammers will often impersonate some random or otherwise false mail address within a

legitimate domain, like hotmail.com. In some cases when a third party mail system

rejects spam or virus mail during the SMTP session, a DSN (bounce message) is

generated and sent back to the false sender. Since spammers typically send millions of

messages with falsified sender addresses, the mail system of the abused domain can be

swamped by the backscatter. smtpf's EMEW facility was designed in part to help with

backscatter, but cannot be deployed in some mail system architectures.

So smtpf provides another mechanism to help with backscatter situations, where smtpf

monitors the rate of DSN or MDN messages (essentially any message from the "null

sender") arriving per minute and rejects such messages above a certain threshold that

can be configured globally by domain and by recipient.

The null-rate Tag will accept email address type Keys.

4.2.6.8 Spamd User Controls

The spamd Tag is used to specify a SpamAssassin configuration to use. If the message

is addressed to a single recipient, then a Spamd:mail lookup is done. If the message is

for more than one recipient, all of whom are within the same domain, then a

Spamd:domain lookup is done. Otherwise the Spamd: default configuration is used. The

Value (right hand side action) must be a user name or address to pass to spamd. It can

be a pattern list. If the special user name OK is used, then the message is not processed

by spamd.

In the example screen above mail to [email protected] will use the spamd:[email protected]

configuration, mail for fsg.com will use the spamd:fsg.com configuration and all other

mail will use the spamd: default configuration

This configuration option when used with virtual users in spamd can be used to allow

per-domain and per-user spamd configuration (e.g. bayes databases and user scores).


4.2.6.9 EMEW Controls

The emew tag is used to specify different emew secrets to match different keys.

In the example screen above mail from [email protected] will use an emew secret of

12Y22123wwww while mail from the xyz domain will use an an emew secret of

aqwerty1235asdfg.

This is used to allow EMEW to be selectively enabled on domains that are able to route

outbound messages via an installation of smtpf.

4.2.7 The Cache Tab

The Cache tab provides simple way to find entries in the shared smtpf shared cache.

Entering a string in the Search: text box and selecting Lookup will show all matches in

the smtpf SQLite shared cache database.


The partial example screen above shows typical results for searching for domain name

as the text string to match.

The Cache Tab also provides for the following pre-formatted searches:

• Cache Activity

• Top Cache Entries

• Top Cache Entries by Type

• Greylisting Activity

The examples screen above show the results of performing a Greylistng Activity search.

It is very seldom necessary to manually manipulate or delete any data from the SQLite

cache. If you are have a greylisting or valid address problem that you believe may be

caused by bad entries in the shared cache, please contact support at [email protected]

for assistance.


4.2.8 The Search Logs Tab

The Search Logs provides a way to find related entries in the mail log files. Simply enter

the text string to match in the text box to the right of the Search button and the select the

check box or boxes to the left of the log file to search then select the Search button

The example above would search maillog and maillog.1 for [email protected]

The example screen above shows the typical results of a log search.

4.2.9 The Users Tab

The Users Tab allows you to add, modify or delete users who have access to the

BarricadeMX user interface.


To add users enter a user name, enter the password twice and select the Add button. To

reset the password select the Reset Password Button, enter the new password twice in

the pop-up window then save the new password. To delete a user, select the Delete

button to the right of the username and confirm the deletion in the pop-up window that

will appear.

4.2.10 The Licensing Tab

The Licensing tab allows you to view the current licensing information and to select and

install a new smtpf / BarricadeMX license if necessary.

Loading a new license is a two step process. First select the license file using the

Choose File button then select the Upload Button. The license file must be copied to

the gateway with the proper permissions before you will be able to select and install the

file. You should receive instructions on how to copy the license file to the system along

with the license file. Please contact [email protected] for help with any problems you may

encounter with the license.


5 Administrative tools and options

5.1 Command Line Options

In addition to the web interface available with CentOS and Red Hat 5.2 systems, the

smtpf process also has command line options to allow starting and Command Options to

assist with starting, stopping and configuring the process without using the web interface.

These command line options include:

To review the smtpf option summary, run:

smtpf -help

To start smtpf:

smtpf

To stop smtpf:

smtpf -quit

To restart smtpf:

smtpf -restart

To restart smtpf using a different configuration file:

smtpf -restart file=/path/to/alt/smtpf.cf

The file option when it appears in the smtpf.cf does nothing other than document which

smtpf.cf was read. It's possible to specify one or more options on the command line in

order to override what appears in smtpf.cf or the hard coded default.

To restart smtpf only if it is currently running:

smtpf -restart-if

The command options shown above can be prefixed by either a plus (+) or minus (-) sign

and both behave the same.

5.2 Runtime Configuration

Typically if you change the contents of smtpf.cf, you must restart smtpf in order for those

options to take effect.


smtpf +restart

However many of the smtpf options can be configured during runtime by telneting to

localhost port 25 and issuing smtpf commands. To connect to the smtpf process run:

telnet 127.0.0.1 25

For security reasons, the following commands only work when the connection comes

from localhost. The possible commands are:

CONN

The CONN command will display a list of all the currently active connections showing the

session ID, SMTP state, client name and IP, session age in seconds, input idle time in

seconds, and total number of octets sent in messages.

KILL <session-id>

The KILL command will terminate the SMTP client session matching the given session-

ID.

OPTN <± option name>

or

OPTN option-name=value

OPTN ±option-name may be used to change the value of a currently loaded smtpf

configuration value in real time and without restarting the smtpf process. An example of

this would be to turn reject a message if the sender's domain has no MX record you

would run:

OPTN +mail-require-mx

The OPTN command without any argument, will display all the current option settings,

one per line. If an argument is specified, it is the same as would be specified in the

smtpf.cf file. If an option influences how smtpf starts up, that options cannot be changed

at runtime.

VERB

or

VERB ±verbose-flag ...


The VERB command without any argument, will display the current verbose logging

flags. Sometimes it's useful to turn on and off certain verbose logging flags in order to

diagnose a problem. For example:

VERB +smtp -uri.

5.3 Statistics

Some options provide real time statistics of the currently running smtpf process. After

connecting to the smtpf process using telnet, the command:

STAT

will produce extensive statistics on smtpf message processing since the last restart.

Starting with version 2.2 , several advanced options have been added to allow

centralized collection and processing of Statistics for a single or multiple gateways.

Please see appendix B - SMTPF 2.2 RELEASE NOTES, the additional documentation

available at http://www.snertsoft.com/smtp/smtpf/ or by contacting [email protected].

.


Appendix A: BarricadeMX/smtpf

Recommended Settings

Important Settings

The following is a list of the important settings in smtpf.cf that are recommended for

maximum effectiveness against spam when using BarricadeMX. All other setting should be

left at their defaults until you have read the documentation fully understand the

consequences of enabling or disabling any option.

Option: +auth-delay-checks

Description: This setting delays some client connection and HELO tests until MAIL FROM: to

allow the sender to authenticate using the AUTH command.

Why?Even when SMTP AUTH is not used, this option is still useful when enabled as it allows the

sender address to be logged which makes it easier to find out the IP address of a sending

system to whitelist, as often the sender will not know this information.

Option: +client-is-mx

Description: Weaken rejects based on client-ptr-required or client-ip-in-ptr until the sender

address is known. Check if the connecting client passes SPF or is an MX for the

sender and reject if it is not.

Why?Option should definitely be switched on if you have +client-ptr-required configured to help

avoid rejecting senders with badly configured DNS.

Option: +client-ptr-required

Description: The connecting client IP address must have a PTR record in DNS otherwise the

connection is rejected.

Why?The +client-is-mx option makes this a safer option to enable and many large sites now have

the same restrictions (e.g. aol.com).


Option: dns-bl=zen.spamhaus.org,bl.spamcop.net

Description: A list of DNS blacklists to consult.

Why?DNS blacklists allow a large amount of connections to be rejected early on within the mail

transaction in a relatively safe manner.

zen.spamhaus.org is run by Spamhaus and is one of the best and most reliable blacklists

available and does not cause excessive false-positives. Please note: Spamhaus may ask

you to take their data-feed service if they feed that your query volume is too high for the

public mirrors.

bl.spamcop.net contains the IP addresses of servers which have blacklisted by

spamcop.net; this can happen if the server is an open relay, an open proxy or has another

vulnerability that allows anybody to deliver email to anywhere, through that server.

Option: dns-gl=list.dnswl.org

Description: A list of IP based DNS whitelists to consult. This only white lists as far as the data

content filters.

Why?Prevents false-positives on all pre-DATA tests for publicly whitelisted systems from known-

good senders.


Option: grey-key=ptr,mail,rcpt

Description: A comma separated list of what composes the grey-list key: ip, ptr, helo, mail, rcpt.

The ptr element is the PTR record for the connecting client minus the first label, so

if host.example.com is the returned PTR value, then example.com is the value

used. If there is no PTR record found or the client IP appears to be a dynamic IP,

then the client IP address is used. Specify the empty string to disable grey-listing.

Why?Enables enhanced greylisting and auto-whitelisting of hosts that pass this test.

Option: grey-temp-fail-period=900

Description: This is the amount of time in seconds a greylist entry is enforced.

Why?Greylisting works by testing that a system attempting to deliver mail correctly implements a

retry-queue by temporarily rejecting mail from new senders for a period of time. Retry

queues are normally run at fixed intervals from 5 minutes to 1 hour or more with the typical

retry interval being 15 to 30 minutes.

A greylist period of 900 seconds is recommended as this will not penalise those senders

with a common interval more than twice, but is high enough to deter some spam software

that attempts to thwart greylisting. It is also chosen because most blacklists have TTL

values of 900 seconds also, so this gives the maximum chance for the blacklist to be

updated with new data between attempts by a sender.

Option: +reject-unknown-tld

Description: Reject top-level-domains not listed by IANA.

Why?This rejects any PTR record or MAIL FROM domain that has an invalid top-level domain.

Very low false-positive rate.


Option: +require-sender-mx

Description: Reject if the sender's domain has no MX record.

Why?Very low false positive rate. If the sending domain has no MX record then the message

cannot be replied to.

Option: +rfc2606-special-domains

Description: When set, use of RFC 2606 reserved domains from the Internet or in mail

addresses is rejected. They are the TLDs .test, .example, .invalid, .localhost, and

the second level domain .example using any TLD. While not part of RFC 2606,

.localdomain and .local are also included. Clients within the LAN and relays are

excluded.

Why?Low false-positives with a good hit ratio.

Option: +rfc2821-strict-helo

Description: Strict RFC 2821 section 4.1.1.1 HELO argument must be a FQDN or

ip-domain literal.

Why?A high proportion of spam from compromised machines that violate this rule which makes it

very effective however a very small proportion of valid senders may violate this rule and

need to be whitelisted.

Option: smtp-drop-after=5

Description: Drop the connection after N temporary and permanently rejected commands, ie.

count any 4xy or 5xy responses and eventually drop. Zero to disable.

Why?Disconnect sessions that generate more than 5 errors in total to help thwart dictionary

attacks.


Option: +smtp-drop-unknown

Description: Drop the connection if client sends an unknown command. To work around Cisco

PIX firewalls broken fix-up protocol, this option ignores any command that starts

with 'XXX'.

Why?Disconnects sessions that send bad commands as a genuine mail server would never do

this.

Option: -smtp-enable-esmtp

Description: Enable enhanced SMTP (ESMTP) for all clients. When disabled any hosts marked

as RELAY in the route-map or from RFC 3330 private IP addresses will be

exempted and always allowed to use ESMTP regardless.

Why?Provided that you do not require SMTP AUTH, then use this option to disable ESMTP. This

has two benefits, some spam software does not correctly handle EHLO rejections and

disconnects instead of falling back to HELO (as per the RFC), other senders send different

arguments to the HELO than the rejected EHLO (a real mail server would never do this)

and is rejected. No false positives are likely with this.

Option: uri-bl=multi.surbl.org,black.uribl.com

Description: Extract from text, HTML, and/or MIME encoded messages bodies URIs

such as http: and mailto: links, then check one or more URI black

lists.

Why?URI blacklists are very effective against spam. Both the listed blacklists aim for zero false-

positives.

Option: +uri-bl-ptr

Description: Check if the PTR result is black listed using uri-dns-bl and/or uri-bl.

Why?Early rejection of server that have a PTR record in a blacklisted domain.


Option: +uri-bl-helo

Description: Check if the HELO/EHLO argument is black listed using uri-dns-bl and/or uri-bl.

Why?Early rejection of servers that HELO with a blacklisted domain.

Option: +uri-bl-mail

Description: Check if the domain of the MAIL FROM: argument is black listed

using uri-dns-bl and/or uri-bl.

Why?Early rejection of senders from blacklisted domains.

All Recommended

Settings

Below is a complete listing of all recommended smtpf.cf settings:

access-map=sql!/etc/smtpf/access.sq3

+auth-delay-checks

avastd-policy=reject

avastd-socket=

avastd-timeout=120

cache-accept-ttl=604800

cache-gc-interval=300

cache-multicast-ip= (set to 239.0.0.1 is using multicast cache sharing)

cache-multicast-port=6920

cache-multicast-ttl=1

cache-on-corrupt=replace

cache-path=/var/cache/smtpf/cache.sq3

cache-reject-ttl=604800

cache-secret=(set if using multi or unicast sharing)

cache-sync-mode=off

cache-temp-fail-ttl=7200


cache-unicast-hosts=(set If using unicast cache sharing)

cache-unicast-hosts+= (additional unicast servers)

cache-unicast-port=6921

-call-back

-call-back-pass-grey

-call-back-strict-greeting

-call-back-uri-greeting

clamd-max-size=512

clamd-policy=reject

+clamd-scan-all

clamd-socket= (set to IP:3310 of clamd server if remote if using clamd locallly set to

SCAN)

clamd-timeout=120

click-secret=secret

click-ttl=90000

click-url=mailto

-client-ip-in-ptr

+client-is-mx

-client-ptr-required

+concurrent-drop

+daemon

deny-compressed-name=*.bat

deny-compressed-name+=*.com

deny-compressed-name+=*.cpl

deny-compressed-name+=*.exe

deny-compressed-name+=*.inf

deny-compressed-name+=*.msi

deny-compressed-name+=*.msp

deny-compressed-name+=*.pif

deny-compressed-name+=*.scr

+deny-content

deny-content-name+=*.bas

deny-content-name+=*.bat

deny-content-name+=*.chm

deny-content-name+=*.cmd

deny-content-name+=*.com


deny-content-name+=*.cpl

deny-content-name+=*.crt

deny-content-name+=*.exe

deny-content-name+=*.hlp

deny-content-name+=*.hta

deny-content-name+=*.inf

deny-content-name+=*.ins

deny-content-name+=*.isp

deny-content-name+=*.js

deny-content-name+=*.jse

deny-content-name+=*.lnk

deny-content-name+=*.mdb

deny-content-name+=*.mde

deny-content-name+=*.msc

deny-content-name+=*.msi

deny-content-name+=*.msp

deny-content-name+=*.mst

deny-content-name+=*.pcd

deny-content-name+=*.pif

deny-content-name+=*.reg

deny-content-name+=*.scr

deny-content-name+=*.sct

deny-content-name+=*.shs

deny-content-name+=*.shb

deny-content-name+=*.url

deny-content-name+=*.vb

deny-content-name+=*.vbe

deny-content-name+=*.vbs

deny-content-name+=*.wsc

deny-content-name+=*.wsf

deny-content-name+=*.wsh

deny-content-name+=eicar*

deny-content-name+=gtube*

deny-content-type=application/*executable

deny-content-type+=application/*msdos-program

deny-content-type+=message/partial


digest-bl=malware.hash.cymru.com

dns-bl=zen.spamhaus.org,bl.spamcop.net

dns-bl-headers=

dns-gl=list.dnswl.org

dns-max-timeout=45

-dns-round-robin

dns-wl=

-deny-content-name=*.ade

deny-content-name+=*.adp

-dupmsg-track-all

dupmsg-ttl=90000

emew-dsn-policy=reject

emew-secret=testy

emew-ttl=604800

file=/etc/smtpf/smtpf.cf.old

fpscand-policy=reject

fpscand-socket=

fpscand-timeout=120

+grey-content

-grey-content-save

grey-key=ptrn

grey-key+=mail

grey-key+=rcpt

grey-report-header=X-Grey-Report

grey-temp-fail-period=600

grey-temp-fail-ttl=90000

-helo-claims-us

+helo-ip-mismatch

-helo-is-ptr

http-timeout=60

idle-retest-timer=300

interfaces="[::0]:25 0.0.0.0:25"

lickey-file=/etc/smtpf/lickey.txt

-lint

+mail-require-mx

+mail-retest-client


ns-bl=bl.snert.net

+ns-sub-domains

+one-rcpt-per-null

-p0f-mutex

p0f-report-header=X-p0f-Report

p0f-socket=

p0f-timeout=60

+rate-drop

rate-throttle=10

+reject-percent-relay

+reject-quoted-at-sign

-reject-unknown-tld

+reject-uucp-route

-relay-reply

-rfc1652-8bitmime

+rfc2606-special-domains

+rfc2821-angle-brackets

+rfc2821-command-length

-rfc2821-domain-length

-rfc2821-extra-spaces

-rfc2821-line-length

-rfc2821-literal-plus

-rfc2821-local-length

rfc2821-pad-reply-octet=

-rfc2821-strict-dot

+rfc2821-strict-helo

-rfc2822-7bit-headers

-rfc2822-min-headers

-rfc2822-strict-date

-rfc2920-pipelining

route-forward-selection=ordered

route-map=sql!/etc/smtpf/route.sq3

run-group=smtpf

-run-jailed

run-open-file-limit=30000

run-pid-file=/var/run/smtpf.pid


run-user=smtpf

run-work-dir=/var/tmp

savdid-policy=reject

savdid-socket=

savdid-timeout=60

-save-data

save-dir=/var/spool/smtpf

server-max-threads=0

server-min-threads=5

server-new-threads=10

smtp-accept-timeout=5

-smtp-auth-enable

-smtp-auth-white

smtp-command-timeout=300

smtp-command-timeout-black=30

smtp-connect-timeout=60

smtp-data-line-timeout=180

+smtp-delay-checks

-smtp-disconnect-after-dot

smtp-dot-timeout=600

smtp-drop-after=5

-smtp-drop-unknown

smtp-dsn-reply-to=

-smtp-enable-esmtp

+smtp-reject-delay

smtp-reject-file=/etc/smtpf/reject.txt

smtp-server-queue=20

-smtp-slow-reply

-smtp-strict-relay

smtp-welcome-file=

smtpf-report-header=X-smtpf-Report

spamd-command=REPORT

spamd-flag-header=X-Spam-Report

spamd-level-header=X-Spam-Level

spamd-max-size=0

+spamd-reject-sender-marked-spam


spamd-report-header=X-Spam-Report

spamd-score-reject=25

spamd-socket=(set to 127.0.0.1:783 is using)

spamd-status-header=X-Spam-Status

spamd-subject-tag=[SPAM]

spamd-timeout=120

spf-best-guess-txt=

spf-helo-policy=

spf-mail-policy=softfail-tag,fail-reject

+spf-received-spf-headers

-spf-temp-error-dns

stats-http-pass=

stats-http-post=http://127.0.0.1/stats.php

stats-http-user=

stats-map=sql!/var/cache/smtpf/stats.sq3

-test-lickey

-test-mode

test-pause-after-dot=0

time-limit-delimiters=

tld-level-one-file=

tld-level-two-file=/etc/smtpf/two-level-tlds

trap-dir=/var/spool/smtpf/trap

uri-bl=black.uribl.com,multi.surbl.org,bl.snert.net

uri-bl-headers=to

uri-bl-headers+=from

uri-bl-headers+=cc

uri-bl-headers+=bcc

uri-bl-headers+=reply-to

uri-bl-headers+=x-apparently-to

uri-bl-headers+=x-envelope-sender

-uri-bl-helo

-uri-bl-mail

uri-bl-policy=reject

-uri-bl-ptr

verbose+=smtp

verbose+=savdid


verbose+=cli

verbose+=attachment

verbose+=headers

verbose+=digest

verbose+=subject


Appendix B: SMTPF 2.2 RELEASE NOTES

With the release of smtpf 2.2, come many improvements. Below are the principal highlights con-cerning new options and significant changes:

Attachment Reject Policies Using simple file name patterns, deny attachments based on attachment name, content-type, and/or file names found in .zip and .rar compressed archives: deny-content deny-content-type deny-compressed-name

Digest DNS Blacklist Support An MD5 hash of the message body is generated and checked against one or more digest black-lists. Inspired by http://www.team-cymru.org/Services/MHR/ digest-bl

Enhanced Message-ID for Email Watermark (EMEW) Version 2 It is now possible to specify different EMEW secrets by individual sender, sender domain, or sender account for outbound tagging and validation of inbound non-delivery reports or content white listing of replies. This allows an ISP to apply EMEW only for those domains known to use the ISP outbound mail servers exclusively and exclude those domains that might use a mixed model. A new emew: access-map tag has been added.

New access-map action words. IREJECT immediate REJECT, ignore smtp-delay-checks; SAVE save a copy of message, if delivered, for debugging or archiving TRAP accept and save message to a trap-dir, but do not deliver; intended for spam trapping and learning TAG Instead of rejecting a message for policy reasons, simply tag the subject header, add a X-spam-reason: header and by-pass the remaining tests. TEMPFAIL report a temporary failure condition


SMTP Cache Manipulation Commands CACHE GET key CACHE PUT key value CACHE DELETE key

Sophos Anti-virus support savdid-socket savdid-timeout savdid-policy

STAT command output changed The output from STAT RUNTIME, STAT HOURLY, and STAT WINDOW commands have been merged into a single STAT command that provides the merged output of the three previous commands.

Statistics data collection It is now possible to have BarricadeMX send the STAT output to a central server for collection, processing, and/or archiving. New option is: stats-http-post stats-http-user stats-http-pass

Time limited recipient addresses BarricadeMX power users can now specify as part of their email address a time limit field that limits the validity of the supplied address. Intended for use by users who want to supply short lived address to questionable web sites registration forms and/or mailing lists. See time-limit-delimiters

New ClamAV for attachments only scanning. Added clamd-scan-all option, which defaults to on. When disabled, only scan messages with attachments.

New DNS BL option Parse and check select message headers for IP addresses to be checked against one or more DNS BL: dns-bl-headers (experimental)


Options to rename or disable certain extension headers grey-report-header p0f-report-header smtpf-report-header spamd-flag-header spamd-level-header spamd-report-header spamd-status-header

New call-back options call-back-strict-greeting call-back-uri-greeting

New URI BL options. uri-bl-headers (experimental) uri-sub-domains (restored) uri-cite-list ns-bl ns-sub-domains (experimental)

RFC 1652 8BITMIME Added simple pass-through 8bit support only. smtpf will not do 8bit to 7bit conversion when for-warding a message. rfc1652-8bitmime

RFC 1870 SIZE Support Added support for SMTP SIZE parameter extension. Used in conjunction with the existing access-map size limitation tags length-connect:, length-from:, and length-to:. When the SIZE parameter is specified, then this allows for rejection based on SIZE at RCPT time instead of have to read the message and reject at dot.

BarricdeMX for Windows & Mac OS X Beta testers wanted. The native Windows version of BarricadeMX is now in beta testing. Please contact Fort Systems Ltd. ([email protected]) if you are interested in participating in the beta test phase due to start soon. BarricadeMX will soon begin testing for Mac OS X and we are also interested in finding partici-pants to test this platform.

Documents

BMX 2.2 User Manual - fortantispam · • Avast!, ClamAV, and F-Prot anti-virus support • "Client-Is-MX" heuristics for PTR and IP in name checks • Concurrent connection limits