SpamAssassin 3.0

[5280Toad]

Anyone setup SpamAssassin 3 on Panther Server yet? Care to share your successes/issues?

[brossow]

Not to hijack the thread by any means, but I can tell you that 3.0 doesn’t work as a drop-in replacement for 2.x in the installation described in the article on this site. When I went from 2.64 to 3.0 yesterday on my OSXS 10.2 server with the latest Exim, spam filtering stopped entirely. Had to revert to the previous version.

[Anonymous]

Haven’t set it up on Panther server yet, but on Panther client, I found that you must have the latest developer tools (XCode 1.5) installed for a succesful compile.

[Clark Wilkins]

I am very new to the Xserve and tried to get this running as well. I think it’s
damn near hopeless for an inexperienced admin to succeed without some
step by step instructions.

I tried to use http://developer.apple.com/server/fighting_spam.html as a
reference.

The problems I ran into (that I know about) are:

the step for building razor-agents fails:

www:~/Desktop/razor-agents-2.61 jdis$ sudo perl makefile.PL
Warning: prerequisite Digest::SHA1 0 not found.
Writing Makefile for Razor2::Preproc::deHTMLxs
Writing Makefile for razor-agents

and trying the first level test for spamassassin as recommended on the site
fails:

razor2 check skipped: Can’t locate object method "new" via package
"Razor2::Client::Agent" at ///Library/Perl/5.8.1/Mail/SpamAssassin/Dns.pm
line 430.
Use of inherited AUTOLOAD for non-method Digest::SHA1::sha1_hex() is
deprecated at ///Library/Perl/5.8.1/Mail/SpamAssassin/Bayes.pm line 983.

I have not gotten any further than this.

/s clark 😳
(who needs a copy of Xserve for Dummies t help him clean up after having paid the "best" Mac consultant in the area to come out and F___ up our system)

[Clark Wilkins]

Can it be that nobody has been able to make this work yet?

[bustthis]

i would say that the apple article is a bit dated and there seems to be a new one here: http://developer.apple.com/server/virusfiltering.html

but, it seems you haven’t done any footwork because there is a very good article on this site about installing spamassassin, amavis, and clamav. i wouldn’t waste your time on trying to get razor to work.

i would suggest following joel’s article, apple’s new article and when you run into problems, search google, join some mailing lists… and yes it will work, but what do i know 🙂

[Spectrum]

I’ve done it and made it work with Postfix as a relay server in my DMZ.

It’s a lot of brain damage and somewhat time consuming. I’ll try to write something up over the weekend and post a reply on how to do it.

[Anonymous]

I installed clamav, amavis and SA by following the article on this site (excellent, thank you). Since then , all three elements have been superceded by later versions. Is there a preferred order or method for upgrading them all?

Thanks

Fraser

[Spectrum]

My apologies for not getting this done sooner. Life has gotten a bit crazy here as we just completed a migration from Novell to some XServes. 🙂

Anyway, I’ve barely proofread this, but I believe it to be correct and complete:

Basically, it requires that you nuke postfix-watch, create custom transport tables and relay tables in /etc/postfix/main.cf and add a custom pipe filter in /etc/postfix/master.cf. You’ll also need to invoke a shell script to do the pass off to spamc/spamd and retransmit the e-mail with postfix-sendmail to the final recipient. If your server is acting as a relay (like mine), you need to make sure that it can resolve the FQDN of the internal server, that you have local DNS MX records that point at your internal server and that the relay server relies on that information.

If you plan to use the tarball to compile SpamAssassin, you’ll need Xcode installed on your machine.

SpamAssassin requires an ton of perl modules to be installed prior to compilation/installation. Get them from CPAN.

SpamAssassin requires /etc/mail/spamassassin to exist. It doesn’t in OS X, so create it.

Now either make, or install SpamAssassin per the included READMEs.

Check SpamAssassin’s functionality before you go any further (spamassassin -t command). If SA isn’t working properly, you’ll be wasting your time.

After SpamAssassin is installed and successfully tested, you need to modify the postfix configuration files. They are located in /etc/postfix.

Lets start off with main.cf. As I’m accustomed to working in *nix, I use vi as my editor, use whatever you like. You’re basically recreating the entire file, but you will include some existing lines.
Here’s mine (edited with <yourstuffgoesinhere> tags):
============================================
# declarations
queue_directory = /private/var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
sendmail_path = /usr/sbin/sendmail
newalias_path = /usr/bin/newalias
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix/examples
readme_directory = /usr/share/doc/postfix
#
mail_owner = postfix

