While
commercialization of the Internet has brought many benefits,
among the negative effects is the proliferation of Unsolicited
Commercial E-mail (UCE), often called "spam."
The Virtual Server controls spam in the following manner:
- Blocking spam from
being sent to users on the Virtual Server.
- Blocking spam from
being sent through the Virtual Server (relaying).
Blocking Incoming Spam
Defending the Virtual Server from receiving spam is tricky. One method for
blocking spam is to enter the return address on the
spam in the ~/etc/spammers file on the Virtual Server.
Blocking E-mail from
Specific Hosts
- From your Virtual Server ~/etc/spammers file, type:
username@hostname
or:
hostname
where username
is the username of the sender and hostname
is the hostname portion of the sender's address,
often just a domain name.
- From the command
prompt, enter vnewspammers. This action rebuilds
the ~/etc/spammers.db file so that changes
can take effect.
Maintaining the ~/etc/spammers
File
When choosing values
to place in the ~/etc/spammers file, you should
understand the layout and contents of the mail message
headers in an unsolicited message. Understanding the
layouts of mail messages (as read by your Virtual Server)
enables you to locate and recognize the message's SMTP
envelope sender.
Your Virtual Server places
the SMTP envelope sender address in the header line
that begins with "From " (the word "From"
followed by one space character).
Notice that the
differences between "From" and "From:"
Header lines are not required to be the same, although
they often are. The "From:" header line is
part of the message content, not part of the SMTP envelope.
If a discrepancy exists between the "From "
address and the "From:" address, use the "From
" address as your value for inclusion in the ~/etc/spammers
file.
Envelope sender blocking
is useful but not foolproof. Since the envelope sender
can be (and often is) falsified by spam purveyors, the
blocking can be circumvented. However, many messages
are deflected, so the effort is not entirely wasted,
provided that you vigilantly maintain the ~/etc/spammers
file.
POP(IMAP)-before-SMTP
Relay Blocking
Unauthorized SMTP relaying
abuse is a growing trend, usually used by individuals
or groups of individuals to send large amounts of unsolicited
commercial e-mail.
An SMTP relay incident
occurs when an SMTP server is used to deliver an e-mail
message that is not destined to any of its local users.
The SMTP server passes the message on to another SMTP
server, hence the term "relay," which in turn
routes it to the eventual recipient user. SMTP relaying
enables the injection of legitimate e-mail messages
into the mail system from client machines that do not
offer full SMTP server capabilities (such as many PCs
running Windows or Macintosh computers). Unprotected
or "open" SMTP servers can be used as SMTP
relays for unsolicited e-mail campaigns. (Unscrupulous
individuals target an unprotected SMTP server, send
the SMTP server a single copy of a message, and then
request that the SMTP server relay the message to recipients.
Many servers crash from the sheer load handling bounced
e-mail from invalid e-mail addresses, not to mention
complaints recipients of the unsolicited commercial
e-mail.)
In the default configuration,
the Virtual Server's SMTP server is closed to all users
unless they have a valid username and password. This
shuts down relaying and protects the Virtual Server's
resources. To do this, the Virtual Server system uses
a technique sometimes called "POP-before-SMTP"
(since it also applies to the IMAP server, it could
also be called IMAP-before-SMTP) to limit SMTP relaying
to users who have previously accessed the POP server
(or the IMAP server) with their password.
POP-before-SMTP relay
blocking works every time someone successfully enters
a correct username and password to the POP server. The
POP server records the remote client IP address for
later use by the SMTP server.
Note: Because
of POP-before-SMTP relay blocking, your users must check
their e-mail (by accessing either the POP server or
the IMAP server) before they try to send e-mail. The
SMTP server refuses to accept their outgoing mail message
otherwise. POP-before-SMTP relay blocking has the largest
effect on users who have a dynamically allocated IP
address each time they connect to the Internet.
Configuring Your E-mail
Clients to Authenticate Before Sending E-mail
- From "check
mail every x minutes," set the number of minutes
a number such as 15. The check mail option makes the
e-mail client authenticate first (in this case every
15 minutes) before sending.
- Newer e-mail client
software has POP-before-SMTP setup options. Choose
the "authenticate before sending" option.
Managing POP-before-SMTP
In the default configuration,
your Virtual Server never removes addresses from the
database. Once an address is recorded, it is always
valid. Users contacting your SMTP server from their
IP address are permitted to use the server as an SMTP
relay host. The command vsmtprelay allows you
to manage the IP addresses in the ~/etc/relayers.db
file. Here are some examples of using vsmtprelay:
Listing All Recorded
IP Addresses
From your Virtual Server
command prompt, type:
% vsmtprelay list
Results resemble the
following example:
# timestamp (UTC): Tue
Sep 22 22:15:27 1998
10.11.12.13 906502527
The example above shows
the recorded IP address (10.11.12.13), the associated
timestamp (906502527), and a comment line showing the
timestamp in decoded form as a date and time in Coordinated
Universal Time (UTC).
Listing All Addresses
Older Than Ten Minutes in the Database
From your Virtual Server
command-prompt, type
% vsmtprelay list 10
Listing Every Address
in the Database, Including Those with Timestamps in
the Future
From your Virtual Server
command-prompt, type:
% vsmtprelay dump
Editing the Database
Contents
From your Virtual Server
command-prompt, type:
% vsmtprelay dump >
~/etc/relayers
Note: The database
contents are placed in the ~/etc/relayers file.
You can manually edit (adding, changing, or removing
entries) the contents of the ~/etc/relayers.db
file.
Rebuilding the Database
From Your Edited Copy
From your Virtual Server
command-prompt, type:
% /usr/sbin/makemap
hash ~/etc/relayers.db < ~/etc/relayers
Expiring All Addresses
in the Database
From your Virtual Server
command-prompt, type:
% vsmtprelay expire
Expiring Addresses in
the Database Older Than 60 Minutes
From your Virtual Server
command-prompt, type:
% vsmtprelay expire
60
Using the crontab Command
to Manage relayers.db
Using your cron
table, you can implement automatic address expiration.
By experimentation, you can arrive at a workable policy
that balances the requirements of server security and
the convenience of your users. A detailed explanation
of cron can be found in Chapter 8.
Implementing a Strict
Address Expiration Policy
From your cron
table, type:
*/15 * * * * /usr/local/bin/vsmtprelay
expire 60
where every 15 minutes
any addresses older than 60 minutes are removed from
the database.
Note: The example
above yields a 60 minute time window for SMTP relay
permission (with a granularity of 15 minutes).
Implementing a Lenient
Address Expiration Policy
From your cron
table, type:
0 0 * * * /usr/local/bin/vsmtprelay expire
where 0 0 means
that once a day at midnight, the address database is
completely cleared.
Note: The example
above enables your users to relay the entire day (if
they check their mail from that IP address at least
once during the day).
|