CREATING A SPAMFILTER RELAY SERVER
USING FEDORA CORE 1
By Scott L. Henderson
Document originally created July 2002.
Changed by Jan B. Jensen
Last revised 12/05/2003.
Why this document exists:
There is a desire to control the flow of "SPAM" into
organizational email systems. SPAM (also known as "UCE", for
"Unsolicited Commercial Email" or "UBE" for "Unsolicited Bulk
Email" -- and by other, less flattering names), is growing at an
alarming rate. Many IT department budgets, however, are tight, and
many administrators and executives are looking to Open Source
solutions to reduce costs. To fight SPAM, you COULD buy another
server, purchase and install ANOTHER copy of a proprietary operating
system, and THEN buy a 3rd party anti-spam tool. But what if you could
take that old Pentium 450 server with 196MB of RAM (or even a lesser
machine, in most cases), and turn it into a better anti-spam tool than
you could BUY?
This anti-spam relay server was my first foray into putting Linux to
work in a production environment. I created this document from my
experiences, and since then (summer of 2002), I've worked with many
other IT people who are beginning to explore the power and flexibility
of Linux and other OSS (Open Source Software) options. I've found that
many administrators of small to medium organizations (say, from 5 to
5000 users) don't yet have the knowledge or experience - or confidence
- to build an Open Source system, like this powerful anti-spam tool. This
document is an attempt to address that situation. With no risk, one
can try this spamfilter between an email server and the Internet. Even
if you completely botch something, you can always just yank this
system out of the loop. So it is a nice way to learn Linux, and get
your feet just a little bit wet. I hope you will be as pleased as I
(and my boss!) have been with the results.
For experienced *nix admins, or others who might want to set up a very
simliar system to this, but on OpenBSD, you should have a look at
this
excellent page. (It's a nice reference for the rest of us too!)
Although any version of Linux, as well as other *nixes can be used for this
configuration, this document describes using Red Hat version 9. Red Hat is
changing the way they roll out their distribution. They are discontinuing
the line of "Red Hat Linux 7, 8, 9" etc. version numbers, and in place of
this they will be offering 2 lines, the "Enterprise Linux" (RHEL)
versions - targeted primarily at business users - and "Fedora", for
"technical enthusiasts". This means if you want to run Red Hat, you should
read up on these new distributions and decide how you want to move forward.
Of course, Red Hat 9 can still be used right now, and into the future. But
the Red Hat will not be maintaining a support program for it after April
2004, so keeping the box current with patches would become a somewhat more
complicated task.
A group has been formed to update this document to the new Red Hat server versions
RHEL AS and ES as well as Fedora. If you would like to join in and help, whether
testing or formatting, or whatever, please email me!
The old version of this (based on Red Hat 7.3, and versions of amavis and
SpamAssassin you might not even still be able to find) is
here.
The "Changelog" is
here.
My email address is scottlhenderson-at-yahoo.com (yes, replace the -at- with
the standard "@" symbol).
If you have built this system before, are an experienced Linux administrator,
or for other reasons you want to skip all explanations and just perform the
steps necessary to build this spamfilter, each major item that needs to
be done is conveniently placed (where the Cat in the Hat keeps all his
valuables):
Commands to be typed in at a command prompt will have a slightly
different font than the rest of the text on this page:
And those items that you either need
to read, make a decision on, etc, in addition to being "in the box",
will be italicized:
It will be assumed that if you follow the 'fast build' boxes, you
will understand how to do certain
things without explanation, like getting to a command line, basic vi commands,
knowing when to replace example values - like "domain1.com" and "domain2.com"
- with your own, when appropriate, etc.
Description:
This Guide documents a step-by-step Fedora Linux install using the well-established
Open Source software...
postfix (www.postfix.org),
amavisd-new (http://www.ijs.si/software/amavisd/),
SpamAssassin (aka "SA") (www.spamassassin.org), and
Razor (http://razor.sourceforge.net)
...to create an anti-spam email relay server. That is, there is no local
mail delivery on this box. All inbound mail is:
- directed to this system,
- SPAM is then filtered out and re-directed to a specified mailbox,
- and the rest is passed on to its original intended recipients...
at a final destination mail server, which is most likely the one you
are currently using to receive mail. Thus, a spam "filter" server.
This setup gives the system administrator control over
spam, removing the need for end user interaction. Yes, you can change
this configuration a bit and bring the end user into the loop, "tagging"
email as *SPAM*, and so forth, but I find that the
less interaction between users and spam, the better! With this setup,
if a user actually misses receiving an intended
email, it is easy for you to find it and forward it
on to them. It will be sitting in the quarantine area you have
configured.
This system will work well when placed between a firewall and an
internal, office mail server. If you don't have a firewall (eek!) then
this box is at your Internet edge, and is sort of an email firewall in
any case. Although the design goal here is to
simply filter and control spam originating from the Internet, the
configuration could be modified to include scanning emails for virus
content. The "amavisd-new" program was in fact originally written
to be an interface between a mail server and various anti-virus
packages. Local delivery of mail on this box could also be
configured, if desired.
In my case, an anti-spam tool was needed in front of a Microsoft
Exchange server, and this setup fits the bill nicely. Scanning
outbound mail for spam content was not needed in my case, so my
outbound mail runs directly from the internal Exchange mail server to
the Internet, without passing through this spamfilter system. This too,
of course, may be modified.
So... some of MY reasons for setting up a spamfilter in this way are:
-we already have an Exchange server and will not be getting rid of it
-we don't want to spend $$ on spam software (most of what I've seen for
$$ hasn't been too impressive, anyway. This multi-component system is
equal to or beats out most commercial anti-spam software packages I've
seen!)
-to protect our Exchange server (a "buffer" between the bad guys and
our internal mail system - no inbound connections to Exchange from the
Internet. This protects, for instance, against such things as smtp auth
attacks, such as described
here
)
-to spread the CPU load (spamfilter does the spam scanning, Exchange
the AV and delivery)
-to be able to take the Exchange server down and Internet emails will
still come in and be stored, waiting, on the spamfilter, until the mail
server is back online
***You can always click HERE for
the most current version of this document.
Notes: (or, "There's a few things you need to understand before
we go any further!")
1. This is not a "standard" Linux HOWTO doc. It is written with
more detail, step-by-step, so that anyone with even the most basic
understanding of Linux and computers can set it up. Apologies to
experienced administrators, just wade through.
:)
2. Complete install as per this doc will require less than 2GB of
disk space. The system will additionally need whatever amount required for
temporary mail storage, as email is spooling through, which depends on
your email traffic flow, and I can't hope to estimate that for you. It
is not a huge amount, however -- the mail won't generally stay on
this system long, before it is off to its final destination.
3. This entire procedure will take an experienced administrator
about 3-6 hours. A newbie twice as much or *MORE*.
4. This doc will not cover hardware problems. It assumes you have
Linux compatible i386 hardware, including one NIC (network interface
card).
5. You'll need to know the IP address, netmask, and other IP
configuration details to be used on this box, before you begin. I
won't be helping you with that.
6. You don't *NEED* a GUI interface/desktop like X Window and
Gnome or KDE, etc., to build this system, and when we're all done
building this, you probably won't normally run it. Most experienced
*nix admins will forego an X Window system altogether, on a server.
Newbies, however, will appreciate that these instructions allow for
using a grahpical web browser to download software, rather than ftp
and lynx, for example. This is more comfortable for those who are
used to a Windows or Mac environment. In any case, suit yourself.
7. My instructions list using the "vi" text editor to edit text
files. If you are more familiar with another text editor, feel free to
use that. If you are used to a Windows environment, vi will seem
difficult at first, but I will explain the basic commands you need to
get things done. Be brave, you'll be fine, and when you're done,
you'll be a little comfortable with the most common text editor in the
*nix world. Not a bad idea - since it's on every *nix machine.
8. In this doc, "domain1.com" and "domain2.com" will be the
fictitious example domains we'll be receiving mail for. You can
receive mail for as many domains as you like with this system. Our
example spamfilter mail server will have a host name of
"spamfilter.domain1.com".
9. An Internet connection is required during the build, for
downloading some of the software we need.
10. I'm sure there are numerous ways this doc and/or the methods
used here, and some of the particular software selections, etc., could
be improved. Please email suggestions to scottlhenderson-at-yahoo.com.
Thanks.
Benchmarking:
I do not have benchmarking data for high-end
use, such as at very large companies or ISPs, but I am aware of
several small ISPs that currently run this configuration. The software
components in this doc are all designed for high capacity and I
would expect them to scale up very well. The 2 main executable
programs used herein, postfix and amavis, both have configurable
throttling and performance settings. They are also mature products,
with a proven track record and a large following of users.
This particular configuration uses Red Hat version 9.0 as the OS. But
there are folks who have successfully set this up on Debian, Mandrake,
*BSD, etc. If you run this on other Linux or BSD distributions
- or whatever - PLEASE do take a minute to email and let me know your
experiences. Thanks!
... scottlhenderson-at-yahoo.com
--OK, Let's Go!
RED HAT INSTALLATION:
(As we start, let's not have the Ethernet cable connected until we need
it. We're starting with a clean box -- we'll try to keep it that way!)
| -insert Fedora install CD, power up |
-if Fedora install program doesn't launch from CD, either get into your computer's
BIOS and tell it to boot from CDs, or use a Fedora boot/install disk to boot up,
and choose CD installation
|
First screen, just hit Enter
|
(we'll use the graphical install
program)
| If you get a "CD Found" window, hit Enter if you have doubts
about the integrity of the CD you're using to install. Otherwise,
hit "Skip" and go to the next screen.
|
(Use the arrow keys to move the
selection option.)
| on the "Welcome" screen, just hit Enter
|
| select appropriate language prefs, keyboard, mouse, on the next few
screens
|
| Install Type screen: choose Custom install
|
If the disk contains a existing installation you will see the following screen:
| Choose the "Install Fedora Core" option |
Disk Partitioning screen:
| Partition disks as appropriate. I recommend following the
suggestions listed below.
|
In my opinion, its best to select the
option to manually partition with Disk Druid, then set up partitions
as appropriate on the next screen, similar to what is listed
below. If you have NO concept of what disk partitions are, or are
scared :), just select "Have the installer automatically partition
for you". It will work fine. You CAN go forward and TRY to
partition, and if you have problems, you can always hit the "Back"
button and have it auto-partition for you then, too. Isn't Linux
user-friendly?
"Unix is very user-friendly. It's just picky about who its friends
are."
Suggestions for manual disk partitioning with Disk Druid:
(If you are suspicious of the quality of your disk(s), or you just want
to be VERY careful, then as you create each partition, select the
option to "Check for bad blocks" and the partition will be tested for
integrity. And any little sections (called "blocks") on the disk
that don't read/write correctly will be marked as "off bounds" by the
system. Its not a bad idea, but it will add a good chunk of time, and,
kind of like insurance, doesn't do you any good most of the time.
:)
-In Disk Druid, select ("highlight") free space on your disk, then
click to create a NEW partition to mount at /boot |
, make
it type ext3 (the default), make it 100MB, check the option box to
force it to be a primary partition.
This will hold your system boot files, and your kernel. So it's kind
of important, right? That's why we like to keep it on a partition
separate from everything else. It doesn't need much room though.
-highlight the free space again and create a NEW partition mounted at
/ (called "root") and make it type ext3,
primary also, and give it at least 3000MB. This will be for a large
chunk of the main system configuration files (like those in /etc),
and also primary software packages, like those in /bin and /sbin.
Don't waste disk space giving it 10GB or something. 3-4GB is
plenty, unless you go installing everything on the CDs.
-create a partition and choose "swap" as the file system type. You don't
list a mount point for a swap partition. Size? as appropriate for your
machine, that is: at least as much as RAM you have (Yoda-speak
there, sorry). You can go twice RAM if you want, but if you have lots
of RAM on this machine, don't bother going over 1 GB or so for a
swap. You'll never need it, and it will just become like that
proverbial 90% of your brain you don't use.
-create one to mount at /var/log |
, type ext3. This will
hold the system log files. 1000MB will easily handle all logging at
a 50,000 emails per week rate and have plenty of room to spare (note:
this system will roll over logs automatically and delete them after
they are beyond 4 weeks old - that's configurable, of course.)
-make a partition to mount at /var/spool |
, type ext3. If
you want, you can select the option to allow this partition to use all
the remaining space on the disk. This partition will be the temporary
holding space for emails coming through, and those waiting in queue
for delivery. It should be at least a couple of GB, unless you have a
very small operation. Remember, it must be at least larger than any
single email you intend to allow in the door! I will also say that,
personally, if I have a machine with the room, I like to leave as much
free space on the box, as on all the above partitions, so that I can
later come back and mirror the system to itself, creating a redundant
copy, for fast disaster recovery in certain situations. This is
advanced stuff, though! For those interested, I have outlined the
technique I use for this HERE.
If you want to consider doing that, just leave sufficient free space on
the disk for it now.
| So, here's a table of how these partitions might be set up. Yours
might look a little different, for instance if you have a another type
of disk (like ide), more RAM, things may be in a different order, etc. Also
note partition 4 will appear automagically - that's your extended partition.
|
Partition Mount Pt FS Size Type Bootable
|
/dev/sda1 /boot ext3 100MB primary *
|
/dev/sda2 / ext3 3000MB primary
|
/dev/sda3 swap swap 512MB
|
/dev/sda4 extended
|
/dev/sda5 /var/log ext3 1000MB
|
/dev/sda6 /var/spool ext3 3000MB
|
*The system will format any newly created partitions.
| WRITE DOWN YOUR PARTITION INFO SOMEWHERE FOR PERMANENT RECORD !!!
|
All RIGHTY then, moving on...
| We'll use the default GRUB ("Grand Unified Boot Loader")
as our bootloader, installed on the MBR
|
(MBR = "Master Boot
Record" - where the box looks first to find an OS or loader of some
kind). You can just leave the defaults on the "Boot Loader
Configuration" screen, except:
| I'd recommend putting in a
"Bootloader password".
|
Make it a fairly long and ugly thing, and
write it down and keep it somewhere safe.
| Network Config: Click on "Edit", then uncheck "Configure using DHCP", but leave on "Activate at boot"
|
| Set up remaining network parameters as appropriate
|
(again, I'm not helping
you with this - you'll need to know what values you want to use here.)
| for hostname, use an FQDN
|
("Fully Qualified Domain Name"), something like "spamfilter.domain1.com"
| Firewall Config screen: (make your own decisions here, if you
know what you're doing, but I'll recommend using it, set as per below:
|
-"Enable firewall", then
- check the boxes for SSH, and Mail (SMTP)
-Add in one more in "Other Ports": 123:udp (NTP)
(that's Network Time Protocol - what we'll use to make sure the box keeps good
time by checking with Internet time servers)
see a screenshot here Firewall
| on the next screens, choose Language, Time Zone
|
as appropriate (Note:
language here is what language you want the box to speak to you when
you log into it. So you might want to select any languages your
admins use. This all has nothing to do with what language characters
may or may not be used in emails.)
| Enter a password for the root user on the next screen
|
(aka the
"superuser"). This should be your best shot at a really unguessable,
unbreakable password. Use no words from any language, and no names.
Put in mixed case, numbers, and symbols. Bad passwords would be like
this: "!IthinkThisIsGood!" or "Fred_und_Olga847773". A good
password is like "hU4$gT8mzR#!42kuB". You know the drill - make it
the first letters of a phrase or something. Make it weird. This is
the golden key. Write it down and keep it very safe! (and be a
[Wo]Man: don't use the same thing as for the GRUB "bootloader"
password :)
| don't forget to WRITE IT DOWN and KEEP IT SOMEWHERE SAFE!
|
CHOOSING SOFTWARE "Package Groups":
This installation will include a GUI, but please understand that it
is not necessary in any way (or even particularly helpful in running a
server like this). Experienced Linux admins won't usually install
it. I'm including it in this configuration for the comfort of those
who are a little newer to the Linux world. You will not normally
run it after we finish with the installation and setup. But it
will be on the machine, and you can fire it up any time you want, and
have a nice graphical desktop, just like a Mac, or one of those other
graphical-focused operating systems. ;-)
OK, for the packages:
| Leave all the default packages, except for the below: |
| Select either Gnome or KDE Desktop environment, according to your preference
(If you don't know, just leave the default, "Gnome" - then click on "Details"
and deselect all the Gnome "Optional Packages" except "eog" and "gnome-vfs2-extras")
|
| De-select "Editors". |
| Select "Text-based Internet", go to details and deselect
everything except elinks , screenshot here |
| De-select 'Office/Productivity', 'Sound and Video' and 'Graphics' |
| Select Server Configuration Tools |
| (And yes, that's right - DON'T select "Mail Server" here! Postfix and
SpamAssassin are both available on your CDs, but we'll add them later, and
use more current versions) |
| Select Development Tools, then Administration Tools |
| De-select Printing Support |
Of course, you can choose to add other software as
you see fit. This list is not set in stone, and I am not
experienced with every program. Consult an experienced Linux
administrator to improve on these selections, or just if you'd like
to have some lively discussion. :-)
-hit "Next" and RH install will check to make sure you have not
selected any programs without also selecting appropriate required,
dependent software.
-Unresolved Dependencies? (gasp!) If you made the selections
exactly as per the above, you should NOT see next an "Unresolved
Dependencies" screen - if you do, don't freak. You can do one of 3
things:
1- review the list on the "Unresolved Dependencies" screen to
determine what you did different and hit the "Back" button to make
changes
2- check "Install packages that have dependencies" if you have
added packages you want, and want RH to make sure all required
dependent software is installed
3- use the 3rd option, if you know what you are doing
:)
| "About to Install" screen: hit Next and let the install run,
inserting additional CDs when prompted
|
-label a blank floppy with "RH 9 BOOTDISK" and the machine
name and date. Insert this floppy to
| Create the boot disk when it prompts for it
|
|
turn on the floppy's write protection tab
|
-remove CDs and floppies and
Screenshot
(The first reboot takes a while, be patient...)
Now you start up in the "Welcome Screen" of the Setup Agent
| hit Enter |
| Select "Yes I agree to the License Agreement" |
| hit Next |
| Now set date and time |
| tick "Enable Network Time Protocol" |
| Select NTP-server (write a server name e.g. "ntp1.tele.dk") |
| hit Next |
| |
| In the next screen, add a personal account |
| hit Next |
| In the "Additional CD's" screen, |
| hit Next |
| In the "Finish Setup" screen |
| hit Next |
POST-INSTALL RED HAT CONFIGURATION
(if the system doesn't boot from the HD, use your boot floppy here)
The system now boots into a graphical screen login, we will change this to a
text screen login as default.
| Press the key combination Alt-Ctrl-F1 |
...and enter root's password.
Use the command
use the down-arrow key to go to the following line:
id:5:initdefault:
use the right-arrow key to put the cursor on top of '5'
| Press the key 'r' followed by a '3' |
this will replace the 5 with a 3.
| Press the key ':' followed by a 'wq' to save the file and exit the
editor |
| Type 'reboot' and press enter |
-You should come to a plain, text screen login.
...and enter root's password.
-First, we'll set uneeded daemons ("services" in Windowspeak) to NOT
load at boot:
Use the command(s):
"chkconfig daemon off", with each of the following
daemons:
|
| sendmail (MTA not to be used)
apmd
cups (print server)
(You can use the up arrow to repeat the last command, then edit it)
isdn (you can guess that)
kudzu (finds new Plug-n-Play hardware at boot)
netfs (part of the network file system)
nfslock (another part of nfs)
pcmcia (assuming you don't need that on a server)
portmap (for RPC)
xinetd (a daemon that launches other daemons)
|
So, for instance, you'd use:
chkconfig apmd off |
then:
chkconfig cups off |
-Lather, rinse, repeat.
Now, to get rid of sendmail, we will have to reboot
| Type 'reboot' and press enter |
-You should come to a plain, text screen login.
...and enter root's password.
Creating additional required accounts & groups:
-Now make a copy of the passwd and group files, before you do anything
to them, just in case you make a mistake somewhere, like this:
cp /etc/passwd /etc/passwd-original |
cp /etc/group /etc/group-original |
-Now we'll create some users and accounts we'll need, including an
account for yourself (I'll pretend your name is "admin1" for now), and
also for each admin who will need to login to this box. Each of these
commands goes on a single command line (ignore if its too long and
wraps when you type it, just keep going), and is CasE SenSitiVe (like
all Linux commands). Also, any quotation marks "" should be used, not
ignored.
groupadd -g 888 postdrop |
useradd -d /var/amavis -c "amavisd-new daemon" -u
999 -s /sbin/nologin amavis |
Now we also need to set proper ownership and permissions on the
/var/amavis "home" directory we just created:
chown amavis:amavis /var/amavis |
chmod 750 /var/amavis |
Then, create administrator accounts:
useradd admin1 |
useradd anotheradmin... |
...etc., if you have more admins to create accounts for, make as many as
you need. And you do want
an account for each, for accountability. They will always log in as
themselves, then "su" to root (explained later) to administer the
machine. This is a "best practice"!
-Give yourself a password:
This will prompt you for the password. Put in whatever you want for
admin1's password. You can go ahead and set up initial passwords for
the other admins now if you want.
-We need to make an account for postfix to use, also, but we'll do this
in a slightly different way, to be able to reference a non-existent
home folder (I won't take the time to explain this now). Make sure to
type this command EXACTLY as it appears here, on one line (i.e.,
ignore if it wraps while you are typing it):
echo "postfix:*:887:887:Postfix:/no/where:/no/shell"
>> /etc/passwd |
GPG: "GNU Privacy Guard"
We want any software - that we don't get directly off our Red Hat
CDs - to be verified as the correct, unhacked versions. GPG (the GPL
counterpart to PGP) is a tool that will help us with this. It's
already on your box, now we'll configure it. I won't explain GPG in
detail, just read "man gpg" and/or visit http://www.gnupg.org when
you're ready to learn more. For now:
-To generate your own key:
-Then
to accept the defaults, then answer
(yes) on
"no key expiration".
| Give "spamfilter" when prompted for "Real Name"
|
and a real
| email address you monitor
|
when prompted for email address.
(like postmaster@domain1.com or something)
| Put nothing or whatever you want in the Comment field
|
| then respond with "O"
|
(that's the letter, not the number) for "OK", if all is
correct.
twice (yes, write it down!!) and then
| type garbage on the keyboard to provide random data
|
to the gpg program, to create a key.
-Next, create a revocation certificate. The command (all on one line
now!):
gpg --output revoke-spamfilter.asc --gen-revoke
postmaster@domain1.com |
(Replace "postmaster@domain1.com" with what you used for the email
address for this key)
-Then answer:
to create a revocation certificate, then
(zero) for
"no reason specified",
| then hit Enter (no description)
|
and
to "Is this OK?"
Good job. Write down all your gpg details. We'll come back and USE gpg a bit
later!
DOWNLOADING, VERIFYING, AND INSTALLING POSTFIX
-start the GUI desktop:
The following instructions assume you're in the Gnome desktop.
Modify as appropriate if you are running KDE or something else.
First, let's make a shortcut to launch terminal windows. Right-click
on the launcher/Task bar (between the envelope and printer icons, and
select "Add to Panel", then "Launcher
from Menu", then "System Tools", then "Terminal".
| Launch the Mozilla web browser (first launch will be slow)
|
...from the blue-green globe icon on the Launcher Bar.
-maximize the browser and
| go to www.postfix.org, click on "Download" and choose a site near you.
|
|
Right-click on "Wietse's PGP Key"
|
(Venema Wietse is the author and maintainer of
postfix). Choose to
to save this gem to your home
folder. We'll use this key not only to verify today's download of the
postfix software, but also any future download of updates, etc. from
the postfix site. Now close that annoying "Download Manager" thingy.
| Now get the ...tar.gz ("tar ball")
for the latest stable version of postfix. The link may say "Source Code"
|
Again, you'll right-click, "Save Link Target As" and save to the same place.
The file name will be like "postfix-2.0.16.tar.gz (at the time of this
writing). Your numbers may vary. Save the postfix tarball to your home folder.
| Likewise, download the corresponding PGP sig file (...tar.gz.sig)
|
-After all that is downloaded,
-Open a terminal window (hint: use the shortcut you just created,
silly!). Then:
*Astute newbies will note here that GPG is capable of working with
PGP keys, as well as GPG keys.
-Next, note the email address listed from the output of the above
command. We'll need to use it to sign the PGP key we got from the
postfix site:
gpg --edit-key wietse@porcupine.org |
-At the "Command>" prompt, type:
At "Really sign all user IDs?" type:
| At the next prompt, just hit Enter
|
at the next one, type another
Then
| Enter your GPG passphrase
|
then enter a
...then a
to save the changes and exit.
Verifying the postfix tar ball
-Now let's see if the postfix software we just downloaded is
legitimate, according to GPG:
gpg --verify postfix-#.#.#.tar.gz.sig postfix-#.#.#.tar.gz
|
*Replace the "#.#.#" above with the actual numbers/letters for the
version you are working with.
If you don't get a "Good signature from Wietse Venema ... blah
...blah", from the above command, then you have a problem. Perhaps
you have a corrupted (or hacked!) piece of software. Don't go forward
until you have a tarball that produces a correct GPG report.
You DO know the *nix trick for completing long file and
folder names, right? If not, you're fingers will get very tired. If
you type the first part of a file or folder name, like: "post", and
then hit the tab key, Linux will fill in the rest, up to the point
where more than one option exists. So for the above command, for
instance, I would type "gpg --verify pos" and then hit the tab key.
The system would fill in with "postfix-#.#.#.tar.gz". I can then type
the ".sig" that goes on the end, then a space and "pos" again, and hit
the tab key again. It will once again fill in the remaining name.
Play with this. It's extremely handy. There are other command line
shortcuts you will want to learn.
Postfix Installation
-And enough of working in the GUI! I can't take it anymore. Let's go
back to the clean, clear text interface... Logout of X please...
Ahhh, much better! :) OK, let's put the
downloaded software in a better place, and go there to work on it:
mv postfix-#.#.#.tar.gz /usr/local/src |
cd /usr/local/src |
-Now we'll "untar" it (uncompressing it in the process):
tar xzvf postfix-#.#.#.tar.gz |
And go into the new directory this created:
-Next, we build the program, with this simple command:
(This will take quite a while...)
-And now we install it:
You will then be prompted for several options. Just
| hit Enter to accept the defaults for all of the options
|
When the installation is done, you can delete the tar ball, so it
doesn't waste space on your disk:
cd .. |
rm -f postfix-#.#.#.tar.gz |
Now is a good time for a
I recommend a double, skinny, no-foam hazelnut Latte, actually.
Postfix Configuration
-Start by making a backup of the postfix config files:
cd /etc |
mkdir original-postfix |
cp -Rp postfix/* original-postfix/ |
CHROOT for Postfix, and preparing for filtering: changes to master.cf
First, some background... We want to take advantage of
the fact the Postfix's author, Wieste
Venema, who is very concerned with creating secure code, designed
postfix to be able to run most of its functions in a "chroot"
environment.
(To understand chroot better, read up on it: "man chroot
" or "info chroot". A short explanation
would be: A chroot is a
contained, restricted area of the filesystem within which a program
is allowed to run, for better security. This is sometimes called its
"jail". The idea is if someone were
to hack into a program or get it to do something out of the ordinary, the
limited area of control reduces the damage that could be done.)
In the case of postfix specifically, the program will be limited to
/var/spool/postfix, and any directories below that. This
means it must have
everything it needs there. Wieste has kindly created scripts which will
do some of the work for us. We'll use one
of those scripts, named "LINUX2", which will set up the initial environment,
then we'll edit postfix's "master.cf" file, to tell postfix to use
the chroot environment. Note that one of the things it will do here is
copy the files resolv.conf and hosts from
/etc/ and place copies of these into the folder
/var/spool/postfix/etc/. Postfix will thereafter look to
the copies in its chrooted environment for these. Thus, if you make any
changes to your machine's network config, like editing these files, make
sure you change them in both places.
-Here are the commands: (Don't forget to be careful and use correct
capitalization!)
postfix start |
cd /usr/local/src/postfix-#.#.#/examples/chroot-setup
|
chmod +x LINUX2 |
./LINUX2 |
postfix stop |
cd /etc/postfix |
vi master.cf |
Now we're in the file master.cf, using the "vi" editor. Use the PgDn
and PgUp and up and down arrow keys to move around in the file. Read
the commentary at the beginning, it will only take a minute. You may
not understand all of it, that's fine. When you get down to the
table, you will see a column with the heading "chroot (yes)". Use
the arrow keys to put your cursor right at the chroot column for the
first row, which is "smtp". Hit an "i" on the keyboard. You'll see
the word "INSERT" appear at the bottom of the screen. You are now in
INSERT mode. This is pretty much like any ordinary text editor program
at this point. Don't start just yet, but you can use the arrow keys
to move around, you can type characters, use the Del and Backspace
keys for their normal functions, etc. What you want to do is to
| replace the "n" in the chroot column with a "y", in each row,
except for rows that have "proxymap", "local", "virtual", or "pipe" in
the LAST column
|
Next, we want to give postfix some information it will need to talk to
the amavis
filter program. (BTW, watch out for the two postfix configuration files, both
located in the /etc/postfix folder. More than one admin has gotten confused
between "master.cf" and "main.cf"!)
|
Add these lines right after the table. Note: the items on these lines are
separated by tabs, created with (none other than) the "tab" key. And the "-o"
is the lower case letter o, not zero:
|
smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
|
When you are all done, the table and the lines right after it should end up
looking like this:
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - y - - smtpd
#628 inet n - n - - qmqpd
pickup fifo n - y 60 1 pickup
cleanup unix n - y - 0 cleanup
qmgr fifo n - y 300 1 qmgr
#qmgr fifo n - n 300 1 nqmgr
rewrite unix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
flush unix n - y 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - y - - smtp
relay unix - - y - - smtp
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - y - - showq
error unix - - y - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - y - - lmtp
smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
(Don't worry about the stuff below this part displayed above - you won't
need to change any of those rows, and they are all listed as "pipe" in the last
column.) When you're done editing master.cf, you can
| save your changes and exit
|
by hitting the "Esc" key, then typing:
:wq |
...and then hitting the Enter key. That's right, you'll hit the "Escape" key,
then type in a colon, then a lower case w, then a q. To vi, this means:
Esc = leave INSERT mode and return to command mode
: = here comes the command(s)
w = write this file to disk ("i.e., save my changes")
q = quit vi
Send all of root's mail to someone
In order to follow good security guidelines, we want to avoid logging in
as root - unless necessary - so let's not force a root login just to check
root's mail; let's send it somewhere else. To do this, we'll edit a file
postfix uses to redirect mail to aliases. Amazingly enough, the file
is called "aliases":
Near the top of the file you will see a line like this:
#root: you |
-Remove the leading "#" symbol, and replace the word "you" with the email
address for an administrative mailbox that you will plan to monitor. You
can create one on your internal mail server just for this, if you like.
Name it "root@domain1.com" or "spamfilter@domain1.com" - or whatever makes
sense to you. This will be where all email addressed to "root" on this box
will go. Mostly that will be automated reports and stuff, and some alerts.
(Like everything else we'll do, you can always change this later.) When you
are done with this,
| what was:
|
#root: you
|
|
will be changed to:
|
root: spamfilter@domain1.com
|
(or something similar)
Now we tell postfix where to look for its "aliases" file (for some
reason it defaults to /etc/aliases, which is the default sendmail
location for this file, so we change it):
postconf -e "alias_database = hash:/etc/postfix/aliases"
|
Then we'll create from the text version of the aliases file, the "hash"
version that postfix will actually use (note: any time you edit the
aliases file, you'll need to run this command again):
You will see now there is an "aliases.db" file in /etc/postfix/. That is
what postfix reads.
Starting Postfix automatically, at boot time
OK, you'll want a nice intialization script to start postfix at boot. I'll
give you one that you can use, and show you how to use a text web browser
while we're at it. The browser is w3m. If you've ever used the old tried
and true lynx browser (I'm showing my age here), you'll find w3m very much
like it, but with some extra features. Worthy of checking out.
Captain, we're going out...
Enter the command:
elinks www.geocities.com/scottlhenderson/postfix-startup-script.txt
|
(If you mistype the address you'll get an error page of one kind or another, depending
on exactly what you mistyped. Just hit a "q" and then a "y" to quit elinks. Then
when you're back on the command line, you can hit the up arrow to see the last
command, use the left and right arrow keys to go in and edit your mistake, and
then try again.)
When you have the page in the browser (you'll see the beginnings of a script
file, with the top line being:
#!/bin/sh
and a title line near the top that reads:
# postfix Postfix Mail Transfer Agent - Init Script
Then:
| type an "Esc" |
| select 'file' in the menu |
| type an "v" - lowercase that is |
and you'll get a prompt asking you
where you want to save the buffer (i.e., the data currently being displayed).
| Type in: |
/etc/init.d/postfix |
| hit enter |
Which will save this page to that file name, then
| hit a "q" and then a "y" to quit elinks |
| Unplug the Ethernet cable
|
Let's make this new file that you just downloaded executable:
chmod 0755 /etc/init.d/postfix |
Now we'll create the necessary symbolic links to this initialization script.
(Symbolic links, if you don't know, are almost identical to Windows
"shortcuts". They are often called "sym links", or just "links".)
Perhaps
you noticed in the script file the line that contained "# chkconfig: 345 80 30"
followed by some additional commented lines following the same construct:
"# attribute: value". This is our old friend, chkconfig (of course, see
"man chkconfig" to learn...). The text "# chkconfig 345 80 30" means turn
this (postfix) "on" for run levels 3, 4, and 5, and make the start sequence
value 80 and the stop sequence number 30. Now, we'll be starting our
spamfilter server in run level 3, so postfix will start then. If we switch
to level 5 (X Window GUI), it will still run. All this is good. (No time
to explain run levels here, sorry. If you don't understand, let's just go
on, you can research that on your own, later.)
Chkconfig can also create our startup links
(i.e., the sym links that go into the /etc/rc.d/rc#.d directories in a
System V style of *nix, such as we have. Don't understand that? Just
do a web search on "System V initialization" and read to your heart's
content. Soon you'll be able to techno-babble such nonsense that no one
will be able to understand you.) For now, however, just do this:
(Hey - there's TWO dashes in front of "add" there!)
Voila! The requisite links for postfix startup are in place.
Set up asynchronous logging for Postfix:
We can improve the logging performance for mail activities (and logging mail
activities can be a busy, busy business!) by making it asynchronous.
For info on what this means, read the file
/usr/local/src/postfix-#.#.#/README_FILES/LINUX_README. We will turn on
asynchronous logging by editing syslogd.conf. First, backup the file:
cp /etc/syslog.conf /etc/syslog.conf-original |
-Then, to edit:
|
Scroll to the line that has:
|
mail.* /var/log/maillog
|
Hit "i" to begin editing, and
type a single dash "-" directly in front of
/var/log/maillog
|
When you're done, the line should look like this:
|
mail.* -/var/log/maillog |
| exit vi
|
...by hitting the Esc key, then typing
:wq
...and hitting Enter.
(again, the standard vi "write and quit" exit)
Postfix Configuration
Our next friend is the file /etc/postfix/main.cf --
the main configuration file for postfix. Following are suggested values to
use in main.cf. These have been tested
for this configuration and will work fine, but there are many judgement calls
involved in this, and it is a good idea at some point to learn more about
postfix configuration, on your own. You could first go to the main.cf document
itself. There are copious comments describing may of the available options.
Refer also to the postfix documents on your machine in
/usr/local/src/postfix-#.#.#/README_FILES, and of course, visit the postfix
web site.
Rather than editing main.cf directly (which you may nonetheless do, if you
prefer) we'll use a handy tool that comes with postfix, named "postconf".
With the -e switch, it will mean to "edit" main.cf.
(*Note: in commands, wherever quote marks " " are used, USE THEM!!
:)
myorigin - domain mail from this machine appears to come from.
postconf -e "myorigin = domain1.com"
|
Obviously, in the above, and all the following commands, replace my example
parameters, like "domain1.com", with your own specific values.
myhostname - the fully-qualified domain name ("FQDN") of the
machine running the Postfix system.
postconf -e "myhostname = spamfilter.domain1.com"
|
mydestination - specifies for which domains this machine
will accept mail (from the outside, i.e., from the Internet). You
want to list here ONLY domains that you are responsible for which you are
responsible for accepting mail. Separate them with commas.
postconf -e "mydestination = domain1.com, domain2.com"
|
...don't forget to change to your value(s)!!
mynetworks - the machines I trust, and will relay mail for,
to any destination. Generally, this is set to my LAN, or just one, or a few
trusted internal mail servers. This is an important one
to get right,
or else you can become an "open relay". In other
words, your box could accept and forward mail to domains for which it has
no business doing so. Being an "open relay" is a serious issue, and can
cause you to get "blacklisted" by various Internet anti-spam lists, among
other problems.
postconf -e "mynetworks = x.x.x.x/32"
|
(where x.x.x.x is the IP address of a specific machine)
If you will be dealing with multiple internal mail
servers, and/or want to allow several machines and/or subnets to relay
through this server (carefull!!), just add them to this parameter in
CIDR format, like this:
|
Alternate to the last command:
|
postconf -e "mynetworks = 172.20.32.5/32, 10.0.0.0/16, 172.20.16.0/8"
|
(the above will allow the machine 172.20.32.5, and any machines that have
an IP address starting with 10.0, or 172.20.16, to relay smtp mail
through this box)
biff - we won't use biff notifications (don't ask)
smtpd_banner - what this server calls itself, when talking with
other mail servers (keep identification info to a minimum, but
conform to RFCs.). If you want to respect other mail servers that require
a valid reverse-lookup address for all connecting mail servers, use a
hostname that has a reverse lookup on the Net!
postconf -e "smtpd_banner = mail.domain1.com"
|
message_size_limit - maximum size email that postfix will let in the
"front door"
postconf -e "message_size_limit = 1000000000"
|
(The above allows emails up to 1GB)
local_transport - give an error message for local delivery attempts.
postconf -e "local_transport = no local mail delivery"
|
local_recipient_maps - don't try to determine valid email recipients
In our situation, the postfix server will have no idea if we have a
bob@domain1.com or a jsmith@domain2.com, etc. It doesn't have any such
lists to check against! We
could fix this, but it is far easier to just ignore this problem. If
mail comes in to a recipient that I don't have, postfix will process it and
transport it on to the internal mail server, which will promptly reject it
and will attempt to do the NDR (non-delivery report) to the stated sender
email address. There are other potential solutions here, but I will only
cover this simple configuration, which works fine. So we'll just set this
value to nothing:
postconf -e "local_recipient_maps = "
|
transport_maps - tells postfix where to look for a transport file.
That tells it where to forward valid mail for our internal domains. Our file
will be /etc/postfix/transport. (No, postfix admins, we won't use the
"relay_domains" parameter for this - see the problem described at
http://www.postfix.org/faq.html#firewall if you need details. Also the
section just above in that web page discusses using a transport table.)
postconf -e "transport_maps = hash:/etc/postfix/transport"
|
/etc/postfix/transport - now we'll leave the main.cf file for a bit
and go to the file we just mentioned above: the "transport" file, which is what
postfix will check for redirection or relaying of mail addressed to particular
domains. In our case, all inbound mail will be relayed on to other mail
servers:
vi /etc/postfix/transport
|
|
(and edit file as per below:)
|
Read the text in this doc as you please, to understand better, then
scroll down to the bottom of the file (actually doesn't make any difference
WHERE in the file you do this):
|
add 1 new line for each domain for which you will be handling mail,
similar to the example below
|
(but of course replace domain#.com with your domain(s) and x.x.x.x and
y.y.y.y with the IP address of the mail server(s) that are the final
destination(s) for their respective domains) - like this (remember, use
the key "i" to begin inserting in vi):
domain1.com smtp:[x.x.x.x]
|
domain2.com smtp:[y.y.y.y]
|
|
(DO include the brackets on these lines!)
|
*These lines tell postfix to transport any mail addressed to recipients in
domain#.com to the mail servers at the IP address(es) specified (i.e. your
internal mail server(s), using the smtp protocol. The format is exacting,
get every symbol correct and leave some white space between the domains
and the "smtp" part.
-Use the regular "Esc", then the :wq sequence to
*Note: any time you make a change to this file, you must create a special
version of it for postfix to read, by running the postmap command (postfix
doesn't actually read the text version we work in, it makes another, faster
file for its use):
postmap /etc/postfix/transport
|
Postfix anti-SPAM settings
Preliminary Notes:
The values below help ward off SPAM by means of postfix configuration.
These will cause emails to
be rejected by postfix right at the "front door", so to speak, without
even having them scanned by Spamassassin ("SA"), or other systems deeper
within your mail processing system. This is good and bad. It saves system
resources, but it also doesn't let you SEE the bounced mail. All you will
see is a log entry or two from
postfix saying essentially "Hey, a mail server named "xxxxxxxx" at IP address
X.X.X.X tried to send some mail in, but it broke rule XYZ, so I bounced
it". Now this could have been SPAM -- spammers often intentionally don't
follow RFCs in order to accomplish their goals. But if it was a "legitimate"
mail -- say from a customer who's IT Department has simply misconfigured their
mail server (extremely common)-- you could have some ruffled feathers
to deal with!
If you want to allow ALL email to come in the front door,
and configure SpamAssassin / Amavisd to scan and handle all SPAM control
within the system, you would need to modify some of the settings below.
I personally find a combination of postfix and SA anti-SPAM control to
be best.
If you want to go BEYOND the postfix anti-SPAM config I'm setting up here
(and believe me, you can), and/or you want to understand more about these
settings, a super
resource is
Jim Seymour's Postfix Anti-UCE Page (expect to spend an
hour or so reading and understanding all of it!) You will note I use
some of the same settings as he does here, but this configuration is not
nearly as restrictive. But this config also differs from his in the
location of some of the restrictions because I have organized them how I feel
they are most intuitive for the average administrator.
For now, just keep in mind that postfix will not be our only - or even our
primary - anti-spam tool. So we don't need
to try to block everything here. We don't even want to. We'll just try to
slough off a little of the real obvious garbage, junk mail. SpamAssassin
and Amavis will come into the picture in a bit, and will provide us with
even more powerful and configurable options to recognize and manipulate
SPAM.
smtpd_helo_required - make any connecting mail server do a proper
smtp "handshake" and announce it's name. Internet RFCs require this,
so we do too.
postconf -e "smtpd_helo_required = yes"
|
smtpd_helo_restrictions: We'll list 4 items here, but note that one
isn't a "restriction":
permit_mynetworks - allows machines listed for the mynetworks value
to be permitted without question
reject_unauth_pipelining - rejects bulk mailers that
attempt to use pipelining to speed delivery, without checking if it is
supported first (non-RFC, common among spammers)
reject_invalid_hostname - rejects when the client HELO
has a bad hostname syntax.
reject_maps_rbl - reject the request when the reverse DNS lookup
reveals that the network address is listed on an RBL specified in
in the "maps_rbl_domains" parameter (below). RBLs are "Realtime
Blackhole Lists" -- in other words, lists of "badboy" mail servers.
Various organizations run them, many of these are free, some are not
(like mail-abuse.org). I won't explain much about
RBLs here - it's too complicated and they all have their own idiosyncracies.
They are legitimate services, and VERY helpful in beating
SPAM, but also (like many things dealing with spam) somewhat
controversial. I've chosen a few freebies I that think work
well together, but at some point down the road you should definitely
search the Internet on "RBL" and learn more about all of this.
postconf -e "smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_hostname, reject_maps_rbl"
|
(Remember to make commands as one continuous line, and ignore when it
wraps!)
maps_rbl_domains - tells postfix which RBLs to use
postconf -e "maps_rbl_domains = sbl.spamhaus.org,
relays.ordb.org, opm.blitzed.org, dun.dnsrbl.net, spam.dnsrbl.net"
|
*Note: If you want to be just a little more
conservative, but still keep some RBL listing, leave in all the RBLs
above except for the last one, from which I get a few claims from
mail admins who say they have had trouble getting off the dnsrbl list,
even after following their guidelines at
http://www.dnsrbl.com/getremoved.html. I can't verify this,
though, and I do stop a good deal of spam by using this list. Your
option, and you can always change any of this later, of course. Again,
READ about these RBL things, and learn. (later :)
smtpd_sender_restrictions:
reject_non_fqdn_sender - reject when the data in the client
"MAIL FROM:" command does not contain an address in fully-qualified
domain form (e.g. "someone@somedomain.com").
reject_unknown_sender_domain - reject when the sender
mail address has no DNS "A" or "MX" record at all. (The "sender" here is
what the sending mail server gave in the "MAIL FROM:", not the header
"From" line.)
postconf -e "smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain"
|
smtpd_recipient_restrictions: restricts what recipient
addresses this system accepts in "RCPT TO" line (i.e., who the mail says
it is FOR, in the envelope information. Again - NOT from any header "To:"
data).
reject_unauth_destination - Ignore the client hostname. Reject
unless one of the following is true:
1-the resolved destination address matches $relay_domains or a subdomain
thereof, and the address contains no sender-specified routing
(user@elsewhere@domain)
2-any destination that matches $mydestination, $inet_interfaces or
$virtual_maps (we won't be using virtual_maps).
reject_non_fqdn_recipient - reject when the address in the
"RCPT TO:" command is not in fully-qualified domain form.
postconf -e "smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination, reject_non_fqdn_recipient"
|
*Note: restrictions are used in the same order as they appear in
/etc/postfix/main.cf and the first match ends the process.
header_checks - tells postfix where to find a file we'll use to
evaluate header information in emails (like common spam phrases, etc. and
tells postfix what to do with each of these).
postconf -e "header_checks = regexp:/etc/postfix/header_checks"
|
content_filter - here's where we tell postfix to use amavis
postconf -e "content_filter = smtp-amavis:[localhost]:10024"
|
*When you are done issuing all the above commands to set these
main.cf parameters (and in fact ANY time you make changes in either
main.cf or master.cf), issue this command to make postfix immediately
reads its new configuration:
And now:
postconf -n >> /root/postconf.txt
|
This produces a file /root/postconf.txt showing a list of your main postfix
parameters, including any that are not default. Review them CAREFULLY
for correctness. (Use the command: less /root/postconf.txt .
Go back and fix any mistakes. I recommend you print or otherwise save a
separate copy of this info (on a different machine!), as well as each of
the below docs, for future reference.
/etc/postfix/header_checks - this file will list certain
"strings" of text, and tells postfix what to do with mail if it
encounters these in email headers (I'd like to insert a URL here for a
good, brief explanation of what email headers are, and how they are
different from envelope data, if someone knows of one, please
email me! ...SH).
-A sample file is already created for us, with comments explaining
what to put in it. We'll make a copy of that, and then you can edit it:
cp /etc/postfix/sample-regexp-header.cf /etc/postfix/header_checks
|
|
Then, edit this doc as appropriate:
|
vi /etc/postfix/header_checks
|
|
And here's an example of a line you might put in:
|
/^Postmaster@/ OK
|
Note this file requires regexp ("regular expression format"). "regexp" is
something you'll want to learn about in order to live in the *nix world.
Get a book or research it on the Net sometime. For an example of an
elaborate header_checks file from someone with an attitude, take a look
here. But
don't blindly follow this - use your own mind! :)
/etc/postfix/access - this file is another check used by postfix
to control things right at the front door. In this file, we'll list certain
senders/domains/IPaddress ranges for special handling. Below are bogus
examples, create your own as you see fit. This file needs to exist,
because postfix will be looking here and will expect to see SOMETHING.
If you don't have any of these to create right now, just use a made up
one for starters, like the last one in the COMMAND example below. Note
that an "OK" here doesn't mean an email will not be tagged as spam by
amavis a bit further on...
touch /etc/postfix/access
|
(This creates an empty file)
#Example access map file
#
# note: this file only accepts 3 control types:
#
# REJECT
# OK
# [45]XX $message (for specially selected error codes and messages)
ispy99@spamnet.cn 550 Go away
makeabuck@mlm.dom 550 No MLM thanks
allspam.dom 550 Spam is not accepted here
badguy.net REJECT
#250.192 REJECT
#goodguy@somewhere.com OK
justaspamminfool@allspamallthetime.com REJECT
(Of course, any line starting with a # symbol will be ignored by postfix)
*Note: any time you change this file, afterwards you will always:
postmap /etc/postfix/access
|
...to create the special version of it that postfix will use.
END of Postfix anti-SPAM settings...
Remote Administration test:
-This section assumes you don't want to physically go to this box
whenever you want to administer it. If you DO plan to always physically
go to it, you can ignore this section and turn the ssh server on this box
off with this command: chkconfig sshd off |
. Otherwise,
plug in the Ethernet cable, and let's test ssh. On any machine
with an ssh client installed, try a connection to the new server.
(You can use the ssh client from another Linux machine, as most every distro
ships with one, or you can obtain an ssh client for other operating
systems, like Windows and Macintosh. For examples, see here:
Some other SSH Clients.
With a typical client version of ssh, you can test a connection to the
spamfilter like this:
|
From another machine, running an ssh client:
|
ssh -l admin1 x.x.x.x
|
(where x.x.x.x is the IP address of this new server, and "admin1" is your user
name on it. The first time you connect ssh will prompt you asking if you
are sure this is the right machine. Say yes unless you believe terrorists
have already sneaked into your building and have secretly replaced your
spamfilter box with another at the same IP address, when you weren't
looking.)
Next:
then switch to the root account:
Yes the dash is important!
Provide the root password when prompted. That's good, if you got
this far everything is fine. Get out:
exit |
exit |
| Or, if you are in England, use these: |
wayout |
wayout |
| (JUST kidding... :-) |
Red Hat Registration and Updates
-Red Hat has a nice system to keep your machine up to date. You have
to register your machine first. We'll go into the GUI:
startx |
| 1. Click on the "Update" button near the bottom of the screen, just
next to the clock. It is blue with a white 'tick' symbol. This assumes
you are using Gnome |
| 2. Click on the "Register with RHN" button. |
| 3. Acknowledge the "encrypted page" message, if it appears. |
| 4. Click on the link to download the new version of the up2date program.
|
| 5. Click on the "OK" button in the Configuration screen |
| 6. Click on the "Yes" button when asked about PGP |
| 7. In "Redhat Update Agent" click on the "Forward"
button |
| 8. In "Channels" click on the "Forward" button
|
| 9. In "Packages Flagged to be Skipped", tick the selection
"Select All Packages" to ensure everything is updated |
| 10. Click on the "Forward" button |
| 11. In "Available Packages Update", tick the selection "Select
All Packages" to ensure everything is updated |
| 12. Click on the "Forward" button |
| 13. After everything is downloaded, Click on the "Forward"
button |
| 14. After everything is installed, Click on the "Forward"
button |
| 15. Click on the "Finish" button |
| |
| If you get an alert notification, just close it |
*You can go to https://rhn.redhat.com at
any time to view or alter this registration (cookies required on this
site)
RH will update all packages you have on your machine. This will take a
while. Red Hat will not install any software not
already there -- just updates, including bug fixes, security patches,
etc. Sweet! Reboot after. You may have to run this over an evening or
on a weekend. Paid RH subscribers get priority on this service, and
if the wire is too busy it will stop and tell you there isn't enough
bandwidth right now for you, and refer you to a web page where you can
learn about buying a paid subscription ($60/year per box, good
investment, in my humble opinion. See the web site for info.) Of course,
you can also just come back and try this procedure as many times as you like,
later. If for some reason you don't want to use up2date, you can still get
the same updates manually. For details on that, go to
http://www.redhat.com/apps/support/errata .
Download amavisd-new, Spamassassin, and Razor
While we're in the GUI, we'll do some more downloading. I will assume
you can find your way around without point-and-click directions for
this. As time goes on, the versions of these software
packages will continue to be updated. I have noted the versions I used
when preparing this doc. If you get a newer version of something, make
sure to read any "Release Notes" and other documentation that comes with
it so you will know if you need to change some of the procedures from
what I have written for setting this up:
Download all of these to /usr/local/src :
|
| 1. With Mozilla, go to http://sourceforge.net/projects/razor and get
the latest versions of "razor-agents" (I got 2.36) and "razor-agents-sdk"
(I got 2.03). These will be in ...tar.gz "tarball" format.
|
| 2. Go to www.spamassassin.org and download the latest version of
SpamAssassin in tar.gz format (I got 2.60-rc3).
|
| 3. Go to www.ijs.si/software/amavisd, hit "Download" and get the latest
version in tarball format (I got version 20030616-p6). Right-click on the
"md5 sum" right next to it and "Save Link Target as" and put it in /usr/local/src,
too. |
OK, now let's:
We won't be needing the connection for a bit (and until we have the box
better secured, we'll minimize it's exposure).
Installing Razor
We won't need the GUI for this, so you can exit it, or just use a terminal
window. Let's go to our download directory and unpack razor, then compile
and install it:
cd /usr/local/src |
tar xzvf razor-agents-sdk-#.#.tar.gz |
(as always, replace the #.# stuff with the numbers of your version)
cd razor-agents-sdk-#.# |
perl Makefile.PL |
make |
make install |
OK, done with the "sdk" part... now:
cd .. |
tar xzvf razor-agents-#.#.tar.gz |
cd razor-agents-#.# |
perl Makefile.PL |
make |
make test |
make install |
Installing SpamAssassin
First, we need to change a language setting:
vi /etc/sysconfig/i18n |
| Change the "LANG" value from "en_US.UTF-8" to simply "en_US"
|
|
save, and exit vi
|
-reboot the box:
When it is back up, log in as root and:
cd /usr/local/src |
tar xzvf Mail-SpamAssassin-#.#.tar.gz |
cd Mail-SpamAssassin-#.# |
perl Makefile.PL |
|
Here you will be prompted, asking for an email address for "users who
want more information on your filter installation". I'd recommend using
"postmaster@domain1.com" or something similar.
|
|
When prompted asking if you want to run Razor v2 tests you can reply
"y", and if no errors, continue on: (if you get an error about "pod2man"
you don't have the value set right in /etc/sysconfig/i18n - fix it and
reboot again)
|
make |
make install |
"Installing" amavisd-new
Run these commands:
cd .. |
md5sum amavisd-new-#######.tar.gz > my-amavis-md5sum
|
cat my-amavis-md5sum |
cat amavisd-new-########.tar.gz.md5 |
(Make sure you get the "md5" on the end of that last one!)
| Now compare the hash value of the output from the above 2 commands!
|
If the hash values don't match exactly, you have a corrupted or forged
amavisd-new file. Don't use it. Stop, figure out why, and fix it.
Then go on:
tar xzvf amavisd-new-########.tar.gz |
cd amavisd-new-######## |
|
*Note: If you have a version of amavis different than what I mentioned
in the download instructions above,
read the INSTALL file in this directory to see if the instructions for
setting up amavisd-new have changed from what I am describing below.
|
There isn't really an "install" to amavis, you just move two files into
their places:
cp amavisd /usr/local/sbin
|
cp amavisd.conf /etc
|
Configuring amavisd-new
First, make a backup of the amavisd config file:
cp /etc/amavisd.conf /etc/amavisd.conf-original
|
Next, we'll edit this file, but first let me just mention that this file is
a very important part of configuration control in your spam system.
There are many settings in here. I won't cover all of them by any means.
But this file is one of those heavily commented
config files that some hate, others love. I recommend you return and spend
some time reading in here, after this system is all set up, to learn more about just
what you can do with amavisd. But be careful, and always back up before
you change anything!
Locate the line that begins with: $mydomain = 'example.com'
and change the value from:
'example.com' to 'domain1.com'
|
Do I still need to remind people to change my example value "domain1.com" with
the appropriate value? Surely not...
Locate the line that begins with $daemon_user, and change the value
from:
'vscan' to 'amavis'
|
Locate the line that begins with $daemon_group, and change the value from:
'sweep' to 'amavis'
|
Scroll down to the line that begins with:
# @bypass_virus_checks_acl . . . .
|
|
And remove the "#" symbol at the front of this line
|
This last one removes all anti-virus code from amavis. Since we're only interested
in anti-spam functionality, for us, this is a good thing.
Locate the line that begins with: #$warnspamsender = 1; . . .
and remove the leading # symbol, to make amavis send a bounce message
whenever an email is quarantined as spam.
|
Of course, this is your call, but
strict RFC compliance calls for notifying the sender whenever you don't
deliver to a recipient. I do it, even though it does mean I always have
a small stack of emails in the queue headed to obviously bogus sender
addresses. This doesn't have much effect on the server's performance.
Next, locate the line that begins like this:
$mailfrom_notify_spamadmin . . .
and change
"spam.police\@$mydomain"; to "postmaster\@domain1.com";
|
Next, locate the line that looks like this:
#$spam_quarantine_to = 'spam-quarantine';
and insert a # symbol at the beginning of that line
|
On the very next line, you'll see:
#$spam_quarantine_to = "spam-quarantine\@$mydomain";
Here, remove the leading # symbol.
|
|
(And make sure you have an emailbox for this address on a destination server -
This is where you will review quarantined emails, and will forward on any "false
positives" to the proper recipient.)
|
|
*Alternative:* Instead of delivering the spam to an emailbox on the internal
server, drop it into a folder right on the spamfilter. To do that, comment
out the "spam_quarantine_to" line above that references the email address, and
instead select and indicate a folder name for the value "spam_quarantine_to".
(Read the comments in this area of amavisd.conf for more info.)
|
Installing amavisd prerequisites
We'll get these prerequisites from CPAN, which is a fantastic service on the Net that
provides perl code, so we don't have to go to a bunch of different web/ftp servers to
get what we need. There is a LOT of stuff we need, though, so this will take a while.
Grab a soda and plug in to the Ethernet:
cd
|
perl -MCPAN -e shell
|
|
at the prompt asking if you are ready to manually configure, type "no"
(we'll let it autoconfigure)
|
*If at any point you are prompted for unsatisfied dependencies
and asked if you want to "prepend them to the queue", choose
"y" for "yes". If at any time you get prompted asking if you want to
modify/update your configuration, reply yes also. You might also get a message
saying the servers are too busy or "maximum connections", and you don't get
that piece installed. Just wait a second, and try again. Keep at it
until all these are on your machine. If at any point it seems to just be
hung/not moving, wait at least 30 seconds, and hit the Enter key.
(Watch capitalization, and symbols need to be EXACT):
then just be patient until it finishes the install and returns you to the cpan
prompt...
Then go on...
install Compress::Zlib
|
install Archive::Tar
|
install Archive::Zip
|
install IO::Stringy
|
install Mail::Internet
|
install Net::Server
|
install Convert::TNEF
|
install Convert::UUlib
|
install MIME::Base64
|
install MIME::Parser
|
|
(The next one prompts: "Do you want me to perform hostname lookups?"
responded n for no. (we don't need this tested now), it will prompt you
with "Enter a list of available NNTP hosts" -just hit Enter.
It will ask about several other kinds of hosts, like
SMTP, POP3, etc. -just hit Enter. Then a prompt will ask if
"you have a firewall/ftp proxy between your machine and the internet"
Answer appropriately for your situation, then comes a prompt for "Should
all FTP connections be passive? hit Enter (for yes). Then, when prompted,
provide your internet domain name (e.g. domain1.com), and for "Do you
want me to run these tests?" reply no.
|
install Net::SMTP
|
install Digest::MD5
|
install Time::HiRes
|
install Unix::Syslog
|
q
|
|
|
Starting amavisd-new
Let's give amavisd a little test run:
amavisd stop
|
amavisd debug
|
|
After just a few moments, if you have something misconfigured, amavisd will
tell you. If you have an error in /etc/amavisd.conf, it will give you a line
number and a brief explanation. Fix anything wrong. This will mean reading
closely any error messages, and possibly reading files in
/usr/local/src/amavisd-new-########, etc. There are friends at the amavis
mailing lists waiting to help...
|
|
If everything is OK, you will see a lot of lines scroll that look like text log
entries (exactly what debug mode does - logs to the screen), and the last item
will end with "Parent ready for children". (Only a computer could say that, huh?)
|
|
Use the Ctrl-C key combination to exit amavis.
|
You can ignore the lines above this that talk about
things like "No $unfreeze - not using it", and "No zoo", yada, yada. Unfreeze and
zoo and the rest of those are similar to [un]zip and other [de]compression
utilities. Useful if scanning email for hidden viruses, but we won't bother to
open such unusual compressed/archived file attachments to look for spam. FYI,
though, each time amavis starts up normally on your box, all these lines will
be recorded in the system log files.
Obviously, we'll want amavisd-new to start at boot, and we'll want it to
fire up BEFORE postfix, so when postfix directs mail to its filtering
friend, the friend will be there to answer the call. We'll put an init script
for amavis where it goes, and set it to start amavis at boot:
cp /usr/local/src/amavisd-new-########/amavisd_init.sh /etc/init.d/amavisd
|
chmod u+x /etc/init.d/amavisd
|
chkconfig --add amavisd
|
vi /etc/init.d/amavisd
|
Change the line:
prog="/usr/sbin/amavisd"
to:
prog="/usr/local/sbin/amavisd"
|
*For those admins wondering, you do NOT need to do anything further to
make amavisd-new run as the "amavis" user. The program itself will do this,
keeping it from having root priviledges. Postfix, BTW, will also run
automatically as another user: "postfix", not as root.
Give ownership to the Spamassassin folders to amavisd, and test a Start-up
chown amavis:amavis -R /usr/share/spamassassin
|
Razor2 configuration
An individual who set this system up recently pointed out that this document
does not cover proper Razor configuration. I have not tested his instructions
yet, but I have reasonable confidence that they are accurate. I provide the
following link to a page, which he has created, covering this configuration.
If you do not follow
the instructions on his page, your spamfilter will run fine, but apparently
will not take advantage of the Razor capabilities. I will be going through
this Razor configuration procedure myself within the next few weeks (when
I get TIME!!!!!) and will update this document accordingly then. Here is the
page. (Please
note that any line on his doc that begins with a # symbol means to type
that command in, as root.)
...OK, let's see if we can fire this system up! Type:
/etc/init.d/amavisd start |
/etc/init.d/postfix start |
From each command, you should see a line indicating that the program
started successfully. This is indicated by "OK" appearing on each line.
If instead the word "FAILED" appears on either line, you've got a
config error somewhere with either postfix or amavisd. (Or you already
had one or both already running, in which case of course they will
"FAIL" to start. You must shut them down first.
OK, you can start them? Great. Let's see if we can connect to amavis. With
a little deviation, we will basically follow the doc on your machine at:
/usr/src/amavisd-new-########/README_FILES/README.postfix:
telnet 127.0.0.1 10024
|
|
You should get a connection response, indicating amavisd-new is "ready".
Good. now just drop the connection:
|
quit
|
Shut them both down again, Postfix Interruptus:
/etc/init.d/amavisd stop |
/etc/init.d/postfix stop |
Required Name resolution
-OK, other mail servers will need to find your server. Set up
name resolution of spamfilter.domain1.com to its IP address. How
this is done depends on your environment. Bascially, you need
to make sure that any box that needs to talk to this mail
server can resolve its name, either through appropriate DNS
server entries somewhere, or local "hosts" files on those
machines.
MAILGREP UTILITY:
-While not required, a nice tool to have is "mailgrep.pl",
to parse certain data out of the mail logs instead of having to
scroll through them, or do the grep commands. Note this tool
will not work quite right with Mandrake, as Mandrake by default
disperses mail log data to 3 different files under /var/log/mail.
You'd have to read up on how this tool works and see if you can make
it fit that set up (or change the way Mandrake logs to resemble Red
Hat). If you do either, please let me know how this comes out!
This little gem was
written by Craig Sanders, but for some reason the links on
Craig's web site (http://taz.net.au/postfix) don't work anymore,
so I have put a copy on my site (thanks to the GPL Craig released
this under, this is all perfectly simple and legal - thanks,
Craig!) So, to set this up, download the openlogfile (a
perl function to open log files) and mailgrep (a perl script to
help search the maillog) utilities, rename them, put them in
/usr/bin, and make mailgrep.pl executable:
-plug in the Ethernet cable again... then get to your browser of choice and
download the file:
http://www.geocities.com.scottlhenderson/mailgrep.pl.txt
-do a "Save as", and save it to /usr/bin
-shorten the name by removing the ".txt" from the end of the file
name.
-do the same with:
http://www.geocities.com/scottlhenderson/openlogfile.pl.txt
Next, grab "File::MMagic", using CPAN (you know how to do this now!)
-then, pull the Ethernet cable out, and:
chmod +x /usr/bin/mailgrep.pl |
-To learn how to use this, just type the command:
mailgrep.pl
*Note: our mail log is not "mail.log" (the default for this
tool), so we need to type the correct mail log path and file name
- /var/log/maillog -when we use it. E.g., to search for all
mail log entries dealing with mail to or from
"someuser@somedomain.com", we would use:
mailgrep.pl -s someuser@somedomain.com /var/log/maillog
To see what mailgrep.pl does for you, compare the output of the
above to:
grep -i someuser@somedomain.com /var/log/maillog
Of course, these suggest ideas for developing scripts to make these
kinds of searches even easier. All of that is left as an exercise
for the reader...
SPEED UP REBOOTS:
-set grub to 2 second delay, to make remote reboots
faster, but still allow you time to respond if you're at the
console:
vi /boot/grub/menu.lst
-edit the line: timeout=10 to timeout=2
MAIL REPORTS:
-This section will set up an automated preparation of a very
nicely laid out report of email activity, and email this report
to us once per day, with the previous day's mail statistics,
and once weekly, with the stats for the entire previous week.
-first, we need the Date::Calc perl module. Plug into the
Ethernet and:
perl -MCPAN -e shell |
install Date::Calc |
|
(this will require some other stuff, when prompted, choose yes)
|
bye |
-Then, we need the pflogsumm.pl utility:
cd /usr/bin |
Go to: http://jimsun.linxnet.com/postfix_contrib.html
Read the instructions and get the latest pflogsumm.pl installed
|
-pull the Ethernet tubule
-Don't forget to make pflogsumm.pl executable:
chmod +x /usr/bin/pflogsumm.pl
|
-ROUTINE EMAIL OF LOG SUMMARIES:
-set up cron to prepare and mail pflogsumm results, daily and
weekly:
as root:
Enter
a blank line or 2 above the existing line using the Enter key,
arrow back to the top and type in 2 lines: (replacing
"spamfilter.domain1.com" with the name of your mail server) This
report will be emailed to wherever you redirected root's email. Obviously
you can change this behavior...
| The end result should be like:
|
10 3 * * * /usr/bin/pflogsumm.pl -d yesterday
/var/log/maillog 2>&1 |/bin/mail -s "spamfilter.domain1.com -
Postfix daily mail summary" root
|
10 3 * * 0 /usr/bin/pflogsumm.pl /var/log/maillog 2>&1
|/bin/mail -s "spamfilter.domain1.com - Postfix WEEKLY mail summary"
username |
SECURITY:
-Set up some decent security on your box. If you don't know
how, plug in to the Ethernet and go to
http://www.cisecurity.org
and download the latest Linux security benchmark and tools and
use them. Not real hard to do, but takes a little time.
You can skip this, of course, but do polish your resume if so, and
don't keep it on this box, it will be hacked. :)
Just fill out your name and email address, on the cisecurity web page,
then download and read the pdf documentation and go through it step by step.
It will take an hour or so
to do. One note: at the end of this doc it explains how to use ntpd
for time service. You NEED to do this, to have accurate time stamps for
emails and logs. Important for email servers, it is! (Yoda again...) You can refer
to http://www.ntp.org for more information (than you
maybe want) on ntp time service, but also for a list of free
public time servers you can use. The instructions in the CISecurity
pdf file don't explain something I had to do for ntpd to work,
however.
|
If ntp doesn't work for you, after you set it up, do this:
|
touch /etc/ntp.drift.TEMP
|
chown ntp /etc/ntp.drift.TEMP |
-To learn more on security, read the Linux Security HOWTO
document at:
http://www.tldp.org/HOWTO/Security-HOWTO/index.html
and/or the Red Hat-specific security doc at:
http://www.tldp.org/HOWTO/Security-Quickstart-Redhat-HOWTO/index.html
Configure tripwire
...if desired. For info, see
www.tripwire.org (do you notice a pattern here?),
or get a good book on it, and of course, read thusly:
man tripwire |
BACKUPS
-Develop a plan for backups. You need a plan for this, even
though this machine won't hold data, for the most part, since
all mail will just be forwarded from it, not generally stored on
it (unless the mail server it is sending to goes down, in which
case it will store all mail until the receiving server becomes
available). At the least, you should backup all the configuration
files related to the programs in use on this server! Remember if you
blow the thing up, you'll be back here reading this document again!
(Actually a copy of this HOWTO as the build document for this system
might not be a bad idea either...)
Make sure the Ethernet cable is plugged in, and
reboot the box. You're done, girl. Go test it
:)
I'd like to add a good deal of information on tweaking and
white/black-listing, etc., but who knows when I'll have time for it.
Here's a little bit I have so far:
CONFIGURING, WHITELISTING, BLACKLISTING, CHANGING SCORE VALUES, ETC.
-With Amavis and SpamAssassin, you can change many configuration values.
Among these are white and blacklisting senders and receivers,
altering the scores for various spam-ish email characteristics, and
so forth. For those spammers who manage to always score just
below your SPAM score threshold, for instance, you can blacklist
their domain or specific sending address, as you see fit.
Likewise when legitimate email ends up in the spam quarantine
mailbox, you can whitelist the sender or domain. You'll be
doing this kind of thing several times a day for the first week or
two.
If you want to change the score that SpamAssassin gives to a
characteristic, you can do that too. These kinds of changes can
all be done in one file: /etc/mail/spamassassin/local.cf. You
don't want to go into the regular SpamAssassin config files (in
/usr/share/spamassassin) and mess with them. Your changes would be
overwritten if you upgrade SA in the future, anyway. Remember:
all of this has nothing to do with what Postfix does at the "front gate".
OK, here are the contents of a ficticious local.cf file, for ideas:
# /etc/mail/spamassassin/local.cf
#
# WHITE AND BLACKLIST FILE, AND SCORE CHANGES
#
# Note: wildcards ARE allowed here. Please add entries to
#each list in alpha order, by final domain.
#
# WHITE-LISTED SENDERS (the good guys):
whitelist_from *.good-domain.net # This domain is safe
whitelist_from *@goodguys.com # These guys are ok
whitelist_from dudley.duright@mounties.ca # He never spams us
# WHITE-LISTED RECEIVERS:
# (Let ALL mail through to these recipients - no scanning for SPAM):
all_spam_to spam-lover@domain1.com # He likes it
# BLACK-LISTED SENDERS (the bad guys):
blacklist_from offers@*.*
blacklist_from offerz@*.*
blacklist_from *@badguys.com # nasty outlaws
blacklist_from *@casino-fun.* # we don't want any of this stuff...
# SCORE CHANGES (Don't mess with these unless you KNOW what
# you are doing!
score FORGED_HOTMAIL_RECD 5.50
score WEB_BUGS 1.50
* Note: a good site for email server testing is at:
http://zmailer.org/mxverify.html (read the instructions on the page)
Some final comments:
Spam traffic in increasing dramatically. I
recently read an estimate that spam traffic may represent one half of
all email traffic by year end 2003. And spammers are becoming
increasingly sophisticated. Setting this system up won't
end your anti-spam project, I'm afraid. You'll catch a LOT of
spam with this, but some will keep getting through, and some good
emails will get blocked. You'll learn and tweak things as you
go forward.
My time to provide tech support for this procedure is VERY
limited, but if you're in a jam, try me and I'll help if I can. My
apologies in advance if I can't help or don't have time. I have
to keep my day job... Please don't write me asking how to do things
other than what this doc covers, like adding in virus protection, or
doing different things with the spam. Other documentation exists to
cover these things, you just have to read it. If you have a problem,
carefully check your config, and read your log files for clues.
You also have available to you the mailing lists for
spamassassin, postfix, amavis, etc. The people on these lists
are very helpful - I couldn't have set this up without them.
They are an EXCELLENT tech support option -- from them, I usually
always had an answer to my questions within a few minutes to a half an
hour or so!
I hope this doc is useful to you. Feel free to contact
me, scottlhenderson-at-yahoo.com, with comments and
suggestions. Please keep in mind this is a freebie project. I
provide this because I enjoy doing it, and want to save others some of
the learning curve I went through. I make no money on this. If you
are just DYING to send me money, let me suggest your $$ would
be better spent going to an established, Open Source organization, like
the Free Software Foundation or your favorite Linux distro. Or to
Amnesty International. Something like that. Tell me that you did so
on my behalf and my heart will be warmed.
Everyone is welcomed to link to this document, as well as to copy
all or any portion of it for their own use and/or to share with
others pretty much as they see fit. More specifically,
this document is provided under the terms of the OpenContent
license. See http://www.opencontent.org/opl.shmtl for
a copy of the license.
The author can unfortunately assume no liability for the use of this
information. Terribly sorry. If you're standing on someone's shoulders you
probably shouldn't try to kick them anyway.
This page created with the "vi" web page builder. :)
Good-bye! (finally, huh?)