# hostname entry
myhostname = <FQDN of this server> # Enter the FQDN of this server here. It MUST resolve.
# domain entry
mydomain = <your domain name> #Enter your domain name here.

# configuration lines
myorigin = <your domain name> # Enter your domain name here.
mydestination = $myhostname,localhost.$mydomain,
mynetworks = <enter your public/private networks here> # Enter ALL your public/private nets in a comma separated list. You can use CIDR masks (i.e., x.x.x.x/24)
relay_domains = <your domain name> #Enter your domain name here
parent_domain_matches_subdomains =
debug_peer_list smtpd_access_maps
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination,permit
relay_recipient_maps = hash:/etc/postfix/relay_recipients
transport_maps = hash:/etc/postfix/transport
local_recipient_maps =
local_transport = error:local mail delivery is disabled
virtual_alias_maps = hash:/etc/postfix/virtual
smtpd_banner = $myhostname ESMTP #I’ve truncated this because I don’t like people knowing just what is running. 😉
setgid_group = postdrop
unknown_local_recipient_reject_code = 450
fast_flush_domains = $relay_domains
mydomain_fallback = <enter a secondary server address here> # Warning! This entry is mandatory. Postfix will not run without it. You can enter an IP or FQDN. It doesn’t need to ever be used, but it must exist.
###########################################
# Rest of this junk is from server admin tool and unmodified from original form.
#
luser_relay =
maps_rbl_domains =
message_size_limit = 0
smtpd_use_tls = no
smtpd_enforce_tls = no
smtpd_tls_loglevel = 0
smtpd_sasl_auth_enable = no
smtpd_use_pw_server = no
smtpd_pw_server_security_options = none
server_enabled = 1
mailbox_transport = cyrus
enable_server_options = yes
inet_interfaces = all
relayhost =
smtpd_client_restrictions =
always_bcc =
~
============================================

The above file configures your server as a DMZ relay with no local transport. We’ll be adding alias for root, postmaster, etc that send all e-mail to internal addresses.

Next, we need to edit master.cf to add a content filter inclusion on the smtp service line.
Here’s mine:
============================================
smtp inet n – n – – smtpd # this line is already there and uncommented if running smtp
-o content_filter=spamfilter # this is the line you add directly under the smtp line. Lead with whitespace as shown.
============================================

Next you need to set up the content filter itself in master.cf In the interfaces section, you need to add the following:
============================================
spamfilter
unix – n n – pipe
flags=Rq user=spam argv=/usr/bin/spamfilter.sh -f ${sender} — ${recipient}
============================================

The above uses a shell script named spamfilter.sh to invoke the pipe. The SpamAssassin, spamd and spamc executeables install in /usr/bin by default, so I also installed my shell script there as well.

Since I didn’t want this running as root, I chowned spamd and spamc as spam:wheel with perms = 755.

Now, we need to create the shell script.
Here’s mine:
============================================
#!/bin/bash
/usr/bin/spamc | /usr/sbin/sendmail -i "$@"
exit $?
============================================

So, essentially what we’re doing is creating a complex pipe from postfix to spamc/spamd to sendmail.

Next, we need to create some tables in /etc/postfix to manage the connection.

First we need to create a transport table. It should already exist as transport. I’m a bit overly cautious when doing these, so I cp the originals to .bak files just in case there’s a problem down the road.

This is a very simple table mapping the smtp server to the domain.
============================================
<yourdomainname> [smtp:<ipaddressofyourinternalmailserver>]
nowhere.net [smtp:192.168.0.1] ; Here’s a quick example.
============================================

Earlier I mentioned that since we are disabling local mail service, we needed to create alias for the well known receivers to redirect them to internal addresses.
This is done with the virtual table and the file should also pre-exist here.

============================================
postmaster postmaster@<yourdomain>
abuse sysadmin@<yourdomain>
sysadmin sysadmin@<yourdomain>
root postmaster@<yourdomain>
============================================

The above will redirect the local e-mail accounts in the left column to the internal addresses in the right column. Obviously, the internal addresses must exist.

The next table is the most complex of the ones we’ll deal with. This is the relay_recipients table. Here you can make a choice. You can enter some wildcard info and forward all e-mail inbound OR you can really tighten this up to relay only mail to existing internal addresses. (The former is quite simple, the latter requires either manual update by the sysadmin (a real chore if you’ve got a lot of people) or an automation script that can handle it for you.)

