Bug 79608 - procmail runs but does not correctly apply rules
Summary: procmail runs but does not correctly apply rules
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: spamassassin
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Chip Turner
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-13 22:46 UTC by Graham Freeman
Modified: 2007-04-18 16:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-02-28 22:13:56 UTC

Attachments (Terms of Use)
Output of Sean B. Straw's "procdiag.sh" script (3.63 KB, text/plain)
2002-12-13 22:50 UTC, Graham Freeman
no flags Details
List of RPMs on the system in question (10.54 KB, text/plain)
2002-12-13 22:52 UTC, Graham Freeman
no flags Details

Description Graham Freeman 2002-12-13 22:46:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

Description of problem:
I'm having a strange problem with Procmail on Red Hat Linux 8.0.  I
recently migrated my e-mail services from a Red Hat 7.3 system to a Red
Hat 8.0 system, and everything but procmail survived the transition.

In a nutshell:  My procmail log shows that procmail is aware of the
incoming messages, and it appears that it's actually processing them.
However, no matter what I try I can't get procmail to actually recognize that
many of these messages do indeed match rules in my .procmailrc.

Here's my ~/.procmailrc:

[...begin quote of procmailrc...]


| cd mail-backup && /bin/rm -f dummy `/bin/ls -t msg.* | /bin/sed -e 1,128d`

| /usr/bin/spamassassin

* ^Subject: Test grobblefruit

* ^X-Spam-Flag.*YES

* ^TO_rt-users@lists\.fsck\.com

* ^TO_outlook-users@yahoogroups\.com

* ^TO_procmail@Lists\.RWTH-Aachen\.DE

* ^TO_openldap-software@OpenLDAP\.org
[...end quote of procmailrc...]

Here's the procmail log entry from a recent message I got which should have been
handled by the relevant procmail rule:

[...begin quote of procmail log...]
procmail: [17472] Fri Dec 13 14:45:27 2002
procmail: Assigning "LOGABSTRACT=all"
procmail: Locking "mail-backup.lock"
procmail: Assigning "LASTFOLDER=mail-backup/msg.3k2L"
procmail: Opening "mail-backup/msg.3k2L"
procmail: Acquiring kernel-lock
From graham@farwestern.com  Fri Dec 13 14:45:27 2002
 Subject: Test grobblefruit
  Folder: mail-backup/msg.3k2L                                              885
procmail: Unlocking "mail-backup.lock"
procmail: Assigning "LASTFOLDER= cd mail-backup && /bin/rm -f dummy `/bin/ls -t
msg.* | /bin/sed -e 1,128d`"
From graham@farwestern.com  Fri Dec 13 14:45:27 2002
 Subject: Test grobblefruit
  Folder:  cd mail-backup && /bin/rm -f dummy `/bin/ls -t msg.* | /bin      885
procmail: Executing " cd mail-backup && /bin/rm -f dummy `/bin/ls -t msg.* |
/bin/sed -e 1,128d`"
procmail: Executing "/usr/bin/spamassassin"
procmail: No match on "^Subject: Test grobblefruit"
procmail: No match on "^X-Spam-Flag.*YES"
procmail: No match on
procmail: No match on
procmail: No match on
procmail: No match on
procmail: Locking "/var/spool/mail/graham.lock"
procmail: Assigning "LASTFOLDER=/var/spool/mail/graham"
procmail: Opening "/var/spool/mail/graham"
procmail: Acquiring kernel-lock
procmail: Unlocking "/var/spool/mail/graham.lock"
procmail: Notified comsat: "graham@8765678:/var/spool/mail/graham"
  Folder: /var/spool/mail/graham                                              1
[...end quote of procmail log...]

This same "No match on [rule]" behaviour happens with every other message which
should otherwise match a rule in my procmailrc.

I'm using the 'procmail-3.22-7' RPM as distributed by Red Hat with RH
version 8.0.  As the RPM package name implies, it's procmail v3.22r7,
which looks to me to be the current version available from procmail.org.

I've only been editing my .procmailrc with vim and pico via the shell, so I
don't think linebreaks are a problem.  Just for kicks, I copy & pasted the
contents of my .procmailrc to a new iteration of the same file, using only vi on
the local shell, so as to remove any possible linebreak problems.  As I
expected, no linebreak problems existed and so this approach solved nothing.

An earlier version of my procmailrc *did* work on Red Hat 7.3 (with the Red
Hat-distributed 'procmail-3.22-5' RPM), and the only reason I've changed the
procmailrc since then is because it stopped working when I moved to RH 8.0.

I've communicated with folks on the Procmail Users list at
'procmail@Lists.RWTH-Aachen.DE', at least one of whom has reported using my same
.procmailrc with success on a non-Red Hat 8 system.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ensure that the 'sendmail-8.12.5-7', 'procmail-3.22-7', and related packages
are installed on your Red Hat 8 system
2. create a valid ~/.procmailrc
3. receive e-mail which ought to match a rule in your .procmailrc

Actual Results:  E-mail is reported by procmail to have been received and
examined, but no procmail rules are actually matched.

Expected Results:  Properly-constructed rules should trigger a match on
appropriate incoming messages.

Additional info:

Comment 1 Graham Freeman 2002-12-13 22:50:29 UTC
Created attachment 88710 [details]
Output of Sean B. Straw's "procdiag.sh" script

Comment 2 Graham Freeman 2002-12-13 22:52:05 UTC
Created attachment 88711 [details]
List of RPMs on the system in question

Comment 3 Graham Freeman 2002-12-13 23:06:08 UTC
Also, my RH7.3->RH8.0 transition was done by creating a new RH8.0 system from
scratch.  In other words, I didn't attempt a foolhardy upgrade process.  The
original RH7.3 system in question is still up and running, with a modified workload.

Comment 4 Need Real Name 2002-12-31 14:54:50 UTC
I'm having the same problem.  Is there any fix or work around?

Comment 5 Graham Freeman 2003-01-02 18:11:25 UTC
Thanks to helpful advice from Alessandro Forghieri from 'orion.it', I've been
able to narrow down the source of the problem to the Red Hat
'spamassassin-2.31-16' RPM package.  Removing the following two lines from my
.procmailrc caused every other rule in my .procmailrc to start working again:

| /usr/bin/spamassassin

Mr. Forghieri said that his problem went away when he upgraded to a newer
version of SpamAssassin.  I haven't done that yet because I'd prefer to stay
with the Red Hat RPMs, since that's what I pay $60/year/system for.

Comment 6 Graham Freeman 2003-01-02 23:04:28 UTC
I finally figured out a usable .procmailrc, thanks in part to Peregrine
Hardware's installation notes - in particular the file at

Here's my functional procmailrc file:

[...begin quote of functional .procmailrc...]


# Keep a backup of each of the last 128 messages received
| cd mail-backup && /bin/rm -f dummy `/bin/ls -t msg.* | /bin/sed -e 1,128d`

# Don't process anything over 256K - most spam is smaller than this,
# and we have limited system resources.
* < 256000

      | /usr/bin/spamc -f


* ^X-Spam-Flag: YES

* ^TO_rt-users@lists\.fsck\.com

* ^TO_outlook-users@yahoogroups\.com

* ^TO_procmail@Lists\.RWTH-Aachen\.DE

* ^TO_openldap-software@OpenLDAP\.org

* ^TO_amanda-users@amanda\.org

* ^TO_achievo@achievo\.org

* ^TO_IMAP@cac.washington.edu

* ^TO_imap@u.washington.edu
[...end quote of functional .procmailrc...]

Comment 7 Jens Petersen 2003-01-03 04:07:10 UTC
So is there still a problem with our procmail/spamassassin?

Comment 8 Graham Freeman 2003-01-03 07:06:48 UTC
Yes, in that the procmail-based invokation of SpamAssassin that works on Red Hat
7.3 and is referenced in the SpamAssassin documentation doesn't work on Red Hat
8.0.  Not only doesn't it work, but the procmail logs are baffling and bordering
on misleading.

It's probably not a RedHat-initiated problem, but if Mr. Forghieri is correct
that upgrading to a newer version of SpamAssassin fixes things, then I'd say
that Red Hat should either issue an updated spamassassin RPM or fix the
documentation at line 116 in


Comment 9 Jens Petersen 2003-01-03 11:43:22 UTC
Do you have any comments on this, Chip?

Comment 10 Chip Turner 2003-01-03 13:38:25 UTC
you can try the spamassassin from rawhide; it is a more recent version.  I'd
also suggest trying the perl from rawhide as well, but you may need to build it
via src rpm.  this bug doesn't affect everyone, though, so it has yet to be
determined how urgent an errata is.  we'll take this into account but chances it
won't be for a while, so your best bet is to try rawhide.

Comment 11 Graham Freeman 2003-01-06 22:34:19 UTC
Thanks for the suggestion, but since I found a usable .procmailrc entry for RH
8.0's current spamassassin, I'll just leave it as-is.  I try to keep my RH
machines as vanilla as possible so that I can just ride the RH-issued upgrade cycle.

I suspect, however, that there are more than a few people who're having the same
problem as me but just aren't reporting it.

Comment 12 Graham Freeman 2003-01-21 20:40:49 UTC
Evidence of others having the same problem but not reporting it:  Mr. Klicka
from the domain "netpro.cz" contacted me privately and said that he was having
the same problem.  I gave him my .procmailrc as a workaround.

Comment 13 Jeff Cours 2003-04-15 18:27:39 UTC
I also had this problem on a .procmailrc that I'd brought over from Debian's
Woody release - worked fine under Woody, failed under RH8. I was able to get
spamassassin to work with procmail under RH 8 by modifying the normal
spammassassin recipe as described in the docs:

:0fw: spamassassin.lock
* < 256000
| spamassassin

to this:

:0fw: spamassassin.lock
* < 256000
| spamassassin --pipe

I think what's going on is that spamassassin (at least the version shipped with
RH 8) by default writes the message to the mail spool after processing, unlike
spamc which defaults to writing the message to stdout. Apparently procmail
doesn't intercept the message on the way to the mail spool, so the message
bypasses the rest of the procmail filters. The "--pipe" command tells
spamassassin to send its output to stdout instead, which procmail can grab and
continue processing.

Comment 14 Warren Togami 2004-02-28 22:13:56 UTC
RH8 is no longer a supported product, and I highly suspect that this
problem is solved in newer distributions.  Please open a new bug if
you still have problems like this in newer distributions.  Thank you.

Note You need to log in before you can comment on or make changes to this bug.