unix virtual server
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

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

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

Hosting  ::  Web Design  :: Server Administration  ::  Tech Support  ::  Contacts
Data Centers  ::  Tier I Global IP Network  ::  SLA/Contracts  ::  Search  ::  Account Login