View Full Version : Who turned off SpamAssassin?

04-11-2004, 09:14 AM
SpamAssassin is no longer scanning my incoming email. I haven't made any configuration modifications. Has West Host made a change?

04-11-2004, 05:08 PM
I have a custom install of SpamAssassin (thanks FZ and Jalal), and have noticed a handful of e-mail not be scored at all by SpamAssassin. No custom headers, nada.

One consistency I've noticed is that the To: value (my e-mail address) is in all upper-case. Not sure if that has anything to do with anything..

04-11-2004, 05:19 PM
Here's a possibility: the mail is larger than 256kb (I think that is the default figure WestHost puts in), because the WestHost SpamAssassin install adds this condition to your /etc/procmailrc (that only mail with relatively small file sizes is sent to SA).

However, that shouldn't be the case with you, j103c - unless the code you added to your /etc/procmailrc also contains that condition (and it's a good condition to include!).

04-19-2004, 03:25 PM
Here's an example of an e-mail that gets through. It was under the size limit that WH sets in procmail. I've '<hidden>' the legit e-mail address, especially since it's not mine ;)

Return-Path: <bounce-dzgjjclqavzgqh@gpettqsjk.uwonmail.com>
Received: from mail2.dealofalifetime.net (mail2.uwonaprizemail.com [])
by <hidden> (8.11.6/8.11.6) with SMTP id i3JJc1K03990
for <hidden>; Mon, 19 Apr 2004 13:38:09 -0600
Message-ID: <29559968.1082403490394.JavaMail.root@tuvllxhzc.uw onmail.com>
Date: Mon, 19 Apr 2004 14:38:10 -0500 (CDT)
From: uWonMail <xbcaaskrembcrz@tuvllxhzc.uwonmail.com>
Reply-To: uWonMail <xbcaaskrembcrz@tuvllxhzc.uwonmail.com>
To: <hidden>
Subject: Place your Bid - Jewelry, Art and More all starts at one
Mime-Version: 1.0
Content-Type: multipart/alternative;
X-ntc: tzlkjuljzxbukublellekvzv vbuvllxhzcbuvzk uukhcjhvkv
X-UIDL: C?g"!`<0!!,9R!!b]V!!

Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There have been several others.. I haven't noticed a real pattern yet. One thing that a couple share is "bounce" in some of the headers.

I should add that the To address was not in all upper-case in this e-mail..

04-19-2004, 03:59 PM
I think you've got the same problem as in the other thread this morning. You indicated you have a custom install of spamassassin. Could it be that this install only runs for a particular user, and you have a catchall address. If so, things sent to the catchall (for example, via a bcc:) might bypass the .procmailrc for that particular user. If spamassassin is to apply to all users, then it must be invoved by the /etc/procmailrc, not an individual users' .procmailrc.

If that is not the case, there is the possibility that there might be some header line that it making SpamAssassin think it has already processed the message, so as to avoid a message processing loop.

Here are some suggestions:

(1) Ensure the messages are going through your procmail. Go into the /etc/procmailrc, and enable looking, and look in the appropriate log files for the messages.

(2) If they are going through procmail, see if SpamAssassin is working for other messages.

(3) Try playing around with the various headers to see which one might be suppressing a spam assassin check. If you figure it out, put in a rule that says to treat the message as spam if that header is there, but there are no header lines from spamassassin.

In fact, you could probably have your .procmailrc divert any messages that should have gone through spamassassin but that don't have spam assassin header lines to your spambox :D


04-19-2004, 04:01 PM
Looking at the message some more, it is possible that the "bounce" is the factor, as mailer daemons often add that when they bounce mail, and spamassassin might just skip the processing of bounced mail.

04-19-2004, 04:08 PM
I do have a custom install, but Jalal and FZ helped me set it up so it applies to all accounts in the domain. I have looked and don't believe WH set up the domain with a catch-all address, which is fine by me - I was going to disable it anyway.

These e-mails are going to real user accounts, and procmail is set up correctly, so I'm assuming some header is triggering it to be skipped by SpamAssassin.

04-19-2004, 04:23 PM
You could always do a brute force: anything small enough without spamassassin headers gets forced through spamassassin :-)

04-19-2004, 05:32 PM
I believe it should still have at least:

X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on <domain>
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

The above was taken from a legit e-mail..

04-19-2004, 08:55 PM
Let's assume you're right: it never got to SA. Why might that be? First, could it have hit a procmail rule that bypassed SA? The only way to truly find out is to play with it. It is likely more trouble than it is worty.

I have a very extensive procmail file. I used to run things both though spambuster and spambouncer, but the latter doesn't work on westhost (I don't have all the requisite programs). I then use mailbouncer (www.mailbouncer.net) to filter even more, because after all the above, I still get 100-200 spam a day.

This is a *hard* problem. It is hard to know spam, partially because spam is like pornography -- that is, subjective to the reader. Any true approach to deal with spam will likely require changes to the underlying protocols of the net, which won't happen easily.

If you're interested, I'm sure we'll be talking about it more next year at my conference (www.acsac.org).


04-20-2004, 07:20 AM
Thanks dpfaigin..

I don't think it's that complicated. My procmail is set up pretty sparse, using *mostly* standard WH config with 1-3 extra rules that delete or move to another mailbox. I don't have any other rules than the ones WH sets to bypass SpamAssassin.

My chain of server apps touching e-mail is sendmail -> procmail -> SpamAssassin.

All e-mail, unless it is over a certain size or "* ! ^FROM_DAEMON", should be going through SpamAssassin. I've seen a couple spams forged with mail daemon type headers, but some getting through don't.

That's not necessarily a 'spam' issue to me, that's a queue not being processed when it should be.

Anyone else have any ideas?

04-20-2004, 11:31 AM
The ^FROM_DAEMON condition may be the culprit here. The "bounce" is probably what triggers the exception, and so that mail is not processed by SpamAssassin. If you can, try taking out all conditions except the size condition, and see if you still get mail that seems to have passed through without being scanned...