First, let's define what is UCE (Unsolicited Commercial Email) or spam. One of the best definitions comes from http://spam.abuse.net/whatisspam.html:
"Spam [UCE] is flooding the Internet with many copies of the same message, in an attempt to force the message on people who would not otherwise choose to receive it. Most spam is commercial advertising, often for dubious products, get-rich-quick schemes, or quasi-legal services. Spam costs the sender very little to send -- most of the costs are paid for by the recipient or the carriers rather than by the sender."
As a server administrator you should adopt and enforce a spam or UCE policy to be a good "Netizen". Make sure you publish your policy to your clients and potential clients. Many good anti-spam policies can be found at http://spam.abuse.net/goodsites/index.html. You should also show your support for the proposed law to outlaw spam on the Internet (H. R. 1748, "The Netizens Protection Act of 1997") by writing or calling your congressman. For more information about this see http://www.cauce.org/.
Until there is a law to outlaw spam there are a few things you can do now to make the spammer's life tough. Before we describe possible solutions, let's make sure we understand the problem. There are many ways that a spammer may abuse your server, including:
As for the first two, there are methods to block spam from spammers and block spammers from using your server as a relay host. The rest of this paper describes in detail some ways to do both of these.
There are a number of ways to block email from spammers. We have included with all virtual server accounts an easy and straight forward way to block email from an address or domain name. In your ~/etc/ directory there is a file called "spammers" which contains something like the following:
# # Simply add the hostnames or email addresses on their own lines below # Examples: # cyberpromo.con (blocks all mail from the hostname "cyberpromo.con") # spammer@aol.con (blocks mail only from "spammer@aol.con") # spammer@aol.con cyberpromo.con
Lines that begin with "#" are comments. Other lines are domains or email addresses to block. In the above example, all email with the email address "spammer@aol.con" or any email address with the domain name "cyberpromo.con" in the "From:" line is blocked by the server. To add additional email address or domain names to block, do the following from the TELNET shell prompt of your Virtual Server:
% pico ~/etc/spammers<add the domain name or email address at the end>
% vnewspammers
Important Note: If your account has been with Digital Daze for a long time (or you are missing the "~/etc/spammers" file) you may need to run "updatesendmailcf" command at the TELNET shell prompt to add this Anti-Spam feature.
For well known spammer's email addresses and domains for your ~/etc/spammers file see:
http://www.webeasy.com:8080/spam/spam_download_table
http://www.idot.aol.com/preferredmail/
http://www.cco.caltech.edu/~cbrown/BL/
http://www-math.uni-paderborn.de/%7Eaxel/BL/
or send email to bobby@fujipub.com (Bobby Holstein) with the subject line "SPAMMERFILE"
or send email to spamlist@us.net
The problem with the above solution is that spammers like to forge their addresses and try to mask their identity and origin in an attempt to circumvent this type of block. This can be easily done by the spammer by forging the "From:" line in SMTP (Simple Mail Transport Protocol). Therefore, you may have to filter on other things besides the "From:" line in the headers.
The procmail mail filtering program, developed by Stephen van den Berg at RWTH-Aachen, Germany, provides a powerful mechanism to analyze and filter incoming mail for anything in the headers. The most recent version of procmail is always available for free download at:
ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail
While an occasional spam message might slip through even the most careful defenses, taking steps to actively block spammers will greatly reduce the number of spam messages delivered to your users.
Because procmail is well-suited to processing email messages, it forms a handy weapon in the war against spam. Catherine Hampton has developed a set of procmail configuration files, named the "Spam Bouncer", that can be used to implement a sophisticated spam blocking scheme with procmail. The latest version of the Spam Bouncer is always available for free download at http://www.spambouncer.org.
She has also prepared a set of instructions for new procmail users interested in understanding how the Spam Bouncer and procmail interact, available at http://www.spambouncer.org/proctut.shtml.
One of the interesting capabilities of the Spam Bouncer is its ability to divide potentially objectionable mail into two different levels of suspicion: blatant spam messages and questionable messages. Messages that are determined to be blatant spam may be discarded, archived for later review, or even may be made the object of an automated complaint filed with the connectivity providers of some of the most notorious spammers. If the message is deemed to be questionable, either because it came from a site known to harbor spammers or it contains some of the catch phrases commonly used by spammers in their messages, it can be returned to the sender with a message including a keyword to be used in the header of future messages. Since spammers rarely use valid return addresses in their mail, and since the likelihood that they personally read their replies is small, this provides a mechanism for selectively accepting messages that would otherwise be rejected. Future messages containing the required keyword are automatically accepted by the Spam Bouncer, thus permitting safe delivery of the message.
Installing, configuring, and maintaining the Spam Bouncer are tasks recommended only for advanced users since the procedure requires a moderate level on Unix knowledge and a solid understanding of the virtual server environment. The Spam Bouncer documentation pages mentioned above provide thorough documentation and should be consulted regularly since the Spam Bouncer is often updated and improved.
Other spammers, rather than sending their abusive email to you and your customers, may use your Virtual Server's email server to "relay" their spam to other people. This is an attempt to make it look like it was your site that sent UCE. Here is what can be done to stop abusive relaying through your server:
We have two suggestions for adding to your email headers. The first is turning on what is called authentication-warnings or "authwarnings". Setting the authwarnings option causes your email server to insert special headers into the mail message that advise the recipent of reasons to suspect that the message may not be authentic. When this is set and email is "spoofed" (forged through your site) the recipent will see something like the following in their email headers:
X-Authentication-Warning: yourdomain.com: Host spammer.cyberpromo.con [192.168.29.130] claimed to be yourfriend.com
Authwarnings are added by editing your ~/etc/sendmail.cf file and adding the following:
Opauthwarnings
to the "options" area. Here is how you do this:
TELNET to your server, then using your favorite UNIX editor, edit ~/etc/sendmail.cf
% pico ~/etc/sendmail.cf
Look for the area in the sendmail. cf file that looks like:
#############
# Options #
#############
Oa1 # Wait (in minutes) for alias file rebuild
OA/etc/aliases # location of alias file
OC10 # Checkpoint queue runs every N deliveries
OF0600 # Temporary file mode
Og100 # Default GID
OH/etc/sendmail.hf # SMTP help file
OI # Insist that the name server be running
Ok5 # Open connection cache size
Om # Expand aliases to include sender
On # Verify RHS in newaliases
OQ/usr/spool/mqueue # Queue directory
OS/etc/sendmail.st # Stat file
OT3d # Queue timeout and warning time
Ot # Use TZ environment variable
If you already have a line in the options area that begins with an "Op" then just add "authwarnings" to that line, separated from the other flags with a comma. If you don't already have an "Op" line, then add the following below that last option line (lines that begin with "O"):
Opauthwarnings # Privacy Options: Authentication Warnings
Another suggestion is to add information about who to contact if there is a problem with mail coming from your server. For example, something like the following could be added about email "passing through" your server:
X-Info1: *****************************************************************
X-Info2: * This email came through the SMTP.ABC.ORG email server. If you *
X-Info3: * suspect this email was sent by a spammer through this site *
X-Info4: * please forward the ENTIRE email message including headers to *
X-Info5: * abuse@abc.org so action can be taken against the spammer. *
X-Info6: **** Fight Spam on the Internet! See http://spam.abuse.net ****
X-Info7: **** Outlaw Spam: Support HR 1748 See http://www.cauce.org ****
X-Info8: **** Block Spam: Blackhole list see http://maps.vix.com/rbl ****
X-Info9: *****************************************************************
This educates the recipient that the email did indeed come from your server and you are willing to do something about the message if they are willing to forward you the message. Note that spammers will also see this message when they send a few test messages to see what your headers look like. With the right message, like above, they may think twice about using your server for their UCE.
Here is how you add your personal header message in your email:
TELNET to your Virtual Server, then with your favorite UNIX editor, edit your ~/etc/sendmail.cf file:
% pico ~/etc/sendmail.cf
In the "Header formats" section of file, and after the very last line that begins with "H", add something like the following:
H?M?X-Info1: $.*****************************************************************
H?M?X-Info2: $.* This email came through the SMTP.ABC.ORG email server. If you *
H?M?X-Info3: $.* suspect this email was sent by a spammer through this site *
H?M?X-Info4: $.* please forward the ENTIRE email message including headers to *
H?M?X-Info5: $.* abuse@abc.org so action can be taken against the spammer. *
H?M?X-Info6: $.**** Fight Spam on the Internet! See http://spam.abuse.net ****
H?M?X-Info7: $.**** Outlaw Spam: Support HR 1748 See http://www.cauce.org ****
H?M?X-Info8: $.**** Block Spam: Blackhole list see http://maps.vix.com/rbl ****
H?M?X-Info9: $.*****************************************************************
This will place the information lines below the lines in the header.
Rather than letting anyone relay email through your site, you may want to block relaying except for sites that have your approval. Again, this requires you to edit your ~/etc/sendmail.cf file to add an additional "rule".
##############################################################
# Ruleset check_rcpt - Shutdown relaying through this server #
##############################################################
# dequoting map - Needed for SPAM hack below
Kdequote dequote
# permitted relay sites file
F{RelayOK} -o /etc/relayok.txt
Scheck_rcpt
# anything terminating locally is ok
R<$+ @ $=w >[tab] $@ OK
R<$+ @ $* $={RelayOK} >[tab] $@ OK
# anything originating locally is ok
R$*[tab] $: $(dequote "" $&{client_name} $)
R$=w[tab] $@ OK
R$* $={RelayOK}[tab] $@ OK
R$@[tab] $@ OK
# anything else is bogus
R$*[tab] $#error $: "550 Relaying Denied"
IMPORTANT NOTE:
[tab] should be replaced with tab's. This new rule ("check_rcpt")
will not work without tab's.
digitaldaze.com
mycomputer.mydomain.com
myisp.com
Make sure you don't have blank lines in this file.
One problem with the above "anti-relaying" rule is that it relies on the DNS "reverse lookup" to be correct. Spammers love to spoof their reverse lookup. In other words, the spammer could guess one of the domain names in your ~/etc/relaydomains.txt list (like your domain name) and use it. However, it is very difficult to spoof IP addresses to the point that it is not worth the spammer's time. Therefore, to relay by IP addresses, you can use the following rule instead of the one above:
##############################################################
# Ruleset check_rcpt - Shutdown relaying through this server #
##############################################################
# dequoting map - Needed for SPAM hack below
Kdequote dequote
# permitted relay sites file
F{RelayOK} -o /etc/relayok.txt
Scheck_rcpt
# Anything terminating locally is ok
R< $+ @ $=w >[tab] $@ OK
# Anything originating locally is ok
R$*[tab] $: $(dequote "" $&{client_name} $)
R$=w[tab] $@ OK
R$@[tab] $@ OK
# Check the client address
R$+[tab] $: $(dequote "" $&{client_addr} $) $| $1
R0 $| $*[tab] $@ ok
R$={RelayOK}$* $| $*[tab] $@ ok
# anything else is bogus
R$*[tab] $#error $: "550 Relaying Denied"
Again, remember to replace the "[tab]" with the tab character.
In this case, the ~/etc/relayok.txt file should look something like:
127.0.0.1 192.168.1.100 10.123
Again, don't include any blank lines. The first line ("127.0.0.1") you should always have. This is a reserved IP address for "localhost". The second line shows how you can allow the host at 192.168.1.100 to relay email through your site. The third line is an example of allowing a whole subnet relay through your site. For example, this could be the subnet for your ISP that you use. In other words, when you dialup to your ISP you always get an address that starts with "10.123" but the last two numbers are different every time. Note that you should include the IP address of your Virtual Server so email can be sent from it.
Now, rather than blocking all IP addresses except the ones listed in relayok.txt let's say you want to allow all IP addresses except the ones listed in the file relaynotok.txt. This can be done by modifying the previous example (in section 3.2):
# permitted relay sites file
F{RelayOK} -o /etc/relayok.txt
to:
# not permitted relay sites file
F{RelayNotOK} -o /etc/relaynotok.txt
R$={RelayOK}$* $| $*[tab] $@ ok
# anything else is bogus
R$*[tab] $#error $: "550 Relaying Denied"
to:
R$={RelayNotOK}$* $| $*[tab] $# error $: "550 Relaying Denied"
# anything else is OK
R$*[tab] $@ ok
Again, [tab]'s should be replaced with actual tab characters.
With these modifications if you detect someone relaying through your virtual server you can simply add the spammer's IP address block in your ~/etc/relaynotok.txt file. For example, say someone complains to you about spam that is coming from your site (yourdomain.com). From the headers of the spammer's email you should see something like the following:
Received: from yourfriend.com (smtp.spammer.con [192.168.1.232]) by yourdomain.com (8.8.5) id NAA29638; Thu, 9 Oct 1997 13: 32: 33 -0600 (MDT) Date: Thu, 9 Oct 1997 13: 32: 33 -0600 (MDT)
Also, in your ~/usr/log/messages file you should see something like: