Originally by Scott Vintinner
Anti-Virus section originally by Kris Nosack
View the full list of contributors here
In order to give my initial instructions a life of their own, I have set up this Wiki. Basically this site contains the directions for setting up the same anti-spam gateway, but in a format that anyone can edit. Please feel free to correct any mistakes that you find here. All I ask is that you read the Before You Start Editing page so that we can keep everything fairly consistent. You'll also find help formatting and creating pages, via the Wiki Help page.
If you are looking for information about older versions of this solution, check out our Old Versions page.
Introduction:
Installation:
Setup:
Other Notes:
If you are using our directions, please sign our guest book: Recent Visitors
 | Anti-Spam Printable view |
| Anti-Virus Printable view |
Due to the overwhelming amount of SPAM (people editing pages to advertise porn sites, etc), I have locked some pages that shouldn't change often. If you need to make changes to any of these pages, please let me know. If you are considering spamming here, please know that it will be removed as fast as you can put it up, so don't even bother.
This document describes how to setup a spam-blocking email gateway based on open source and freely available software. This procedure is designed for a small to medium sized company. It describes how to setup a new computer that is meant to run on your network's DMZ in between the Internet and a corporate email server like Lotus Notes or Microsoft Exchange.
This entire procedure has been developed with security as a primary focus. The operating system is OpenBSD (http://www.openbsd.org), which is a "Secure by Default" system with a good track record for security. The email MTA is Postfix (http://www.postfix.org) which also has a good record for security and is the easier of the 2 main competitors to the troubled sendmail program. Amavisd-new (http://www.ijs.si/software/amavisd) is the main filter which processes email from postfix and ensures that we don't lose any mail. SpamAssassin (http://www.spamassassin.org) is the main anti-spam component which works by comparing messages to a ruleset and by using a statistical analysis that is custom built based on your email. In addition to SpamAssassin, we will be using 2 online SPAM databases: DCC (http://www.rhyolite.com/anti-spam/dcc) and Vipul's Razor (http://razor.sourceforge.net). These databases work by comparing hashes of our email messages with hashes of known spam. As a final security precaution, we will run all network processes in a restricted-user/chroot environment,so if an attacker were able to compromise one of the modules, the amount of damage they could do would be seriously limited.
There are many different ways to customize the handling of SPAM with amavisd-new to fit your company. The configuration of Amavisd described here is designed to totally remove the burden of SPAM from your end users; no more work is required from them, the spam just disappears. In all current e-mail systems, if someone sends an e-mail to you, but mistypes your email address, your server rejects their e-mail, and it is up to the author to find out your correct address. This system works on the same premise, by telling the sender that their message looks like SPAM and telling them to solve the problem. When a message is rejected, the sender will get a postmaster "undeliverable" message from their mail server which includes a short message that we can customize with directions in case of a false-positive. The sender can follow the directions in this short message to be added to a "whitelist" of approved email addresses which get to bypass the spam filter. This solution is similar to other Whitelist style programs out there, except that where they reject all messages until the author is whitelisted, we only reject messages that look like SPAM.
Since this system has a low false-positive rate, the end result is a process that requires no action on the part of the 99% of people sending you valid email. Most importantly, since we put the burden back on the mail author, our end users no longer have to waste ANY time on a message we have identified as SPAM.
The best place to go for help is the amavisd mailing list (https://lists.sourceforge.net/lists/listinfo/amavis-user).
Please search through the archive (http://marc.theaimsgroup.com/?l=amavis-user) for answers to your problem before posting a question. Mark Martinec does a very good job of answering most questions quickly, so please don't waste his time. Do some research first and try to ask good questions. I also subscribe to the list, so when posting your question be sure to mention which OS you are using (Likely OpenBSD).
Also please do not email huge copies of your config files or debug output unless asked to do so; or use a web service like [PasteBin] and put the links in your email.
If your question is specific to [SpamAssassin], [DCC], [Razor], [Amavisd-New], or [PostFix], please refer to their respective homepages and mailing lists for support.
If you have a suggestion, or a question, please visit the discussion board for this web site [here].
Since computers with 256 MB of RAM are increasingly common, these directions are optimized for a computer with at least that much memory. If you have more or less memory, you should see the section on Performance before putting your server into production. This configuration will allow up to 8 simultaneous connections to your server. If you need to support more connections at a time, you will need to add more memory to the system (amavisd is a bit of a memory hog).
Text listed in monospace bold are commands that you type into the console.
Text listed in monospace italics represent the output you can expect after executing a command in the console.
Text listed in monospace are edits to text files.
Text listed in monospace gray tables represent entire config files.
This document is not really meant for the unix newbie. If you have never worked with linux or unix before, you may experience some difficulty with these directions. Specifically, I expect that you will know how to use vi to edit files (here's a [vi cheat sheet]). (Actually I've been informed that you can set the EDITOR environment variable to get OpenBSD to use whatever editor you want for vipw and crontab -e, so I guess you can use whatever editor you want.)
Also, you'll want to grab a copy of PuTTY and WinSCP. These 2 utilities will help you configure your server remotely without the need for a GUI running on the server itself. PuTTY is an awesome SSH client that you can use to talk to your OpenBSD server over a secure link. It has 2 great features: anything you select with your mouse is copied to the Windows clipboard, and right-clicking the mouse anywhere in the window will paste the contents of the clipboard. It works great in insert mode in vi to paste hundreds of lines. My servers are rack-mounts, so usually as soon as I get the network running on the OS, I head back to my PC and pull up PuTTY. WinSCP is a gui file browser for SSH. It will let you easily copy files back and forth between your Windows PC and the OpenBSD server.
I have received many many emails from people telling me that I'm going straight to hell for not using [SUDO]. As you look through my directions, you will see that the directions have you logged in as root during this entire procedure. The "best-practices" for OpenBSD say that you should login as an unpriviledged account to do most of the work and use the sudo command whenever root access is required. I'll be the first to admit that I'm not conscientious enough to follow those guidelines 100% of the time. I certainly suggest that you read up on the [sudo command] if you are unfamiliar with it. Personally I think there is a time and a place for using sudo and an efficient administrator knows the difference.
Obviously these directions require some customization to fit into your network. Specifically you'll want to replace the sample server names and IP addresses with your own. Here's a little diagram of what we'll be setting up:
 |
For our examples, our internal network numbering uses the 10.0.0.0/8 private domain range. The 10.1.0.0/16 network is our main network. The 10.2.0.0/16 network is our DMZ network. Our pretend public internet class C is 65.0.0.0/24. Additionally, the server we will be setting up will be called mta1 in these directions. You can call your server whatever you want, just replace it with your name where ever you see it. For simplicity, we'll pretend that our company's domain name is domain.com.
Hopefully you have a firewall at your company. Here's a list of what traffic you will need to allow through your firewall to make all of this work.
| Source | Destination | Type | Port | Description |
| 10.2.1.50 | 10.1.1.50 and any External | TCP | 25 | Outgoing SMTP |
| 10.1.1.50 | 10.2.1.50 | TCP | 25 | SMTP from Exchange to our MTA |
| any External | 10.2.1.50 | TCP | 25 | Incoming SMTP |
| 10.2.1.50 | any External | UDP | 6277 | Outgoing from our MTA to the DCC servers |
| any External | 10.2.1.50 | UDP | 6277 | Incoming from DCC Servers to our MTA |
| 10.2.1.50 | any External | TCP | 2703 | Outgoing from our MTA to the Razor servers |
| 10.2.1.50 | any External | TCP | 7 | Outgoing ping from our MTA to the Razor servers |
| 10.2.1.50 | any External | TCP | 22 | Outgoing SSH (used to update our source code from the OpenBSD servers using CVS) |
| 10.2.1.50 | any External | TCP | 21 | Outgoing FTP (so we can download files that we need) |
| 10.2.1.50 | any External | TCP | 80 | Outgoing HTTP (also so we can download files) |
Additionally mta1 needs to have access to a DNS server. In my configuration the DNS is on the DMZ so no extra firewall rules were required.
The [OpenBSD FAQ Chapter 4] provides an excellent step by step explanation of how to install the latest version of OpenBSD, so I won't repeat it all here. I'll just give some minor tips:
Once OpenBSD has been installed, head back to your desk and pull up PuTTY to remotely access the system through SSH. It is much easier to do it from your desk when you can have multiple remote sessions going and can cut and paste using PuTTY.
NOTE: these directions assume that this is a new server that is not currently being used. If your server was previously running sendmail or some other MTA, you will want to check the postfix INSTALL file for better instructions on migrating to postfix.
When possible, you never want to run anything as root. The root account has unrestricted access to everything, so if there is a bug or security hole in anything you run as root, it could potentially compromise your entire system. To further tighten the security of our system, we will run different modules as different user accounts.
Use vipw to edit the password file. You could also use the adduser or useradd commands, but this is the easiest way for us. Go to the bottom of the file and add the following lines:
postfix:*:2000:2000::0:0:Postfix Mail Daemon:/var/empty:/sbin/nologin amavisd:*:3000:3000::0:0:Amavis Mail Scanner Daemon:/var/amavisd:/sbin/nologin
Next we want to add the group accounts for our new users. To do this, edit the /etc/group file with vigr. Add the following lines (preferrably in numeric order with any other groups in the list):
postfix:*:2000: postdrop:*:2001: amavisd:*:3000:
Note: in OpenBSD 4.2 vigr doesn't seem to exist.
Use:
group add -g 2000 postfix group add -g 2001 postdrop group add -g 3000 amavisd
Here's a quick explanation of what we'll use the new accounts for: The postfix account is the account that postfix will run under, and likewise the amavisd account is the account that the amavisd program will run under. Running these programs in non-root accounts is good for security, since if an attacker compromises either program, they are still limited by those accounts. BTW, the * in the first section is in place of where a normal password would be. The star tells the operating system that the user cannot login. The /sbin/nologin is the user's shell that is launched when they login...which in this case is another indicator to the operating system that these users shouldn't be able to login.
Note: http://www.ijs.si/software/amavisd/ says:
OpenBSD and NetBSD? have a pretty low default setting for max open files. To increase it for the default login group edit the /etc/login.conf, or add the user vscan to the daemon login group which has higher settings. Exceeding the limit can lead to spinning amavisd child processes or Berkeley db 'running out of lockers', often associated with Razor2, Bayes or DCC checks. (What's the recommended number?)
You can install Postfix from the OpenBSD port collection using the directions included in the Ports & Packages FAQ. The postfix port is located at /usr/ports/mail/postfix. You may want to double-check which version you are getting with that method, as it must be version 2.1.0 or higher. Below I describe quickly how to install Postfix directly from the source. For more detailed instructions, look at the INSTALL document once you have uncompressed the source code file. Why don't we just use the pre-built Postfix Package?
Download latest version of postfix to /root and compile it. Check the http://www.postfix.org website for the latest version since it is updated frequently.
cd /root
ftp http://mirrors.isc.org/pub/postfix/official/postfix-2.5.2.tar.gz
tar -zxvf postfix-2.5.2.tar.gz
cd postfix-2.5.2
make
Setup the default postfix config by running make install and answering questions.
make install
Answers (most will be the defaults)
install_root: [/] tempdir: [/root/postfix-2.5.2] or whichever directory the source is in config_directory: [/etc/postfix] command_directory: [/usr/sbin] daemon_directory: [/usr/libexec/postfix] data_directory: [/var/lib/postfix] html_directory: [no] mail_owner: [postfix] mailq_path: [/usr/bin/mailq] manpage_directory: [/usr/local/man] newaliases_path: [/usr/bin/newaliases] queue_directory: [/var/spool/postfix] readme_directory: [no] sendmail_path: [/usr/sbin/sendmail] setgid_group: [postdrop]
Setup Postfix CHROOT. Here we need to copy the necessary system files to the root directory where postfix will be restricted.
mkdir /var/spool/postfix/etc
cd /etc
cp localtime services hosts resolv.conf /var/spool/postfix/etc
Setup Aliases File. Here we want to setup the aliases file (which provides aliases for commonly used accounts). If we had one from sendmail we could use it. Otherwise we'll just copy the sample one. Basically the aliases file allows us to redirect any email for non-email receiving accounts (like www) to the root account. Root's email is forwarded to us using the /root/.forward file we setup above.
cp /etc/postfix/aliases /etc/
Run newaliases to hash the textfile into aliases.db (which is what postfix actually uses).
newaliases
Next we want to edit the postfix configuration file (/etc/postfix/main.cf) to customize it for our email system. Search for the following entries to set. Note that many will not be listed in the default file.
# # >>>>>>>>>> You must reload postfix after editing this file # >> NOTE >> to do this use the command: # >>>>>>>>>> # postfix reload # queue_directory = /var/spool/postfix daemon_directory = /usr/libexec/postfix command_directory = /usr/sbin mail_owner = postfix myhostname = mta1.domain.com mydomain = domain.com myorigin = $myhostname mydestination= $myhostname, localhost.$mydomain, localhost mynetworks = 10.0.0.0/8, 65.0.0.0/24, 127.0.0.0/8 relay_domains = hash:/etc/postfix/relay_domains #relay_recipient_maps = hash:/etc/postfix/relay_recipients # See notes below #show_user_unknown_table_name = no biff = no empty_address_recipient = MAILER-DAEMON queue_minfree = 120000000 message_size_limit = 80000000 mailbox_size_limit = 1000000000 smtpd_banner = $myhostname ESMTP transport_maps = hash:/etc/postfix/transport local_transport = local smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_non_fqdn_recipient #some people also add reject_non_fqdn_sender (but I have clients that break this rule that I need to receive from) notify_classes = protocol,resource,software # Install Time Configuration sendmail_path = /usr/sbin/sendmail newaliases_path = /usr/bin/newaliases mailq_path = /usr/bin/mailq setgid_group = postdrop manpage_directory = /usr/local/man sample_directory = /etc/postfix readme_directory = no html_directory = no
Explanation of Postfix configuration settings:
| queue_directory | Postfix's work directory. Where all the mail will be temporarily stored until it is delivered. |
| daemon_directory | Specifies the location of all the postfix programs. |
| command_directory | Specifies the location of all post* commands. |
| mail_owner | Specifies the user account that will own the mail queues. |
| myhostname | The name of this computer including the domain part. This is used when adding received by headers in email messages. |
| mydomain | This specifies the domain of this current computer. |
| myorigin | This name is added to locally originating email. So if you sent yourself a message from root, it would appear to come from root@mta1.domain.com. |
| mydestination | This setting tells postfix what domains it is the final destination for. This should be left at the default, and your domain should instead be listed in the relay_domains file. |
| mynetworks | This setting tells postfix what networks it should consider local. In other words, computers connecting from any of these networks will be able to relay mail, etc. In our case, we put 127.0.0.0 (for localhost), 65.0.0.0 (for any other computers on our external network), and 10.0.0.0 (for any internal computer). |
| relay_domains | This setting tells postfix which domains it should relay. In this setting, we specify the relay_domains file (which we'll create below). This simply lists domains each on separate lines. |
| relay_recipient_maps | This setting allows you to deny email to any recipient not listed in the specified file. This should be commented out unless you want to either manually maintain this file (/etc/postfix/relay_recipients), or if you want to follow the directions to Automatically Update Recipient Maps From Active Directory. |
| show_user_unknown_table_name | This setting changes the rejection message of "User unknown in relay recipient table" for users no in the relay recipient table to simply say "User unknown." This setting is only used with the relay_recipient_maps setting. |
| biff | This setting tells postfix not to use the biff program to let local users know that they have new email. |
| empty_address_recipient | This setting is the destination for undeliverable mail from <> |
| queue_minfree | This setting tells postfix not to accept any messages for delivery if there are less than 120 megs of disk space available. This number should be 1.5 times the message_size_limit or you will get an error message. |
| message_size_limit | This sets the maximum size of a message. Messages larger than 80 megs will be rejected. You can increase or decrease this based on your own server requirements. |
| mailbox_size_limit | This sets the maximum size of local mailbox files. We set it to 100 megs, although it should never reach this high because our only local mailboxes are spam and notspam |
| smtpd_banner | This is the banner that is displayed to connecting computers. It is a good security practice to give as little information as possible. I've included just the essentials. |
| transport_maps | This setting tells postfix where to find the transport information. The transport file is where we tell Postfix where to route certain mail. In our case, this file is where we tell Postfix that mail for domain.com should be delivered to our exchange server. |
| local_transport | This setting tells postfix that all local mail should be delivered using the local delivery agent. |
| smtpd_helo_restrictions, smtpd_sender_restrictions, smtpd_recipient_restrictions | These settings are used to deny access to postfix based on the HELO command, the sender, or the recipient. The recipient restrictions settings are used to prevent our mail server from being used as an open relay. As configured, the helo and sender restrictions are left open. If you want to play around with these you can, just look them up in the postfix documentation. Normally these settings can be used to help block SPAM. Unfortunately they depend on the assumption that all legitimate senders have their systems correctly configured. In my experience this is never the case, so these settings are more trouble than they are worth. Like the RBL lists, I found that enabling these settings meant that I spent too much time teaching other mail administrators how to correctly configure their systems (Note that we'll use Realtime Blackhole lists (RBLs) in SpamAssassin, not in Postfix because there positive hits will simply result in higher spam scores.) |
| notify_classes | This setting tells postfix to send all sorts of notifications to the postmaster email account. Here's a list of the available options: bounce: Send the postmaster copies of the headers of bounced mail. 2bounce: Send undeliverable bounced mail to the postmaster. delay: Send the postmaster copies of the headers of delayed mail. policy: Send the postmaster a transcript of the entire SMTP session when a client request was rejected because of (UCE) policy. If you enable this, you will get 1 email for every spam message that was rejected by amavisd. Good for testing, not good for production. protocol: Send the postmaster a transcript of the entire SMTP session in case of client or server protocol errors. resource: Inform the postmaster of mail not delivered due to resource problems. software: Inform the postmaster of mail not delivered due to software problems. |
| Install Time Configuration | This section holds the settings we used when we installed postfix. We keep them in the config file so that future upgrades will be easier. |
Edit /etc/postfix/master.cf file. Change the CHROOT setting for all the base postfix services from 'n' to 'y'. Adjust the maxproc for the smtp line and include the added parameters. Also add the 127.0.0.1 daemon as indicated.
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
#This is the before-filter smtpd...it passes content to amavisd on port 10024
smtp inet n - y - 8 smtpd
-o smtpd_proxy_filter=127.0.0.1:10024
-o smtpd_client_connection_count_limit=4
#This is the after-filter smtpd, it receives mail from amavisd to port 10025
127.0.0.1:10025 inet n - y - - smtpd
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=
-o receive_override_options=no_unknown_recipient_checks
pickup fifo n - y 60 1 pickup
cleanup unix n - y - 0 cleanup
qmgr fifo n - y 300 1 qmgr
rewrite unix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
flush unix n - y 1000? 0 flush
proxymap unix - - y - - proxymap
smtp unix - - y - - smtp
relay unix - - y - - smtp
showq unix n - y - - showq
error unix - - y - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - y - - lmtp
trace unix - - y - 0 bounce
verify unix - - y - 1 verify
anvil unix - - y - 1 anvil
scache unix - - y - 1 scache
tlsmgr unix - - y 1000? 1 tlsmgr
discard unix - - y - - discard
Another option is below. It is my understanding that using Amavisd with Postfix as a pre-queue mechanism is not what amavisd was designed for, nor does it work very well in all cases. I have seen several problems using the above setup and present the one below as an alternative that invokes amavis AFTER mail has been queued. It has solved the problems I was seeing with amavisd rejecting emails it shouldn't be due to SMTP commands not being understood by amavisd. Notice the use of content_filter vs. smtpd_proxy_filter. ERZ
# Postfix master process configuration file. For details on the format
# of the file, see the Postfix master(5) manual page.
#
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - 5 smtpd
-o content_filter=smtp-amavis:[127.0.0.1]:10024
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - n - - smtpd
-o local_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o strict_rfc821_envelopes=yes
NOTE1: In my case it was necessary to run proxymap *NOT* chrooted, since its purpose is to get around chroot restrictions! YMMV. [Tim Buck, added 04/04/2005]
NOTE2: I disabled some of the other services in the master.cf while testing and received scache error "connection to subsystem private/scache: connection refused". After enabling "scache unix - - y - 1 scache" my errors stopped. [Travis Robertson, added 04/15/2005]
NOTE3: I added the last 3 lines (scache, tlsmgr, discard) onto the master.cf file above as they are required as of Postfix 2.2. As Travis noted above, failure to include scache in particular can cause real problems. [E. Falk, added 6/10/2005]
I won't bother explaining this file in too much detail. Basically this file is used by the master program to figure out how to run each of the individual postfix processes.
The first smtp line is the smtp daemon that listens for incoming connections. As the message is coming in, it is passed through to the proxy filter (amavisd) on port 10024. Note that the maxproc column specifies the maximum number of instances of that program to run (to prevent overwhelming the memory on the PC).
The :10025 line is a smtp daemon that delivers messages without filtering. It is used by amavisd when it passes back a good message for acceptance into the queue. It is also used for delivering mail from internal servers, since we trust all their content and don't need to filter it (the redirection is done by pf. See (Setting up pf and spamd)? for more info. To speed up this daemon, we remove many of the restrictions we place on the other daemon.
The smtpd_client_connection_count_limit prevents the same remote server from connecting more than once to your server (and hogging all your connections). You should set this to be around half of the setting of the smtpd maxproc.
NOTE: using the Before-Queue filter method is not recommended for very high-traffic ISPs unless you can dedicate a high-ram server. You can only have as many connections at one time as you have amavisd processes, so unless you have a lot of RAM you may not be able to run enough processes. For example, under a default postfix config, you could have up to 100 connections at a time. Under this configuration, you can only have 100 connections at a time. Further incoming connection attempts will be rejected, and the remote smtp will have to retry the connection later. If you experience trouble with this, you may want to switch amavisd into the normal filtering mode and use D_BOUNCE or D_PASS instead of D_REJECT (read the README.postfix in the amavisd documentation included with the source code). You can also read more about the Before-Queue filter in the SMTPD_PROXY_README included with the postfix source.
Now we want to create the relay_domains file. This file contains a list of domains (one per line) that you wish this server to relay for. In our case, we set it so it would relay mail for something@domain.com, and something@mail.domain.com. If you have multiple domains, you will want to list each of them on a separate line in this file. Remember to add OK with a space separating the OK and the domain name or else you will get an "expected format: key whitespace value" error when you go to run postmap.
vi /etc/postfix/relay_domains
domain.com OK
mail.domain.com OK
NOTE1: You probably need to run postmap /etc/postfix/relay_domains, otherwise you may find the following in the maillog:
fatal: open database /etc/postfix/relay_domains.db: No such file or directory
Next we want to edit the transport file (/etc/postfix/transport). This is a file that identifies where to route our incoming email. Since we want this server to accept all mail for our domain and route it to our exchange server, we will add that line here.
domain.com smtp:[10.1.1.50]
If you want to use a FQDN instead of an IP address, just leave out the brackets (i.e. smtp:exchange.domain.com). Just make sure that the server will be able to successfully lookup that DNS record.
NOTE1:
For the terminally lazy, or if you just have a large number of domains you relay for, try this to cut down on some typing:
cat /etc/postfix/relay_domains|sed -e 's/OK/[<your mail server's ip>]/g' >> /etc/postfix/transport
Or if you prefer to use FQDN
cat /etc/postfix/relay_domains|sed -e 's/OK/<your mail server's FQDN>/g' >> /etc/postfix/transport
Just make sure to review the file before you move on (Like removing the line that contains mail.domain.com OK)
NOTE1_END:
After editing the transport file, we need to run the postmap command. Postfix doesn't actually read the textfile we created because that would be slow (especially if the file had many entries). Instead we convert the file into a database format using the postmap command.
postmap /etc/postfix/transport
After running this command, you will see the new database file that has been created: /etc/postfix/transport.db.
If you are protecting a single Exchange server, you may want to consider using luser_relay instead of transport_maps and relay_domains. Add the following to your /etc/postfix/main.cf file:
mydestination = your_domain.tld, $myhostname, localhost.$mydomain, localhost local_recipient_maps = luser_relay = $user@your_exchange_server.your_domain.tld
This is helpful in the case where you need email addressed to $user@your_domain.tld delivered locally to the email gateway. Otherwise, the transport and relay_domain rules will always be used first. If your gateway is handling mail for more than one domain or you don't ever need mail handled locally on the gateway, then you shouldn't use luser_relay.
Setup Postfix to launch at Startup by editing the /etc/rc.local file to include the following:
# Start Postfix echo -n ' postfix'; /usr/sbin/postfix start
You can now start postfix using the postfix start command. You should test to make sure that you can connect to the SMTP interfaces on port 25 and port 10025. To do this use the command:
telnet localhost 25
The server should respond with:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mta1.domain.com ESMTP
press ctrl-], then type 'quit' to quit
telnet localhost 10025
The server should respond with:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mta1.domain.com ESMTP
press ctrl-], then type 'quit' to quit
Both amavisd-new and SpamAssassin are written in perl and have a number of other perl modules as dependencies. Fortunately perl has a built-in way to download and install these modules. To start the perl command environment use the command:
perl -MCPAN -e shell
NOTE: CPAN doesn't work in OpenBSD 4.1 (the only version I've checked) until you install the package p5-LWP-UserAgent?-Determined.
pkg_add -v ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/i386/p5-LWP-UserAgent-Determined-1.03.tgz
After some configuration and a bunch of questions since this is the first time you are using CPAN on this system (use the defaults, and select one or more CPAN servers from the list), this command will drop you to a little cpan> prompt where you can enter commands. To install a module, type install followed by the module name (ex. install MIME::Words ). If you need help, type help.
Here is a list of the modules required. Note that same may return saying they are up to date, so just move on to the next one. Also note that you don't necessarily need to run the latest version of all these modules in order for amavisd to work correctly. If the module is already installed, it may work fine without needing to be updated (especially since some module upgrades may require a newer version of perl!).
MD5 LWP MIME::Base64 Mail::Internet Archive::Tar Archive::Zip IO::Wrap IO::Stringy IO::Multiplex Unix::Syslog MIME::Words MIME::Head MIME::Body MIME::Entity MIME::Parser Net::SMTP Net::DNS (when prompted to enable tests, choose no) Net::Ping Net::Server Net::Server::PreForkSimple Convert::TNEF Convert::UUlib MIME::Decoder::Base64 MIME::Decoder::Binary MIME::Decoder::Gzip64 MIME::Decoder::NBit MIME::Decoder::QuotedPrint MIME::Decoder::UU Time::HiRes Digest::SHA1 Digest::Nilsimsa Getopt::Long File::Copy Bit::Vector Date::Calc
If you are feeling really impatient, you can install them all with a single install command: install MD5 LWP MIME::Base64 Mail::Internet Archive::Tar Archive::Zip IO::Wrap IO::Stringy Unix::Syslog MIME::Words MIME::Head MIME::Body MIME::Entity MIME::Parser Net::SMTP Net::DNS Net::Ping Net::Server Net::Server::PreForkSimple Convert::TNEF Convert::UUlib MIME::Decoder::Base64 MIME::Decoder::Binary MIME::Decoder::Gzip64 MIME::Decoder::NBit MIME::Decoder::QuotedPrint MIME::Decoder::UU Time::HiRes Digest::SHA1 Digest::Nilsimsa Getopt::Long File::Copy Bit::Vector Date::Calc
Occasionally you will be prompted with the following message:
- Unsatisfied dependencies detected during [G/GA/GAAS/Somefile.tar.gz] -
Name of Dependency
Shall I follow them and prepend them to the queue
of modules we are processing right now? [yes]
This is just telling you that the module you are installing needs some other module to work properly. It is asking your permission to go ahead and install it first. Go ahead and press enter to accept the default of yes.
Similarly you will be prompted with a number of other questions during this install process. Just press enter to accept the defaults on most of them.
If you run into any errors, try to read the error to figure out what you should do. In some cases you may get an error when a test that is run as part of the install fails. To install anyway use the force install modulename command. For more assistance with cpan and perl go to www.cpan.org.
Once everything is installed type 'q' to quit.
To check if all the modules were installed, run the Perl Module Test Script.
NOTE1(Added by Ivo Sabev (Summerborn)) I do not install perl modules this way. I also do not install things from source. It is good to know how to get things from scratch but I use the nice OpenBSD ports tree, which I tested on 3.8 and 3.9. Just go to /usr/ports and install postfix and amavisd-new. They will install all the dependencies including perl modules. The only differences will be the user names and groups that are used by postfix and amavisd to run. For postfix it is _postfix._postdrop and for amavisd it is _vscan._vscan
NOTE2(Added by (KillerLOOP?)) You can also install the ports from source, because of the current dependancies. I thnik it's the better way if you need specific features in feature.
NOTE3(Added by LMD) Something always seems to fail in the CPAN method. Don't panic. Try pkg_add (assuming you have PKG_PATH set) or try downloading and installing an older version of the package from CPAN.
NOTE4(Added by RaalM?) There seems to be a bug in libnet 1.20 module, wich causes all the accented characters in e-mails appear as the usual Unicode junk. Here is a decription of the bug and a temporary solution: http://rt.cpan.org/Public/Bug/Display.html?id=24835 This didn't fix the problem entirely, however. Maybe the best solution would be to try to downgrade libnet version.
Today, greylisting is one of the most effective antispam tools. It may reject >95% of all spam at the stage of SMTP conversation, thus saving lots of bandwidth and CPU power. As Wikipedia says,
Greylisting is a simple method of defending electronic mail users against e-mail spam. In short, a mail transfer agent which uses greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again to send it later, at which time the destination will accept it. If the mail is from a spammer, it will probably not be retried, however, even spam sources which re-transmit later will be more likely to be listed in DNSBLs and distributed signature systems such as Vipul's Razor. Greylisting requires little configuration and modest resources. It is designed as a complement to existing defenses against spam, and not as a replacement. http://en.wikipedia.org/wiki/Greylisting
You may find information on greylisting implementations at http://www.greylisting.org and http://projects.puremagic.com/greylisting/links.html. My favorite tool is Postgrey by David Schweikert, see http://postgrey.schweikert.ch/ (Note: the guy writes his e-mail clearly at his homepage :) )
Installation of Postgrey is rather straightforward: you'll probably need some Perl modules from CPAN (Net::Server and IO::Multiplex), depending on your installation. Use perl -MCPAN -e shell or anything.
Note: Prior to installation of Postgrey, you must install the IO::Multiplex PERL module.
--------
How I did it:
Open port 10023 on localhost if you need to & install CPAN modules, then:
cd /root # somewhere to work
wget http://postgrey.schweikert.ch/pub/postgrey-1.30.tar.gz # get postgrey
tar zxvf postgrey-1.30.tar.gz # extract archive
cd postgrey-1.30 # change into untared dir
useradd postgrey # add postgrey user
vipw #edit passwd file change postgrey logon to /sbin/nologin
mkdir /var/spool/postfix/postgrey # make db dir
chown postgrey /var/spool/postfix/postgrey # allow postgrey use access to dir
vi /etc/rc.local # edit rc.local
# Start Postgrey echo -n 'Postgrey'; /usr/local/sbin/postgrey --inet=10023 -d --delay=50 --greylist-text="Policy restrictions; try later" # to /etc/rc.local before the start postfix line.
mv postgrey /usr/local/sbin/
vi /etc/postfix/main.cf
smtpd_recipient_restrictions =
permit_mynetworks
...
reject_unauth_destination
check_policy_service inet:127.0.0.1:10023
mv postgrey_whitelist_clients /etc/postfix
mv postgrey_whitelist_recipients /etc/postfix
reboot and check logfiles
--------
Here is the current "Installation" section from perldoc postgrey
smtpd_recipient_restrictions =
permit_mynetworks
...
reject_unauth_destination
check_policy_service inet:127.0.0.1:10023
Voila!
Some problems may occur during the initial period until greylisting will learn common client/from/to triplets and whitelist frequently interacting MTAs. To prevent user complaints you may use scripts at http://oc-co.org/p2pwl to produce initial whitelists from your existing postfix logs. In fact, extensive but accurate whitelisting is a good cure for existing shortcomings of greylisting. If you administer several servers, you may share their whitelists using P2PWL tools or any SQL DB capable greylisting implementation.
NOTE: OpenBSDs? spamd does greylisting on PF-level and is also capable of tarpitting. It is worth a try.
[Web hosting] Wiki resource for webmasters
Both SpamAssassin and Amavisd now require BerekeleyDB be installed for optimal performance..
To do this, follow the directions under Install Needed OpenBSD Ports to setup your ports directory.
If you are using OpenBSD 3.7 or later:
cd /usr/ports/databases/db/v4
make install
otherwise
cd /usr/ports/databases/db
make install
If you get an error complaining of file sizes and checksums not matching, try a "make REFETCH=true" to update ports and then do a "make install".
In order for the perl BerkeleyDB modules to install correctly, you must setup some symlinks:
mkdir /usr/local/BerkeleyDB
ln -s /usr/local/lib/db4 /usr/local/BerkeleyDB/lib
ln -s /usr/local/include/db4 /usr/local/BerkeleyDB/include
Now use CPAN to install BerkeleyDB:
perl -MCPAN -e shell
install BerkeleyDB
If this is successful, you can skip the rest of the instructions on this page. In fact, as of 11/1/09, the CPAN installation package is confirmed successful, and the below appears to be deprecated.
Note that currently this install will fail because testing of the subdb module fails. I have reported this problem [here]. To bypass the testing errors, I quit out of CPAN and compiled and installed manually without testing. The issue appears to be resolved in BerkeleyDB-0.27.
cd /root/.cpan/build/BerkeleyDB-0.27
make clean
perl Makefile.PL
make
make install
You shouldn't receive any errors doing this, and my system seems to work correctly even though the subdb test seems to fail.
An alternative to manual installation is to ignore the testing errors in CPAN by using:
force install BerkeleyDB
If you get an error complaining "#error db.h is for Berkeley DB 1.x - need at least Berkeley DB 2.64", this indicates that multiple BerkeleyDB versions are found on the system. The solution is to edit the config.in file to point to the correct include (INCLUDE=/usr/local/include/db4) and library (LIB=/usr/local/lib/db4) files. Then "make", "make test" and "make install" as normal.
NOTE 1: The readme for the coresponding file at http://www.cpan.org/modules/by-module/BerkeleyDB/ are very helpful in troubleshooting the BerkeleyDB module installation, should you continue to have trouble with it's installation.
Run the perl shell to install it using the command:
perl -MCPAN -e shell
then type:
install Mail::SpamAssassin
and optionally
install Mail::SPF::Query
install IP::Country::Fast
If you are asked if you want to run the Razor2 or DCC tests, just press enter to select NO. When finished type q and press enter to quit.
Edit the /etc/mail/spamassassin/local.cf file and make the following settings:
report_safe 0 use_bayes 1 bayes_path /var/amavisd/.spamassassin/bayes skip_rbl_checks 0 use_razor2 1 use_dcc 1 use_pyzor 0
NOTE: These settings (use_razor2, use_dcc, use_pyzor) are obsolete now. Can be enabled/disabled in v310.pre file)
dns_available yes header LOCAL_RCVD Received =~ /.*\(\S+\.domain\.com\s+\[.*\]\)/ describe LOCAL_RCVD Received from local machine score LOCAL_RCVD -50 ## Optional Score Increases score DCC_CHECK 4.000 score SPF_FAIL 10.000 score SPF_HELO_FAIL 10.000 score RAZOR2_CHECK 2.500 score BAYES_99 4.300 score BAYES_95 3.500 score BAYES_80 3.000
Explanation of SpamAssassin configuration settings:
| report_safe (0|1|2) | This setting configures how to handle SPAM. A setting of 0 puts the SpamAssassin report into the headers. A setting of 1 puts it in the main email and attaches the original email as an attachment. Setting 2 is similar to setting 1, plus it changes the type of attachment to text/plain (as a security measure). NOTE: this setting has no affect when spamassassin is run through amavisd, so just leave it set to 0. |
| use_bayes (0|1) | This setting turns the Bayesean Learning on or off. In our case we want it on. |
| bayes_path (path) | Location of systemwide bayes database. We need to set this so that the root account can run the sa-learn program to update the bayes database normally used by the amavisd user. |
| skip_rbl_checks (0|1) | Definitely turn this off (0). Unlike using the Blackhole lists from within Postfix, using them in SpamAssassin allows you to selectively use the RBLs. For example, if you have a client that has an open relay and is unwilling to change it, you can simply add their domain to your whitelist, while still being able to use the RBLs for everyone else. |
| use_razor2 (0|1) | Tells SA that we want to use Razor version 2 |
| use_DCC (0|1) | Tells SA that we want to use DCC (Distributed Checksum Clearinghouse) |
| use_pyzor (0|1) | Tells SA that we don't want to use Pyzor (since we won't be installing it). |
| dns_available (yes|test|no) | Normally SA tests to see if it has access to a DNS server to do lookups. Since I know my server has access to DNS, I tell it to skip this test. It saves on initial amavis startup time. |
| Optional Score Increases | In this section, I turn up the value of several of the rules. The default score for a spam that turns up in the DCC database is only 2.756 when we're using Bayes and network checks. This seemed a little low for me, so I upped it to 4 points. If you wanted every message listed in the DCC database to be tagged as SPAM, you'd set this to 6.3 points. You can check the default scores for everything in the file /usr/local/share/spamassassin/50_scores.cf. You may see 4 different scores listed next to some rules. The file has different scores for whether or not you are using Bayes and network checks. When there is only 1 score, that score applies all the time, otherwise the 4th score is for bayes and network checks like we are using. |
| LOCAL_RCVD rules | see below |
LOCAL_RCVD rules
The last lines header, describe and score are used to prevent my outgoing mail from being tested for spam. If you're like me, your users would be upset if their mail was tagged as spam before a client read it. This rule basically checks the header for the Received from: lines showing the message route.
You will need to customize this rule to fit your system. To do this, send a message to your test hotmail account (or some account outside of your system). Check the headers for lines that look like this:
Received: from mta1.domain.com (mta1.domain.com [64.132.107.5]) by law122.ms.hotmail.com (8.12.6/8.12.2) with ESMTP id h3EI48pL002768 for <forge@hotmail.com>; Mon, 14 Apr 2003 14:04:08 -0400 (EDT) Received: from exchange.domain.com (exchange.domain.com [10.1.1.50]) by mta1.domain.com (Postfix) with ESMTP id F3B7117EFD for <forge@hotmail.com>; Mon, 14 Apr 2003 14:04:07 -0400 (EDT) Received: by exchange.domain.com with Internet Mail Service (5.5.2653.19) id <GKFZ3XPK>; Mon, 14 Apr 2003 14:04:03 -0400
The rule is a standard SpamAssassin rule and uses Regular Expression syntax. To explain it in regular terms, it looks for *.domain.com (*[*]) on the received line (where the stars are anything). When it finds a match, it gives the message a SPAM score of -50 (ensuring it is not counted as SPAM).
Note: The above LOCAL_RCVD lines are only needed if this server is being used to relay outgoing mail. If it is only handling incoming mail, it is recommended these three lines be commented out. One site found blockable spam was getting through and discovered the spammer had figured out and was adding Received lines that matched the customized regex rule the site was using, allowing the spam to get through with a -50 score for starters. Since the site was only using this server for incoming mail, removing these rules solved the problem.
Setting up AMAVISD user directories
Now we want to setup the amavisd and spamassassin home directory for the amavisd user.
mkdir -p /var/amavisd
chown amavisd.amavisd /var/amavisd
chmod 750 /var/amavisd
cd /var/amavisd
mkdir .spamassassin
touch .spamassassin/user_prefs
chown -R amavisd.amavisd .spamassassin
Copy the files we need to our amavisd chroot directory:
mkdir -p etc/mail/spamassassin usr/local/share
cp /etc/mail/spamassassin/local.cf etc/mail/spamassassin/
cp /etc/mail/spamassassin/init.pre etc/mail/spamassassin/
cp -r /usr/local/share/spamassassin usr/local/share
NOTE: (added 10-21-05 by sys32768) I upgraded to Spamassassin 3.1.0 and DCC and Razor2 stopped working.
DCC and Razor2 are now disabled by default in Spamassassin 3.1.0. You will need to do the following to enable DCC and Razor2 if you are running Spamassassin 3.1.0 or later.
vi /etc/mail/spamassassin/v310.pre
remove the # from the 2 lines shown below:
# DCC - perform DCC message checks. # # DCC is disabled here because it is not open source. See the DCC # license for more details. # loadplugin Mail::SpamAssassin::Plugin::DCC
# Razor2 - perform Razor2 message checks. # # Razor2 is disabled here because it is not available for unlimited free # use. It is currently free for personal use, subject to capacity # constraints. See the Cloudmark SpamNet Service Policy for more details. # loadplugin Mail::SpamAssassin::Plugin::Razor2
Then copy v310.pre to the amavisd chroot directory:
cp /etc/mail/spamassassin/v310.pre /var/amavisd/etc/mail/spamassassin/
(please reformat my note if needed. This is my first Wiki entry! Also please remove it if should not be here. sys32768)
NOTE: Spamassassin now provides a vXXX.pre file with every release, make sure you copy all .pre files to your chroot dir. besides the v310.pre file at this moment:
cp /etc/mail/spamassassin/v312.pre /var/amavisd/etc/mail/spamassassin/
and
cp /etc/mail/spamassassin/v320.pre /var/amavisd/etc/mail/spamassassin/
Check out the [Custom Rulesets page] to find a number of special rules you can install into your system. To install the ruleset, simply copy it to your /var/amavisd/etc/mail/spamassassin directory.
It is important to make sure your SpamAssassin configuration is correct. When finished, type
spamassassin --debug --lint
Which will output a verbose list of configuration information and will say if any warnings or errors were discovered. There is a lot of useful information in this list. You should scroll back through this list to see if all your perl modules are installed, etc.
Unfortunately I couldn't get Razor (http://razor.sourceforge.net) working correctly when not running as chroot. For some reason it had a hard time figuring out what its razorhome directory was (even though it was explicitly set in the config file). Fortunately it works great in chroot mode. If you are not going to run amavisd-new in chroot mode, you may want to just disable the Razor checks in your /etc/mail/spamassassin/local.cf file.
Note that the razor-admin program needs to go through a "discovery" phase, and if tcp port 2703 outgoing is blocked, it will hang.
You can either download and install Razor or install Razor via the ports tree.
To Download, dearchive, untar and compile Razor:
cd /root
ftp http://surfnet.dl.sourceforge.net/sourceforge/razor/razor-agents-2.82.tar.bz2
bunzip2 razor-agents-2.82.tar.bz2
tar -xvf razor-agents-2.82.tar
cd razor-agents-2.82
perl Makefile.PL
make
make test
make install
Or via the ports
cd /usr/ports/mail/razor-agents/
make install
You will need to create the default configuration files in /etc/razor regardless of how you installed Razor:
razor-admin -home=/etc/razor -d -discover
razor-admin -home=/etc/razor -d -create
razor-admin -home=/etc/razor -d -register
Copy the razor config files to the chroot directory
mkdir -p /var/amavisd/.razor
cp -r /etc/razor/* /var/amavisd/.razor
chown -R amavisd.amavisd /var/amavisd/.razor
You can enable or disable Razor by editing your /etc/mail/spamassassin/local.cf file: use_razor2 1
Razor has its own logfile in /var/amavisd/.razor called razor-agent.log. Unchecked, this file could potentially grow to fill your entire /var volume. Therefore, once you are sure that Razor is working properly, you will want to edit the Razor config to turn off logging. Unfortunately you can't use newsyslog to rotate this logfile without having to stop and restart amavisd. Edit /var/amavisd/.razor/razor-agent.conf and change:
debuglevel = 5
to
debuglevel = 0
then restart amavisd.
Download and extract the latest DCC (http://www.dcc-servers.net/dcc/). Note that the version may be different than the one written below.
NOTE: The link to www.dcc-servers.net was broken when I tried it on 10/23/2006. The DCC source is also available at http://www.rhyolite.com/anti-spam/dcc/ as an alternative.
cd /root
ftp http://www.dcc-servers.net/dcc/source/dcc-dccd.tar.Z
tar -zxvf dcc-dccd.tar.Z
cd dcc-dccd-1.3.44
./configure
make
make install
Make sure udp port 6277 is allowed out from this computer on your firewall.
/usr/local/bin/cdcc 'info'
If everything is working, you should see a bunch of lines like:
dcc.rhyolite.com, - RTT+0 ms anon
# 153.19.44.233,- coral.ely.pg.gda.pl WEiAPG? server-ID 1072
# 100% of 3 requests ok 1687.64+0 ms RTT 113 ms queue wait
# 192.188.61.3,- calcite.rhyolite.com Rhyolite server-ID 101
# 100% of 2 requests ok 755.52+0 ms RTT 50 ms queue wait
Since amavisd-new will be running in chroot mode, we need to copy DCC and all the files it needs to the chroot directory. The way DCC is called by SpamAssassin requires /bin/sh in order to work properly in [customized web design]. You should be aware that this requirement reduces the overall security of the system. Without /bin/sh, you'll receive this error when running amavisd debug: DCC -> check failed: no response
mkdir -p /var/amavisd/var /var/amavisd/usr/bin /var/amavisd/usr/libexec /var/amavisd/var/dcc
mkdir -p /var/amavisd/usr/lib /var/amavisd/bin
cp -r /var/dcc /var/amavisd/var/
cp /usr/local/bin/dccproc /var/amavisd/usr/bin
cp /usr/libexec/ld.so /var/amavisd/usr/libexec
chown -R amavisd:amavisd /var/amavisd/var/dcc
cp /bin/sh /var/amavisd/bin/
DCC uses several OpenBSD libraries, which we need to copy to the chroot directory. Since the version numbers on these libraries seem to change regularly, rather than just telling you which files to copy, you can run the following [custom essay] command:
ldd /usr/local/bin/dccproc
This will output something like this:
/usr/local/bin/dccproc:
Start End Type Ref Name
00000000 00000000 exe 1 /usr/local/bin/dccproc
00008000 2000f000 rlib 1 /usr/lib/libm.so.2.0
00019000 20063000 rlib 1 /usr/lib/libc.so.34.1
00002000 00002000 rtld 1 /usr/libexec/ld.so
Just copy the listed files (except dccproc) to their chroot directory under /var/amavisd. So for example, you would:
cp /usr/lib/libm.so.2.0 /var/amavisd/usr/lib/
cp /usr/lib/libc.so.34.1 /var/amavisd/usr/lib/
You can enable or disable DCC by editing your etc/mail/spamassassin/local.cf file: use_dcc 1
It's a plugin now, no?
add loadplugin Mail::SpamAssassin::Plugin::DCC in your etc/mail/spamassassin/init.pre
Installing amavisd-new is actually pretty simple once all the PERL required modules have been installed (which we did above).
To install amavisd-new, all we have to do is copy the perl code file where we want it, set the permissions and make it executable.
cd /root
ftp http://www.ijs.si/software/amavisd/amavisd-new-2.6.4.tar.gz
It is recommended to get the most recent recommended for general deployment version from:
http://www.ijs.si/software/amavisd/#download
tar -zxvf amavisd-new-2.6.4.tar.gz
cd amavisd-new-2.6.4
cp amavisd /usr/local/sbin/
chown root.wheel /usr/local/sbin/amavisd
chmod 550 /usr/local/sbin/amavisd
cp amavisd.conf /etc/
chown root.wheel /etc/amavisd.conf
chmod 644 /etc/amavisd.conf
touch /var/amavisd/amavis.log
chown amavisd.amavisd /var/amavisd/amavis.log
Edit the Amavisd-new configuration /etc/amavisd.conf and make the following changes (or simply create a new file and cut/paste the following:
use strict;
$MYHOME = '/var/amavisd';
$mydomain = 'domain.com';
$daemon_user = 'amavisd';
$daemon_group = 'amavisd';
$daemon_chroot_dir = $MYHOME;
$QUARANTINEDIR = "$MYHOME/quarantine";
$TEMPBASE = "$MYHOME/tmp";
$ENV{TMPDIR} = $TEMPBASE;
$helpers_home = $MYHOME;
$max_servers=8;
$child_timeout=20*60; # we need to adjust the timeout since it is not a localhost transfer
$forward_method = 'smtp:127.0.0.1:10025';
$notify_method = $forward_method;
$inet_socket_port = 10024;
$inet_socket_bind = '127.0.0.1';
@bypass_virus_checks_acl = (1);
read_hash(\%local_domains, '/etc/postfix/relay_domains');
$DO_SYSLOG = 1; # (1 = syslog, 0 = logfile)
$log_level = 5; # (0-5)
$final_spam_destiny = D_REJECT; # Set to D_REJECT, D_PASS to pass through
read_hash(\%whitelist_sender, '/var/amavisd/whitelist');
read_hash(\%blacklist_sender, '/var/amavisd/blacklist');
read_hash(\%spam_lovers, '/var/amavisd/spam_lovers');
#defending against mail bombs
$MAXLEVELS = 14;
$MAXFILES = 1500;
$MIN_EXPANSION_QUOTA = 100*1024;
$MAX_EXPANSION_QUOTA = 300*1024*1024;
$path = '/usr/bin:/bin';
$file = 'file';
$gzip = '/usr/bin/gzip'; # location of gzip on your system - Important!
$enable_db = 1; # enable use of BerkeleyDB/libdb (SNMP and nanny)
$enable_global_cache = 1; # enable use of libdb-based cache if $enable_db=1
# SpamAssassin settings
$sa_local_tests_only = 0;
$sa_auto_whitelist = 1; # comment this line out to turn off auto whitelist
$sa_mail_body_size_limit = 64*1024; # 64KB
$sa_tag_level_deflt = 3.0; # controls adding the X-Spam-Status and X-Spam-Level headers,
$sa_tag2_level_deflt = 6.3; # controls adding 'X-Spam-Flag: YES', and editing Subject,
$sa_kill_level_deflt = $sa_tag2_level_deflt; # triggers spam evasive actions:
$sa_spam_subject_tag = '***SPAM*** ';
$sa_debug = 1; # comment this line out to turn off debugging
1; # insure a defined return
*Added by kuropon 1/27/09* I was getting some errors on startup of amavisd about DKIM. I just went into the config and set the two dkim options to 0. It's default to 1 using 2.6.2, but additional steps seem to be required to get DKIM to work.
| $MYHOME, $mydomain | These are really just variables used in this config file so we don't have to type the same things over and over again. MYHOME is our default work directory, mydomain is the name of our domain. |
| $daemon_user, $daemon_group | This is the user and group that amavisd and all its helper programs will run under for security reasons. |
| $daemon_chroot_dir | This option tells amavisd to run in chroot mode. Chroot is a security trick that traps the program in a certain directory, in our case $MYHOME. By turning this on, amavisd will not be able to access anything on the computer other than what is in the /var/amavisd directory. |
| $QUARANTINEDIR | This is the location where amavisd would place quarantine files if you were using it for virus scanning. Even though we aren't virus scanning, it is still needed, because if $spam_final_destiny is set to D_REJECT, it's dropped here. |
| $TEMPBASE | When amavisd does its thing, it creates a bunch of temp files. Normally it would just store them in $MYHOME. By storing them in $MYHOME/tmp, we can easily cleanup the temp directory whenever we need to by stopping amavisd and deleting everything in $MYHOME/tmp/* |
| $ENV{TMPDIR}, $helpers_home | I found that both of these setting help SpamAssassin, Razor and DCC work better by explicitly telling these helper programs their home and tmp directories. |
| $max_servers | Specifies the number of instances of amavisd child processes to spawn. You should increase or decrease this number depending on how much memory your PC has installed. Make sure that this number is synchronized to the smtpd maxproc setting in the postfix/master.cf file (so that you don't end up with postfix trying to connect to a non-existant queue). |
| $child_timeout | Here we need to increase the timeout for the amavisd process. The default is only 8 minutes. When amavisd is used with other mail packages in a post queue structure, the message is transferred locally only (from the local mail queue to the amavisd loopback) and is therefore very fast. When we use the postfix before-queue filter, the message is being transferred directly from the remote smtp through postfix to amavisd . So for example if the remote smtp is sending a 20 megabyte message, it may take longer than 8 minutes to transmit the message (depending on network bandwidth). In my testing, amavisd would timeout before the message had been transferred and the end user would get the following message: Out: 451 Error: queue file write error. Note that you may want to increase this limit even further if you see this error message from Postfix. |
| $forward_method, $notify_method, $inet_socket_port, $inet_socket_bind, $inet_acl | These settings set up the communications between amavisd and postfix. Basically the two programs communicate using different ports. Postfix sends email it wants to filter to amavisd on port 10024. Amavis processes the message and returns it to postfix on port 10025. The $inet_acl setting makes sure that it accepts only packets from the local computer. |
| @bypass_virus_checks_acl | Since we won't be using the anti-virus features of amavisd, this line is used to turn them off. |
| read_hash(\%local_domains, '/etc/postfix/relay_domains'); | This setting tells amavisd to check the same file that postfix does to get a list of your local domains. Now you only have to keep track of this single file when you have multiple domains! |
| $DO_SYSLOG, $log_level | These settings describe how amavisd should do logging for debugging. The $log_level can be set from 0-5 with 5 producing the most logging output. You should also note that when running amavisd in debug mode, logging doesn't occur to the syslog. Note: if you want to have amavisd log to /var/log/messages instead of /var/log/maillog, you can add a config line here: $SYSLOG_LEVEL = 'user.info'; |
| $final_spam_destiny | You should set this to either D_REJECT or D_PASS. When set to D_PASS, the spam will be delivered to your users. They can then setup inbox assistant rules looking for the X-Spam-Flag header to move the messages to another folder, or delete the messages. The D_REJECT setting will cause the email message to be saved in the quarantine directory. You can also configure D_BOUNCE mode, see the amavisd documentation for more info. At my company, we used the D_PASS method for the first 60 days after turning on SpamAssasssin? to make sure everything was working right (auto-whitelisting had been done, and the bayesian db had been built). Then we switched over to D_BOUNCE mode. Once postfix supported before-queue filtering, we switched to D_REJECT mode. |
| read_hash(\%whitelist_sender, read_hash(\%blacklist_sender, read_hash(\%spam_lovers | These settings point to 3 files that identify our whitelist, blacklist and spam lovers. Each file should have 1 email address (or part of an email address) per line. The whitelist identifies senders that should always be passed through even if they are identified as spam. The blacklist identifies senders that should always be marked as spam. The spam_lovers identifies our users that want to opt-out of our system and receive all their spam. Note that these files are read only on startup of amavisd, so if you edit them be sure to stop and restart amavisd. Also, not shown here is the ability of amavisd to support per-recipient whitelists and blacklists and MySQL? based whitelists and blacklists. |
| $MAXLEVELS, $MAXFILES, $MIN_EXPAN... | This whole section is part of the anti-mail bomb measures of the anti-virus software. I thought it should be kept in there just in case. |
| $path | Tells amavisd where to look for programs it needs. |
| $file | Tells amavisd the name of the file program. |
| $gzip | Tells amavisd where to find the gzip program. Gzip is used to save compact suspected spam that is quarantined. If this variable is not defined, you'll get less than lucid error messages in your log file that will baffle you for a while. |
| $enable_db, $enable_global_cache | Settings to turn on the BerkeleyDB usage in Amavisd. |
| $sa_local_tests_only | Set this to 1 to disable DCC and Razor for debugging. The default for this is false, so I initially didn't include it in my config file, but I have been told that leaving it out causes problems. |
| $sa_auto_whitelist | Great feature of spamassassin that automatically whitelists people that send you lots of non-spam mail. |
| $sa_mail_body_size_limit | Since few spammers send large attachments, we don't even bother checking messages over a certain size (in this case 64KB). |
| $sa_tag_level_deflt, $sa_tag2_level_deflt, $sa_kill_level_deflt | As you know, SpamAssassin assigns each email a positive or negative score to indicate its "spamminess" (yes I know it's not a word). These settings tell SA when to take anti-spam measures. At the tag level, the message's headers are modified with the spam score. At the tag2 level, in addition to the actions from the tag level, it adds a header indicating that the message is spam, and it modifies the subject. At the kill level, the system will take action based on the $final_spam_destiny setting. In most cases, you want tag2 and kill to happen to any message that is spam, so they are usually equal. |
| $sa_spam_subject | This text is added to the front of any spam message that receives a high enough score. |
| $sa_debug | This setting turns on spamassassin debugging. Comment it out once everything is running smoothly for better performance. |
Next we need to create the directories used by amavisd:
mkdir /var/amavisd/tmp
chown amavisd:amavisd /var/amavisd/tmp
chmod 750 /var/amavisd/tmp
mkdir /var/amavisd/quarantine
chown amavisd:amavisd /var/amavisd/quarantine
chmod 750 /var/amavisd/quarantine
mkdir /var/amavisd/db
chown amavisd:amavisd /var/amavisd/db
chmod 750 /var/amavisd/db
Now we want to do everything needed to run amavisd-new in a chroot jail (you can skip this step if you want, but just make sure you comment out the $daemon_chroot_dir setting in the amavisd.conf file with a #). Please note that I'd advise you to do these steps since it makes your system more secure.
Note that all the commands in this next section assume that you are in the /var/amavisd directory:
cd /var/amavisd
Make the default root folders:
mkdir -p etc dev tmp var/run bin
mkdir -p usr/bin usr/share/zoneinfo usr/lib usr/libexec
Next you want to setup a dev/null device. To make this device work, you have to remove the nodev restriction on that filesystem and remount it. To do this, edit the /etc/fstab file. Look for the line where you mount the /var partition and remove the word nodev and the extra comma.
vi /etc/fstab
for example, change
/dev/wd0g /var ffs rw,nodev,nosuid 1 2
to
/dev/wd0g /var ffs rw,nosuid 1 2
If you do not do this, amavisd will report problems when invoking the command /bin/file p001 < /dev/null [etc.] (Ask me how I know... /Jokke)
reboot
cd /var/amavisd
mknod dev/null c 2 2
Setup a symbolic link so the chrooted process can refer to /var/amavisd and still get the files in /var/amavisd (which would then be /)
ln -s / var/amavisd
Copy the configuration files for our system to our chroot etc directory. Please note that if you ever make any changes in the originals you will need to copy them again to this directory.
cp /etc/protocols /etc/services /etc/hosts /etc/magic /etc/resolv.conf /etc/group /etc/passwd /var/amavisd/etc
Copy the file executable to the chroot directory.
cp /usr/bin/file /var/amavisd/bin
cp /usr/lib/libc.so.38.2 /var/amavisd/usr/lib/.
cp /usr/libexec/ld.so /var/amavisd/usr/libexec/.
*Added by kuropon 1/27/09* file in the chroot
File actually needs more than just libc.so, make sure to run ldd /usr/bin/file to see what all it needs and copy it to your chroot. libmagic.so and libz.so are also needed.
*Added by paulb* Correction of check_mail: spam_scan FAILED: panic: swash_fetch error.
You need to copy some files into your CHROOT folder in order to have perl work correcly with UTF-8 Data
mkdir -p /var/amavisd/usr/libdata/perl5
cp -pR /usr/libdata/perl5/unicore/ /var/amavisd/usr/libdata/perl5
Create a dummy pwd.db file:
echo amavisd:*:3000:3000::0:0:Amavis Mail Scanner Daemon:/var/amavisd:/sbin/nologin>/var/amavisd/etc/master.passwd
Some may need to add quotes to that last line, thusly:
echo "amavisd:*:3000:3000::0:0:Amavis Mail Scanner Daemon:/var/amavisd:/sbin/nologin">/var/amavisd/etc/master.passwd
pwd_mkdb -d /var/amavisd/etc/ -p /var/amavisd/etc/master.passwd
Set strict permissions. Note that amavisd must own its home directory (/var/amavisd) otherwise it will generate permissions errors.
chown -R root.wheel etc dev tmp usr var
chown -R amavisd:amavisd .spamassassin .razor quarantine var/dcc
chmod 1777 tmp
chmod 666 dev/null
To enable logging to syslogd you must append the following line within your /etc/rc.conf(.local):
"-a /var/amavisd/dev/log"
Which for a fresh OpenBSD might mean just adding to /etc/rc.conf.local:
syslogd_flags="-a /var/amavisd/dev/log"
*REMINDER* Once you are running amavisd in chroot mode, your configuration files are located in your new root directory. Be sure when you make changes that you are editing the correct files....otherwise you'll wonder why your changes aren't working. Also make sure when you copy them that the permissions are set correctly.
Create our whitelist, blacklist and spam_lovers files. These files are lists with 1 email address or domain per line (in lower case), of recipients and senders that we want to treat specially. Senders in the blacklist file are automatically marked as SPAM. Senders in the whitelist file are never marked as SPAM. Recipients in the spam_lovers are basically your users that want to opt-out of the spam blocking system.
touch /var/amavisd/blacklist
touch /var/amavisd/whitelist
touch /var/amavisd/spam_lovers
You will want to add your postmaster account into the spam_lovers textfile. One of the RFCs for email states that the postmaster account should always accept email.
echo postmaster@domain.com >> /var/amavisd/spam_lovers
Finally, go ahead and add amavisd to the local startup script. Edit the /etc/rc.local file and add the following lines to the bottom. Technically you will want to start this before postfix.
# Start amavisd spam filter echo -n ' amavisd'; /usr/local/sbin/amavisd
Here is the working diff with vanilla amavisd:
--- amavisd Mon Apr 3 18:32:34 2006
+++ amavisd-2.4.0 Mon Apr 10 11:31:27 2006
@@ -7664,12 +7664,14 @@
$r->recip_destiny($final_destiny);
my($status_and_reason) = $r->setting_by_contents_category({
CC_VIRUS,
- ["550 5.7.1", "VIRUS: ".join(", ", @virusname)],
+ ["550 5.7.1", "Message rejected: VIRUS: ".join(", ", @virusname) .
+ ". Contact postmaster\@domain.org in case of problems."],
CC_BANNED,
- ["550 5.7.1", "BANNED: ".join(", ",@{$r->banned_parts || []})],
+ ["550 5.7.1", "Message rejected: BANNED: ".join(", ",@{$r->banned_parts || []}) .
+ ". Contact postmaster\@domain.org in case of problems."],
CC_SPAM,
- ["550 5.7.1", "SPAM". ($r->recip_blacklisted_sender ?
- ', sender blacklisted' : '')],
+ ["550 5.7.1", "Message rejected: SPAM". ($r->recip_blacklisted_sender ? ', sender blacklisted' : '') .
+ ". Contact postmaster\@domain.org in case of problems."],
CC_BADH.",1",
["550 5.6.3", "BAD_HEADER: ".(split(/\n/,$bad_headers[0]))[0]],
CC_BADH,
As a default, the sender of a message that has been rejected will receive a bounce message that looks something like this:
From "Mail Delivery Subsystem" MAILER-DAEMON@mail.somecompany.com Subject Returned mail: see transcript for details Date Sat, May 1, 2004 8:57 pm To person@somecompany.com -------------------------------------------------------------------------------- ----- The following addresses had permanent fatal errors ----- < sentto@domain.com > (reason: 550 5.7.1 Message content rejected, UBE, id=3452) ----- Transcript of session follows ----- ... while talking to mta.domain.com.: >>> DATA <<< 550 5.7.1 Message content rejected, UBE, id=3452 554 5.0.0 Service unavailable
Obviously this error message is not very helpful to end users. At my company, we customized this line to include a website and phone number that the user could call:
550 5.7.1 Message content rejected:looks like SPAM. Visit http://www.domain.com/spam or call 704-555-1212
Here is an example of the website we refer people to: http://www.flakshack.com/anti-spam/whitelist.html. Please feel free to copy this page as a template. Obviously the form on this example won't actually work without something on the back end to process the form.
To customize this SMTP error output line, you must edit the amavisd code. You should have installed this as /usr/local/sbin/amavisd. In the current version this is lines 6365-6366 (for spam) and 6409-6410 (for blacklist). In general you can find the location by searching for "5.7.1"
Change:
: "550 5.7.1 Message content rejected, $reason")
. ", id=$am_id");
To:
: "550 5.7.1 Message content rejected:looks like SPAM. Visit http://www.domain.com/spam or call 704-555-1212") );
There is a limit to the number of characters you can put into this error line. After editing it, you should test on your own to see what works. Just be sure to leave the 550 5.7.1 codes on that line.
Troubleshooting Queue File Write Errors
Here are some general directions for testing your system.
While testing, run Amavisd in debug mode (make sure it is stopped first). You'll also want to make sure that $sa_debug = 1; in your amavisd.conf so you can see the SpamAssassin output.
To make examining the output easier, click on PuTTY's control box menu (the top left) and choose Clear Scrollback. You may need to change PuTTY's default window settings to increase the size of the scrollback buffer so that you can see all of the output.
cat /var/amavisd/amavisd.pid | xargs kill
clear
/usr/local/sbin/amavisd debug
Look at the output to see if there are any error messages. Continue watching the output as you send messages through the system. When you are finished, press CTRL-C to stop the process. You can then start amavisd in regular background mode. Note that amavisd does not log to the maillog when launched with the debug parameter.
/usr/local/sbin/amavisd
Here is a VB script that you can use on any Windows XP machine to send test messages directly to your MTA. Just create a text file called "test.vbs" and paste the following code into it. Modify the variables for your specific setup, and double-click on the file.
sTo = "your_real_address@domain.com"
sFrom = "nobody@madeup.address.local"
sSubject = "This is a test message"
sMTA_IP_Address = "10.2.1.50"
sMessage = "This is a test message with the following word to trigger the spam flag: myspamtest12341234."
Set objCDO = CreateObject("CDO.Message")
objCDO.From = sFrom
objCDO.To = sTo
objCDO.Subject = sSubject
objCDO.HTMLBody = sMessage
objCDO.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
objCDO.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserver") = sMTA_IP_Address
objCDO.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
objCDO.Configuration.Fields.Update
objCDO.send
Set objCDO = nothing
If the message is rejected, you will see a message box like this one:
On OpenBSD 3.7 (and earlier?) with default gzip installed you might see something like
spam quar+notif FAILED: Closing pipe to /usr/bin/gzip: DIED on signal 127 (ffffffff), Broken pipe at /usr/local/sbin/amavisd line 3567
instead of shown above "Message content rejected: looks like SPAM...".
The issue can be resolved by putting GNU gzip into jail (taken from http://www.screamingelectron.org/forum/archive/index.php/t-2018.html):
after help from elmore the solution has been found. elmore pointed me out to http://www.harrysufehmi.com/phpwiki/index.php/OpenBSDFullyLoaded which about midway shows installation of GNU gzip. There's also a patch for OpenBSD's gzip so it returns the value that amavisd is expecting. I didn't install the patch. I used GNU gzip and copied the executable (after first making sure ldd didn't show any different req'd libs) to /var/amavisd/bin (this is my chroot jail). Because of the chroot jail I didn't bother with editing /usr/libdata/perl5/CPAN/Config.pm because the /usr/bin/gzip is still the default OpenBSD gzip and the /var/amavisd/bin/gzip is the GNU one.''
So the steps to install GNU gzip into amavisd jail are:
wget ftp://wuarchive.wustl.edu/mirrors/gnu/gzip/gzip-1.2.4.tar
tar xvf gzip-1.2.4.tar
cd gzip-1.2.4
./configure --prefix=/usr/local/gzip-1.2.4
make
cp -p gzip /var/amavisd/usr/bin
If you want to create a message that fails a SpamAssassin test, simply add the following lines into your /var/amavisd/etc/mail/spamassassin/local.cf file:
body LOCAL_TEST1 /myspamtest12341234/ describe LOCAL_TEST1 This is a unique phrase to trigger a positive score score LOCAL_TEST1 50
After editing the file and restarting amavisd, simply put the phrase "myspamtest12341234" in text of the message above and it should read as SPAM.
One handy thing to know is that if you run tests from a real account, it may get added to the auto-whitelist (with a positive score). If you need to use this real account, this can be bad, since all your email will start being rejected. To fix this:
spamassassin -p /var/amavisd/.spamassassin/user_prefs --remove-addr-from-whitelist=mytestaddress@mydomain.com
Our last step in this process is to setup email summary reports. Once a day, right before the maillog is rotated with newsyslog, we'll run a program on the maillog to generate a nice summary report and email it to root. There are a couple different reporting scripts for postfix available on http://freshmeat.net. I didn't try them all because pflogsumm.pl (http://jimsun.linxnet.com/postfix_contrib.html) worked fine and did what I wanted.
To get this running, simply download the .pl file from his website, check the MD5 signature to make sure it matches, make it executable, and add it to the crontab.
cd /root
ftp http://jimsun.linxnet.com/downloads/pflogsumm-1.1.0.tar.gz
md5 pflogsumm-1.1.0.tar.gz
tar -xvzf pflogsumm-1.1.0.tar.gz
mv pflogsumm-1.1.0/pflogsumm.pl /usr/local/sbin/pflogsumm-1.1.0.pl
chmod 500 /usr/local/sbin/pflogsumm-1.1.0.pl
Every night at midnight, the newsyslog program rotates out the maillog file. As part of its process, it renames the /var/log/maillog file to /var/log/maillog.0 then gzips it. We want our script to unzip this file, process it and generate the report, then zip it up again. To do this we'll create a new script file.
vi /usr/local/sbin/my-postfix-report.sh
Add the following lines into this file:
#!/bin/sh zcat /var/log/maillog.0.gz |/usr/local/sbin/pflogsumm-1.1.0.pl | mail -s "Report" root
Change permissions on the file to make it executable.
chmod 500 /usr/local/sbin/my-postfix-report.sh
Now edit root's crontab:
crontab -e
Add the following line to root's crontab to run our new script every day at 4:00 AM:
0 4 * * * /usr/local/sbin/my-postfix-report.sh
I have written a perl script that also generates several reports (in the same format as pflogsumm) about your spam. The reports include:
1. All spam senders listed by SA Score,
2. All spam sender domains listed by number of messages,
3. All recipients by number of messages, and
4. Total number of spam.
I'm no perl expert, but this script runs fine on my system. You can download it (and all my other scripts) from the bottom of this doc. If you want to use it, just copy the my-spamreport.pl and my-postfix-report.sh files over top of the ones you have already created. (I updated the my-postfix-report.sh script so that it includes the spam report in a single email message).
Update: Kris Nosack has written an updated version of my script to include percentages. You can download this new version of the script here: http://www.xmission.com/~kn/AddClamAV/my-spam-report.txt.
I've also written a script (http://www.flakshack.com/anti-spam/my-summary.pl) that will count the total number of messages, spam and size per day and store it in an ongoing file. You can then download this file and load it into Excel to graph your spam. Here's an example of the output (date, number of messages sent, total bandwidth of all messages, number of blocked spam):
1/3/2004,18099,363151k,5894 1/4/2004,16176,106379k,6370 1/5/2004,16083,90243k,6449 1/6/2004,25380,609m,6147 1/7/2004,26420,708m,6272
To disable amavisd, all you have to do is comment out the line in the master.cf that directs postfix to pass incoming mail through its filter. Locate the smtpd_proxy_filter line and put a comment (#) symbol in front of it.
#-o smtpd_proxy_filter=127.0.0.1:10024
Now just run postfix reload and all incoming mail will now just be routed normally.
The configuration as described is for a PC with 256 MB of RAM and will allow your mail server to accept 8 incoming connections at one time. Once those 8 connections are in use, any further connections will be refused. In this case, the remote SMTP client should continue trying to deliver the message to your mta until it times out, usually in 5 days. If you have less than 256 MB of RAM, you must reduce the number of amavisd and postfix servers, otherwise you will overwhelm the computer (usually amavisd or postfix crashes). If you have more than 256 MB of RAM, you can increase the number of servers to allow for more connections at one time.
You can use the following directions to boost or reduce the number of connections the server can accept at one time. After you make a change, you will want to check your system memory usage using top. When you run the top command, you will see a line that looks something like this:
Memory: Real: 113M/144M act/tot Free: 103M Swap: 0K/512M used/tot
The important number here is the one labeled "Free." It shows how much free memory is available on your computer. The line above was taken from one of my server running 8 processes. As you can see we are currently using 144 MB of RAM and have 103 MB free. I could probably run 10-12 servers instead of 8, but I like to play it safe.
Since there need to be enough amavisd processes to handle each smtpd process, you need to make sure that you have configured the same number in both locations.
vi /etc/amavisd.conf file and edit the following line:
$max_servers = 8;
The default when this line is not present is 2. Increase or decrease the number as needed.
Now edit /etc/postfix/master.cf. Look for the line that says:
| smtp | inet | n | - | y | - | 8 | smtpd |
And increase or decrease the maxprocs count for the smtpd line to match the number of amavisd servers you just indicated in the amavisd.conf.
Restart amavisd and postfix. Run the top command, press the "o" key and type "res" to sort the display by memory usage. Be sure to watch the display as mail is delivered through the system, since more memory is used by a running system than by an inactive one.
If you are using OpenBSD for this system, you may wish to consider increasing the maximum number of filehandles allowed by the system. I've been running systems that were working fine one minute, and the next, they slowed to a crawl, with 5+ hour mail delivery times because of this.
You will know it's this because dmesg or the console should show multiple errors like:
file: table is full
Use sysctl -a kern.maxfiles to see what you have it set to, and then use sysctl -w to modify the setting. Use "man systctl" to learn more about this powerful tool.
I set my system to allow 16,384 files and the mail delivery problem disappeared.
Here are some quotes from people that are using these directions with notes on their performance.
Scott Vintinner's Performance:
We run 2 of these systems for redundancy and load balancing. Both are Pentium III, 900 mhz Dell PowerEdge? Rackmount systems with 256 MB ram and 20 GB HD. On an average week day, each server delivers 700-1000 MB of email (according to my maillog reports) which is usually around 12,000 messages each. Each server detects and blocks about 6000 SPAM messages per day. Performance with this setup seems to be great...no complaints. Load balancing and redundancy is setup by configuring both servers' MX records with the same weight, and by configuring my Exchange server's SMTP connector smart host setting with both addresses (mta1.domain.com;mta2.domain.com).
Adding multiple domains has become much easier. In the examples below, I've added a new domain which I called "domain2.com" to the system.
1. vi /etc/postfix/relay_domains
Add each domain you wish to receive email for on a single line in this file. This single file is now used by both Postfix and Amavisd!
You will want to list each of them on a separate line in this file. Remember to add OK with a space separating the OK and the domain name or else you will get an "expected format: key whitespace value" error when you go to run postmap.
domain.com OK domain2.com OK
NOTE1: You probably need to run postmap /etc/postfix/relay_domains, otherwise you may find the following in the maillog:
fatal: open database /etc/postfix/relay_domains.db: No such file or directory
2. vi /etc/postfix/transport
Here is where you tell postfix where to send email for that domain. So add the new domain(s) under the one you already added:
domain.com smtp:[10.1.1.50] domain2.com smtp:[10.1.1.50]
Run postmap after editing the transports file:
cd /etc/postfix
postmap transport
3. Do not forget to edit the amavisd.conf file. Spam-related headers are only inserted for local recipients. You will need to add the additional domains to @local_domains_maps= if you want to add X-Spam headers.
Please refer to the commented section in amavisd.conf for correct syntax. This is critical or you will break your filter.
This section will include tips on operating systems other than OpenBSD. If you get this system working on any other OS and want to include your OS specific changes, include them here.
Slackware (tips by Derek Shaw)
When creating the symbolic link in the chroot directory, he advises using the following command:
cd /var/amavisd && mkdir var && ln -s ../ var/amavisd
DCCifd install on Slackware (tips by Olivier Renard)
In a amavis chroot environnement (generally /var/amavisd), dcc must be compiled with home and rundir inside the chroot jail path.
./configure homedir=/var/amavisd/dcc with-rundir=/var/amavisd/dcc
don't forget then to modify the local.cf SA configuration file in order to specify the dccifd socket and home path
dcc_home /var/amavisd/dcc
__________________________________________________________________________________
__________________________________________________________________________________
On FreeBSD?-5.3, I had to copy the Mail::SpamAssassin files (from /usr/local/lib/perl5/site_perl/5.8.5) into the chroot directory, in order to get amavisd to start successfully. I put them in /var/amavisd/lib, since /lib was part of the include path. (Tim Buck)
__________________________________________________________________________________
I have setup the system in a so-called "zone" on SUN Solaris. (The zones are very similar to the jails of BSD). As it runs in a zone, chroot is not necessary, the rest is configured as described. I've found the following little caveats during the installation:
- It's impossible to use the pre-installed perl, since this one is compiled with SUN's compiler cc, and you can't install new modules. Instead, install a perl compiled with gcc (e.g. from sunfreeware.com)
- Due to this, all scripts including amavis itself have to changed to use /usr/local/bin/perl instead of /usr/bin/perl. Otherwise, they will not find the necessary modules...
- I have to run clamav as user "amavis" instead of "clamav", otherwise, clamav has no permission to read the e-mails (Harald Husemann)
__________________________________________________________________________________
Microsoft Exchange 2000 / 2003 Integration
I have cobbled together a VBScript that will extract all of the 'proxyAddresses' (the unicode attribute that holds the different smtp: addresses for each user) for every user and group in your base active directory domain.
The script then writes this out to a file called relay_recipients, then uses Putty to copy the file to the server, run postmap, and run a postfix reload command.
It is meant for admins to run manually every time they enter a user into Active Directory.
http://www.castellan.net/extract_exchange/default.htm
__________________________________________________________________________________
VMWare Version of the spam filter
Someone created a CentOS? Linux version of the spam filter instructions on this webpage. I have modified it, and posted it. It is a full VMWare machine, using the free version of VMWAre server. That means you can setup this entire thing in 5 minutes of time.
http://www.thefreespamfilter.com
In order to make it easier for others to add bug fixes to the scripts, they are placed here in the WIKI (click below to access each script). In general, the easiest way to get these scripts onto your server is to use PuTTY. Here are some quick steps.
Select the text of the script and copy it to your clipboard. Then using a console session via PuTTY:
Right click on the screen to paste the contents of the clipboard.
Press "Shift-Z, Shift-Z" to save and exit.
Then type:
Perl Module Test Script - This script will test to see if all nessicary perl modules are installed.
Restart Script - This script will restart amavisd and postfix in the proper order.
Postfix Report - This script is a wrapper for several other scripts to generate and email a daily report.
Spam Report - This report is called by the Postfix report to generate information about detected spam.
(Spam Report ala Kris)? - Spam report modified by Kris Nosack to show a breakdown of spam scores by volume and percentage.
Spam Summary Report - This simple report can be used to create summary graphs of spam data in Excel.
[postfix-logwatch/amavis-logwatch] - Postfix and amavis reporting and statistics.
[Online degree]-If you are interested in adding anti-virus support, you may print the directions from this page: http://flakshack.com/anti-spam/wiki/index.php?page=FairlySecureAntiSpamWikiPrintView
[http://cheilitistreatment.com angular cheilitis treatment
[http://www.mustuniversity.com/schools-majors/ online degree school
[Web hosting] Terms
This web site is ©2004 by Scott Vintinner (and others: Full list of contributors) and is released under the OpenContent License (shown below). By contributing to this web site, you agree that your contributions are also released under this license.
OpenContent License (OPL)
Version 1.0, July 14, 1998.
This document outlines the principles underlying the OpenContent (OC) movement and may be redistributed provided it remains unaltered. For legal purposes, this document is the license under which OpenContent is made available for use.
The original version of this document may be found at http://OpenContent.org/opl.shtml
LICENSE
Terms and Conditions for Copying, Distributing, and Modifying
Items other than copying, distributing, and modifying the Content with which this license was distributed (such as using, etc.) are outside the scope of this license.
1. You may copy and distribute exact replicas of the OpenContent (OC) as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the OC a copy of this License along with the OC. You may at your option charge a fee for the media and/or handling involved in creating a unique copy of the OC for use offline, you may at your option offer instructional support for the OC in exchange for a fee, or you may at your option offer warranty in exchange for a fee. You may not charge a fee for the OC itself. You may not charge a fee for the sole service of providing access to and/or use of the OC via a network (e.g. the Internet), whether it be via the world wide web, FTP, or any other method.
2. You may modify your copy or copies of the OpenContent or any portion of it, thus forming works based on the Content, and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified content to carry prominent notices stating that you changed it, the exact nature and content of the changes, and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the OC or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License, unless otherwise permitted under applicable Fair Use law.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the OC, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the OC, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Exceptions are made to this requirement to release modified works free of charge under this license only in compliance with Fair Use law where applicable.
3. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to copy, distribute or modify the OC. These actions are prohibited by law if you do not accept this License. Therefore, by distributing or translating the OC, or by deriving works herefrom, you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or translating the OC.
NO WARRANTY
4. BECAUSE THE OPENCONTENT (OC) IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE OC, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE OC "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK OF USE OF THE OC IS WITH YOU. SHOULD THE OC PROVE FAULTY, INACCURATE, OR OTHERWISE UNACCEPTABLE YOU ASSUME THE COST OF ALL NECESSARY REPAIR OR CORRECTION.
5. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MIRROR AND/OR REDISTRIBUTE THE OC AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE OC, EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.