SpamAssassin 3?

I recently switched from another provider to DreamHost, and since then, the amount of spam I receive has gone way up. I've lowered my SpamAssassin cut-off score even lower, but it's not enough. I suspect the problem may be that DreamHost is using SpamAssassin 2 and not the newer 3.x series. I asked support if they would be installing version 3 soon, but unfortunately there are no plans to do so.

However, I remember reading in various forum posts that some users have resorted to installing SpamAssassin for themselves. Is this possible? How would I go about installing SpamAssassin on my shared hosting plan?

I did find this article in the wiki, but I'm not sure if it applies:
http://wiki.dreamhost.com/index.php/SpamAssassin

Thanks,

Trevor

You might want to look at this thread.

I currently have a help request in to Dreamhost regarding spamassassin. I posted the Wiki you referenced (at least
as it stands now on October 11). That does pipe mail through spamassassin, but I get the error message back:

Could not lock /home/actest/Maildir/: File exists at /usr/share/perl5/Mail/SpamAssassin/NoMailAudit.pm line 381.

I cannot find this perl module on my login system, but am guesssing that it exists on the system that is processing my incoming mail. I am guessing that Dreamhost has cross mounted my home directory to some other system that is processing the receieved mail. So the Perl modules I see on my home system may not be the same as what exists on the mail processing system. All a guess, I would love to hear from an expert. A friend with a Dreamhost account on another system hit the same Spamassassin error.

I am really puzzled as to why spamassassin would be trying to do any locking. I am trying to use it as a filter with data simply piped through it. I believe our mail system does not need any locking, and even if it did it would be procmail that would do the locking. So what's going on here?

I did try to install a local copy of Spamassassin but ran into problems there. My preference is to run a copy of Spamassassin on Dreamhost. That let's them keep it up to date. I'm really sorry to hear that they don't have plans to move to version 3. I would hope that they would consider providing current spam fighting tools, and keeping them updated to be an important service.

- Dale

You said that Dreamhost is running Spamassassin version 2. And yet I get the report of 3.0.3 when I execute it with "--version" like so:

$ spamassassin --version
SpamAssassin version 3.0.3
running on Perl version 5.8.4

This command was executed on machine "sepulveda". I have a friend with an account on machine "quid" and this shows the same version. Why do you think Dreamhost is running Version 2 Spamassassin? It sounds as if you spoke with then and they told you they would not upgrade.

Looking at a header when I was trying to use the system version I see:
X-Spam-Status: No, hits=-103.4 required=5.0 tests=IN_REP_TO,RCVD_IN_ORBS,USER_IN_WHITELIST version=2.20

I would guess that the "version=2.2" string is telling us the version of Spamassassin but I cannot be sure. If so, it makes no sense to me that machines "sepelveda" and "quid" would be running 3.0.3 and yet mail processing systems would run 2.2.

- Dale

version=2.2 is the SpamAssassin version. Incoming mail is processed on a different machine, which is running older software than the shell machines. This is probably why you couldn't find the file NoMailAudit.pm in your installation of SA 3.

The solution is to ensure that procmail is using your local version of SpamAssassin. This works fine, except there is still a mismatch between Perl/libdb versions, which causes problem with the bayes/autowhitelist databases. The handy installation guide posted in another thread described how to use MySQL for these. This works fine, although I don't know that it would scale to large volumes of mail.

I'm actually having problems with the MySQL Bayes setup. It works fine when I execute manually, but when postfix executes via procmail, the bayes (and other) tests aren't run. Anyone know what user account is used when executing procmail? I don't believe it is the user account that is being delivered to.

Assuming you're using db files for Bayes, rather than SQL (as suggested in another thread), mail delivery is happening on a different group of machines, which is still running an older release of Debian - so the db libraries are likely different.

It'll be even more confusing when DH starts upgrading mail machines, as different mail machines may be different Debian releases, for at least a short amount of time.

w/r/t version, you'd see 3.0.x on the new (Sarge) user machines, but this will never be used. 2.20 is on the old (Woody) mail servers. The Junk filter machines were running different versions last I checked (3.0.4 backport on one and 2.64 or something on the other) - however that may not be the case currently (you could look at the headers of junk-filtered messages to determine this). In any event, you shouldn't use or rely on the installed SpamAssassin binaries on the DH servers, as they may be inconsistent with what's on the mail machine, and will likely stay the same across a release of Debian (meaning it will get old and moldy really quick).

If you can't or won't use the junk filter, do your own install - there are some good howtos out there. The bayes stuff should work out better after the mail servers are also upgraded. You could try testing the install, but then hosing the bayes db entirely and see if it works on the mail servers then - or you could install your own libdb in your home dir and compile SpamAssassin against that - that would be a big PITA, though.

Also keep in mind that the version of Net::DNS on the mail servers is probably old.

See also:
this post (and check out the rest of that thread).

This post says a lot of the same stuff.

In another thread, someone mentioned that you need to have a certain body of spam/ham before the bayes rules kick in. I'm now using MySQL for the bayes db and it took a few days before I started to see it working.

I can run it manually and it works fine (so I know there is enough data in there), but when it runs on incoming mail, it doesn't do the bayes test.

It must run as a different user account when postfix runs procmail. That's what I'm trying to figure out.

It's not a different user, which is what I was trying to tell you. It's running as the same user on a different machine which has different stuff installed. Your home dir is mounted across both machines, so stuff in there will be the same, but when you compile or run SpamAssassin, it's linking to system libraries on the user machine that are different from the ones on the mail machines.

In reply to:

---

version=2.2 is the SpamAssassin version. Incoming mail is processed on a different machine, which is running older software than the shell machines.

---

Is no mail processed on the shell machines? If not, why is SA installed at all?

OK, thanks. In trying to troubleshoot sa, I tried changing my sa line in my procmail recipe from this:

:0fw
| $HOME/sauser/bin/spamassassin

to this:

:0fw
| $HOME/sauser/bin/spamassassin -D 2>> $HOME/sa.log

But no logfile gets created. If it's running under my account and my home directory is mounted on the other machine, shouldn't this work?

Thanks for your help.