relay_recipients may or may not pre-exist in the /etc/postfix directory. If it doesn’t, just create it and make sure to chown/chmod it to be the same as the other existing tables (root:wheel / 644)
Here’s the easy way using the wildcard:
============================================
@<yourdomain> x

@nowhere.net x ; Quick Example
============================================

The above will forward all mail inbound (and through the spamassassin pipe) to the internal servers for them to decide on delivery.

You can also choose to lock this down. The basic format is:
============================================
<user>@<yourdomain> OK
[email protected] OK ; Quick Example
============================================

If you’re running Microsoft’s Active Directory internally (like me), there’s a good perl script that can automate this process for you (This will probably work for any LDAP/OpenDirectory server as well, though you might need to massage it a bit). Otherwise, you’ll need to build it by hand each time a user is added/deleted. I’ll post that in a separate thread for those that are interested in it.

You’ve probably noticed that there are also files of similar name in the directory. virtual.db for example. These are the hashed versions of the text files that postfix actually reads. Since we’ve altered the base text files, we now need to update these hash tables so that postfix can use our tables.

To do this, you will use the postmap command. The syntax is: postmap hash file.db < file

So for the virtual table, the command would be: postmap hash virtual.db < virtual

Create the has tables for each of the tables we’ve updated (transport, virtual and relay_recipients).

Now that we’re done with the configuration of Postfix, we need to deal with that nasty little daemon known as postfix-watch. postfix-watch is a daemon that checks in on postfix on a regular schedule (via periodic daily and a few other means) and checks to see if it is alive if the server is configured to be a mail server. The problem with this is that it also stomps on master.cf and main.cf each time and will remove your customized settings for the server. To prevent this from happening, we’re going to prevent postfix-watch from respawning the server. To do this, we need to edit /etc/watchdog.conf. Using your favorite editor, open watchdog.conf and locate the line with this entry:
============================================
postfix:respawn:/usr/libexec/postfix/master # Mail services – SMTP
============================================

All we will do is comment this line out by placing a # at the beginning. Do NOT delete the line. The reason for this is that periodic.daily parses this file as part of it’s routine. If the line is missing, it will recreate it. Since we are commenting it, periodic believes the line still exists and leaves it alone. So, your edited version should look like:
============================================
#postfix:respawn:/usr/libexec/postfix/master # Mail services – SMTP
============================================

You’d think that is all you need, but wait, there’s more. postfix-watch and periodic are sneaky.

We also need to edit /etc/hostconfig. Again, open the file with your editor of choice and locate this entry:
============================================
MAILSERVER=-AUTOMATIC-
============================================

edit it to read:
============================================
MAILSERVER=-YES-
============================================

This is the one that actually prevents postfixc-watch from starting. Now, that we’ve edited the file, kill postfix-watch (if it is running). For those of you unfamiliar with the unix kill command, you need to find it’s PID to kill it. To do so, issue the following command:
============================================
ps -aux |grep postfix-watch
============================================

That will return a result to the console window similar to:
============================================
root 724 0.0 0.0 27476 408 ?? Ss 18Oct04 3:09.32 postfix-watch
============================================

The number in the second column is what we want (724 in the example above).
To kill the process type: kill 724 (for above, substitute the correct number for your system).

Next, type: "postfix stop" to make sure that postfix is stopped.

Now we are going to start up spamd (the daemon portion of SpamAssassin) to start the pipe.

The basic command is:
============================================
/usr/bin/spamd -d -m4 -H -u spam
============================================

The above starts spamd with -d (daemon), -m4 (create 4 child processes (total of 5 with the parent), -H (use standard home directory (/etc/mail/spamassassin), -u (chrooted as user spam).

Now type: "postfix start" to start up postfix with the new configuration files.

Your relay server should now be working. You can check in on it by using the unix tail command. It will read the last few lines of the mail.log file and display them onscreen for you. You can also use the -f flag of tail to have the file displayed in realtime in the foreground as it is being written.

The full command to have the mail.log file run in foreground mode is:
============================================
tail -f /var/log/mail.log
============================================

When you want to stop displaying the log, simply Ctrl-C to exit the command.

I’ve not yet written startup scripts for spamd (mostly because I’ve been quite busy with other things) but you can do that as well if you like. Be sure to set a plist such that postfix depends on spamd to be running first.

[Author]

Posts