PMDF e-Mail Interconnect provides a wealth of proven tools for dealing
with unsolicited bulk e-mail, commonly referred to as "spam". These
tools, described in more detail below, include:
- Access controls: reject mail from known spam sources
as well as control who within your organization can send or receive
e-mail.
- Mailbox & system wide filtering: individual users, through
PMDF's web interface, can manage their own spam filters, taking
control over what mail is delivered to their mailbox.
- Address verification: refuse mail with invalid originator
addresses.
- Realtime Blackhole List: refuse mail from recognized
spam sources as identified by the Mail Abuse Protection System's
Realtime Blackhole List (MAPS RBL). The MAPS RBL is a responsibly
managed, dynamically updated list of known spam sources.
- Relay blocking: prevent spammers from
using your mail system as a mail relay to send their unwanted spam
to tens of thousands of recipients.
- Authentication services: enable password authentication
in your SMTP server via the Simple Authentication & Security
Layer protocol (SASL).
- Sidelining: silently sideline or even delete potential
spam messages.
- Comprehensive tracing: reliable mechanisms for identifying
a message's source.
These tools may be used individually or in concert. They are designed
to be as efficient as possible so as to minimize your resource cost
in dealing with the abuse presented by spam.
Before continuing our discussion of PMDF's spam fighting facilities,
there's a basic yet important concept in PMDF which needs to be brought
to light. Mail traffic passing into, through, and out of PMDF can
be separated into distinct channels based upon various criteria. Important
to our discussion is that source and destination e-mail address as
well source IP address or subnet are among these criteria. Different
processing characteristics can then be ascribed to these different
mail flows, referred to hereafter as channels. Consequently, different
access controls, mail filters, processing priorities, and tools may
be applied in different ways and combinations to these different channels.
For example, you can process mail originating from within your domain
differently than mail originating from the outside world.
In addition to channel-based message flow classification, another
useful classification is mailing list traffic. Traffic for a given
mailing list may come into PMDF via a number of different channels
and go back out via a number of different channels. As such, when
dealing with mailing lists, it is useful to think in terms of the
list itself and not in terms of channels. PMDF recognizes this and
allows many of the channel-specific spam fighting tools to also be
applied in a mailing-list specific fashion. For further details, see
the description of mailing lists in the PMDF System Manager's Guide.
PMDF has a general purpose mechanism which may be used to reject mail
based upon a variety of criteria including the message's source or
destination e-mail addresses as well as source IP address. This mechanism
may be used in a variety of ways to combat spam. For example, refusing
mail from specific senders or entire domains (e.g., mail from friend@public.com).
This mechanism can be extended with a database should you have large
lists of screening information. This same mechanism is also suitable
for maintaining a database of internal users who are or are note allowed
to send mail out certain channels; e.g., restrict on a per-user basis
who can or cannot send or receive Internet mail.
For further details, please see the description of the SEND_ACCESS,
ORIG_SEND_ACCESS, MAIL_ACCESS, and ORIG_MAIL_ACCESS mapping tables
in the PMDF System Managers Guide.
PMDF provides per-user, per-channel, and system-wide mail filters.
These filters can be managed through web pages or written with a text
editor. Using these filters, users may control what mail messages
are or are not permitted to be delivered to their mailbox. For instance,
a user tired of "make money fast" spam can specify that any messages
with such a subject be rejected. Similar controls may be applied by
the postmaster to all messages flowing through a channel or all of
PMDF.
The mail filtering in PMDF is based upon the new Sieve filtering
language being developed by members of the Internet Engineering Task
Force (IETF).
See the PMDF System Manager's Guide for further information on PMDF's
mailbox filters.
Spam messages often use invalid originator addresses. The PMDF SMTP
server can take advantage of this by rejecting messages with invalid
originator addresses. If the originator address does not correspond
to a valid host name, as determined by querying the Internet Domain
Name System (DNS), the message can be rejected.
For further details, refer to the description of the mailfromdnsverify
channel keyword in the PMDF System Manager's Guide.
The Mail Abuse Protection System's Realtime Blackhole List (MAPS RBL)
is a dynamically updated list of known spam sources identified by
source IP address. The PMDF SMTP server supports use of the MAPS RBL
and can reject mail coming from sources identified by the MAPS RBL
as originators of spam. The MAPS RBL is a free service provided via
the Internet DNS.
For further information on using the MAPS RBL with PMDF, please see
the description of the ENABLE_RBL option of the PMDF Dispatcher.
The features discussed so far have focused on preventing your own
users from receiving spam. However, a comprehensive spam prevention
strategy should also include tactics for preventing spammers from
relaying mail through your system to other systems. [1]
PMDF has facilities to prevent unauthorized use of your system for
mail relaying. In its simplest form, this is achieved by allowing
local users and systems to relay mail while rejecting relay attempts
from non-local systems. This differentiation between local vs. non-local
is easily and securely made by using IP addresses as the differentiator.
It's easy in that it's simple to determine if an IP address is part
of your IP network. It's secure in that IP addresses are not readily
forged: the IP router between your site and the Internet rejects incoming
data packets which purport to have as their source IP address an address
within your network.
Please see Preventing Mail Relaying with PMDF
for futher details. Note that PMDF configurations generated with PMDF
V5.2 or later configuration tools include relay blocking.
The PMDF SMTP server implements the Simple Authentication and Security
Layer protocol (SASL, RFC 2222). This may be used with popular POP
and IMAP clients to provide password-based access to your SMTP server.
A typical usage for SASL is to permit mail relaying for externa,l
authenticated users. This solves the common problem posed by local
users who use Internet Service Providers (ISPs) from home or while
travelling.[2] Such users, when connecting to your mail system, will have
non-local IP addresses. Any relay blocking which only takes into account
source IP address will not allow these users to relay mail. This difficulty
is overcome through the use of SASL which allows these users to authenticate
themselves. Once authenticated, they may be permitted to relay mail.
PMDF's authentication services allow for a number of different password
sources and may be extended to use site-defined password sources.
Please see the PMDF System Manager's Guide for further details.
The access control mechanisms cited previously may also be used to
defer the processing of suspect messages for later, manual inspection.
Or, rather than sideline, the destination address may be changed,
thus routing the suspect mail to a specific mailbox or even the bitbucket
channel. This tatic is useful when spam is being received from a known,
fixed origin and outright rejection will only cause the spammer to
change their point of origin. Similar features are available for PMDF
mailing lists.
For futher details, see the PMDF System Manager's Guide. Specifically,
the discussion of the holdlimit channel keyword as well as
the $A, $B, $D, and $H flags of the SEND_ACCESS, ORIG_SEND_ACCESS,
MAIL_ACCESS, and ORIG_SEND_ACCESS mapping tables.
PMDF's SMTP server discovers and records crucial origination information
about every incoming mail message. For example, source IP address
and the corresponding host name. In addition, use of the Identification
Protocol (RFC 1413), is also supported. All discovered information
is recorded in the message's trace fields (e.g., the Received: header
line) as well as in log files. Availability of such reliable information
is crucial in determining the source of spam which often has forged
headers.
Associated with many of these features, are a myriad of fine details.
For instance, site-supplied screening code and databases may be interfaced
directly to PMDF; third-party spam and virus scanners may be invoked;
format conversions enabled; etc. Particularly annoying to spammers
is that rejection responses from the SMTP server may intentionally
be delayed by, say, 15 seconds.
[1] Spammers who send out tens of thousands
of mail messages do so by sending relatively few messages to unsuspecting,
store-and-forward mail systems. Each of these few messages may have
hundreds or thousands of recipient addresses. The "attacked" store-and-forward
mail system in receipt of one of the messages is then expected (by
the spammer) to relay (resend) the message to each of its recipients
-- recipients who are generally in many different domains unrelated
to that of the attacked mail system. Thus, the attacked mail system
is used as a mail relay and the burden of contacting thousands of
individual recipient mail systems is foisted by the spammer onto it.
Moreover, the individual recipients are often deceived into thinking
that the attacked system is responsible for the spam.
[2] POP and IMAP clients send e-mail by
relaying it through a server system. This way, should the ultimate
destination machine not be immediately reachable, the burden of holding
onto the e-mail and periodically attempting to deliver it is put upon
a presumably more capable and robust MTA rather than the client itself
which may be nothing more than a laptop or pda device.
|
