You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by mi...@kpmcornerstone.com on 2005/04/04 22:17:29 UTC
Problems with spamassassin, milter-spamc, milter-sender and procmail
Hi folks:
Well, I thought I had everything working just wonderfully ... all that nasty spam was being dropped into the bit
bucket as I wanted. However, now I don't seem to be passing things through procmail such that they get dumped.
I am really puzzled -- I believe this may have started when I upgraded spamassassin to v.2.6.3. Currently, I am using
ClamAV, Spamassassin 2.63, procmail and milter-sender and milter-spamc. Here are some of the pertinent details:
A sample message from maillog:
Apr 4 12:23:27 cerebus sendmail[1058]: j34JNMJT001058: Milter accept: message
Apr 4 12:23:29 cerebus MailScanner[31577]: New Batch: Scanning 1 messages, 1418 bytes
Apr 4 12:23:30 cerebus MailScanner[31577]: Spam Checks: Found 1 spam messages
Apr 4 12:23:31 cerebus MailScanner[31577]: Virus and Content Scanning: Starting
Apr 4 12:23:32 cerebus MailScanner[31577]: Uninfected: Delivered 1 messages
Apr 4 12:23:33 cerebus spamd[31487]: connection from localhost.localdomain [127.0.0.1] at port 38946
Apr 4 12:23:33 cerebus spamd[1078]: info: setuid to michael succeeded
Apr 4 12:23:33 cerebus spamd[1078]: processing message <55...@cabinetmake89-zmx17.excite.com> for michael:500.
Apr 4 12:23:58 cerebus spamd[1078]: identified spam (7.0/4.9) for michael:500 in 25.0 seconds, 1611 bytes.
Apr 4 12:24:14 cerebus sendmail[1074]: j34JNMJT001058: to=<mi...@kpmcornerstone.com>, delay=00:00:49, xdelay=00:00:42, mailer=local, pri=120517, dsn=2.0.0, stat=Sent
As you can see the message is clearly identified as spam, but for some reason, it never gets passed to procmail (or I'm doing
something wrong with procmail.) Here is the .procmailrc for this account:
#
:0fw: spamassassin.lock
* < 256000
| spamc
# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*
caughtspam
# All mail tagged as spam (eg. with a score higher than the set threshold)
# is moved to "probably-spam".
:0:
* ^X-Spam-Status: Yes
caughtspam
# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped. This will re-add it.
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "
:0 fhw
| sed -e '1s/^/F/'
}
Here is the local.cf for spamassassin:
# How many hits before a message is considered spam.
required_hits 4.9
# Whether to change the subject of suspected spam
rewrite_subject 1
# Text to prepend to subject if rewrite_subject is used
subject_tag *****SPAM*****
# Encapsulate spam in an attachment
report_safe 1
# Use terse version of the spam report
use_terse_report 0
# Enable the Bayes system
use_bayes 1
# Enable Bayes auto-learning
auto_learn 1
# Enable or disable network checks
skip_rbl_checks 0
use_razor2 1
use_dcc 1
use_pyzor 1
# Mail using languages used in these country codes will not be marked
# as being possibly spam in a foreign language.
# - english
ok_languages en
# Mail using locales used in these country codes will not be marked
# as being possibly spam in a foreign language.
ok_locales en
And the pertinent section of sendmail.cf:
dnl -------------------------------------------------------------------
dnl milter-spamc.mc
dnl -------------------------------------------------------------------
dnl Example configuration to be added to sendmail.mc.
dnl
define(`_FFR_MILTER', `1')dnl
dnl define(`_FFR_MILTER_421', `1`)dnl
dnl -------------------------------------------------------------------
dnl Enable this to see lots of debug output from sendmail about
dnl a good many things.
define(`confLOG_LEVEL', `9')dnl
dnl -------------------------------------------------------------------
dnl Enable this to see even more debug output. Suppose to default
dnl to confLOG_LEVEL.
dnl
dnl If Milter.LogLevel is greater-than:
dnl
dnl 0 Communication errors
dnl 8 Header & RCPT modification messages
dnl 9 Connect to info
dnl 10 Milter error return codes, abort messages
dnl 12 More return code info, connection/open errors
dnl 14 Sender & rcpts info
dnl 17 Show headers & body sent to a milter.
dnl 18 Quit
dnl 21 Time a milter
define(`confMILTER_LOG_LEVEL', 12)dnl
dnl -------------------------------------------------------------------
dnl Note that the F= says what to do with the message if the milter
dnl is not running.
dnl
dnl F=T Temporary fail connection if filter unavailable
dnl F=R Reject connection if filter unavailable
dnl
dnl If no F= specified and there is a problem with the milter, then
dnl the default is to continue normal handling, skipping the milter.
dnl
dnl Note that the T= specifies timeouts for communication. The
dnl following fields are defined:
dnl
dnl C Timeout for connecting to a filter. If set to zero (0),
dnl the system's connect() timeout will be used. Default: 5m
dnl S Timeout for sending information from the MTA to a
dnl filter. Default: 10s
dnl R Timeout for reading reply from the filter. Default: 10s
dnl E Overall timeout between sending end-of-message to filter
dnl and waiting for the final acknowledgment. Default: 5m
dnl
dnl So the default values are equivalent to:
dnl
dnl T=C:5m;S=10s;R=10s;E:5m
INPUT_MAIL_FILTER(
`milter-spamc',
`S=unix:/var/lib/milter-spamc/spamd.socket, T=S:30s;R:2m'
)dnl
define(
`confMILTER_MACROS_CONNECT', confMILTER_MACROS_CONNECT`,
{client_addr}, {client_name}, {client_port}, {client_resolve}'
)dnl
dnl -------------------------------------------------------------------
dnl End milter-spamc
dnl -------------------------------------------------------------------
dnl -------------------------------------------------------------------
dnl milter-sender.mc
dnl -------------------------------------------------------------------
dnl Example configuration to be added to sendmail.mc.
dnl
define(`_FFR_MILTER', `1')dnl
dnl -------------------------------------------------------------------
dnl Enable this for debug output from Sendmail.
dnl define(`confLOG_LEVEL', `14')dnl
dnl -------------------------------------------------------------------
dnl Enable this to see even more debug output.
dnl Defaults to confLOG_LEVEL.
dnl
dnl If Milter.LogLevel is greater-than:
dnl
dnl 0 Communication errors
dnl 8 Header & RCPT modification messages
dnl 9 Connect to info
dnl 10 Milter error return codes, abort messages
dnl 12 More return code info, connection/open errors
dnl 14 grey & rcpts info
dnl 17 Show headers & body sent to a milter.
dnl 18 Quit
dnl 21 Time a milter
dnl define(`confMILTER_LOG_LEVEL', 14)dnl
dnl -------------------------------------------------------------------
dnl Note that the F= says what to do with the message if the milter
dnl is not running.
dnl
dnl F=T Temporary fail connection if filter unavailable
dnl F=R Reject connection if filter unavailable
dnl
dnl If no F= specified and there is a problem with the milter, then
dnl the default is to continue normal handling, skipping the milter.
dnl
dnl Note that the T= specifies timeouts for communication. The
dnl following fields are defined:
dnl
dnl C Timeout for connecting to a filter. If set to zero (0),
dnl the system's connect() timeout will be used. Default: 5m
dnl S Timeout for sending information from the MTA to a
dnl filter. Default: 10s
dnl R Timeout for reading reply from the filter. Default: 10s
dnl E Overall timeout between sending end-of-message to filter
dnl and waiting for the final acknowledgment. Default: 5m
dnl
dnl So the default values are equivalent to:
dnl
dnl T=C:5m;S=10s;R=10s;E:5m
dnl
INPUT_MAIL_FILTER(
`milter-sender',
`S=unix:/var/lib/milter-spamc/spamd.socket, T=C:1m;S:30s;R:6m;E:1m'
)dnl
dnl define(
dnl `confMILTER_MACROS_CONNECT', `j, _, {daemon_name}, {if_name}, {if_addr}, '
dnl `p, {client_addr}, {client_name}, {client_port}, {client_resolve}'
dnl )dnl
dnl define(
dnl `confMILTER_MACROS_CONNECT', confMILTER_MACROS_CONNECT`,
dnl p, {client_addr}, {client_name}, {client_port}, {client_resolve}'
dnl )dnl
define(
`confMILTER_MACROS_HELO', confMILTER_MACROS_HELO`,
{verify}'
)dnl
dnl -------------------------------------------------------------------
dnl End milter-sender.mc
dnl -------------------------------------------------------------------
MAILER(smtp)dnl
MAILER(procmail)dnl
MAILER(local)dnl
As I stated earlier, everything was working before my spamassassin upgrade ... sure, some would get through, but
now virtually NOTHING is getting dumped. You can see that things are getting tagged correctly, but I am not
seeing the full output from milter-spamc (with all the flags and tests, etc.) and the messages, although marked with
the header "***** SPAM ******", still get through, and with scores similar to the one I posted above.
What am I doing wrong here? Many many thanks in advance!
Michael
Re: Problems with spamassassin, milter-spamc, milter-sender
and procmail
Posted by Matt Kettler <mk...@comcast.net>.
At 04:17 PM 4/4/2005, michael@kpmcornerstone.com wrote:
>Well, I thought I had everything working just wonderfully ... all that
>nasty spam was being dropped into the bit
>bucket as I wanted. However, now I don't seem to be passing things
>through procmail such that they get dumped.
>I am really puzzled -- I believe this may have started when I upgraded
>spamassassin to v.2.6.3. Currently, I am using
>ClamAV, Spamassassin 2.63, procmail and milter-sender and
>milter-spamc. Here are some of the pertinent details:
You forgot to mention MailScanner.
However, if nothing else, ditch milter-spamc immediately.
You need to make sure you call spamassassin ONCE per message. You're
currently calling it at least twice. Once from milter-spamc AND once again
by calling spamc in procmailrc. If MailScanner is using SpamAssassin, then
you've got it called three times!
Ouch! That hurts in performance. To add insult to injury, re-scanning the
messages might reduce your hit rate, as I explain below.
If milter-spamc sees the message as spam and you don't have "report_safe 0"
set, it's going to encapsulate the spam in a new message with new headers
and tag the subject.
Later when procmail passes the encapsulated message to spamc, it no longer
looks like spam because of the new headers. None of the original Received:
headers will be scanned for RBLs, as those are in the encapsulated message.
Thus, to the second call to spamc, this message originated at localhost,
instead of evilserver.spammer.com.
Poof. X-Spam-Status gets over-written with No.
That's probably your problem.