Hide Forgot
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...] SHELL=/bin/sh LOGFILE=logs/procmail VERBOSE=yes LOGABSTRACT=all :0c: mail-backup :0ic | cd mail-backup && /bin/rm -f dummy `/bin/ls -t msg.* | /bin/sed -e 1,128d` :0fw | /usr/bin/spamassassin :0: * ^Subject: Test grobblefruit testing :0: * ^X-Spam-Flag.*YES mail/spam :0: * ^TO_rt-users@lists\.fsck\.com mail/rt-users :0: * ^TO_outlook-users@yahoogroups\.com mail/outlook-users :0: * ^TO_procmail@Lists\.RWTH-Aachen\.DE mail/procmail-list :0: * ^TO_openldap-software@OpenLDAP\.org mail/openldap-software [...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 "(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-To):(.*[^-a-zA-Z0-9_.])?)rt-users@lists\.fsck\.com" procmail: No match on "(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-To):(.*[^-a-zA-Z0-9_.])?)outlook-users@yahoogroups\.com" procmail: No match on "(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-To):(.*[^-a-zA-Z0-9_.])?)procmail@Lists\.RWTH-Aachen\.DE" procmail: No match on "(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-To):(.*[^-a-zA-Z0-9_.])?)openldap-software@OpenLDAP\.org" 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: Always 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:
Created attachment 88710 [details] Output of Sean B. Straw's "procdiag.sh" script
Created attachment 88711 [details] List of RPMs on the system in question
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.
I'm having the same problem. Is there any fix or work around?
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: :0fw | /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.
I finally figured out a usable .procmailrc, thanks in part to Peregrine Hardware's installation notes - in particular the file at http://www.peregrinehw.com/downloads/SpamAssassin/INSTALL. Here's my functional procmailrc file: [...begin quote of functional .procmailrc...] SHELL=/bin/sh LOGFILE=logs/procmail VERBOSE=yes LOGABSTRACT=all :0c: mail-backup :0ic # 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` :0fw # Don't process anything over 256K - most spam is smaller than this, # and we have limited system resources. * < 256000 | /usr/bin/spamc -f :0e { EXITCODE=$? } :0: * ^X-Spam-Flag: YES mail/spam :0: * ^TO_rt-users@lists\.fsck\.com mail/rt-users :0: * ^TO_outlook-users@yahoogroups\.com mail/outlook-users :0: * ^TO_procmail@Lists\.RWTH-Aachen\.DE mail/procmail-list :0: * ^TO_openldap-software@OpenLDAP\.org mail/openldap-software :0: * ^TO_amanda-users@amanda\.org mail/amanda-users :0: * ^TO_achievo@achievo\.org mail/achievo :0: * ^TO_IMAP@cac.washington.edu mail/imap :0: * ^TO_imap@u.washington.edu mail/imap [...end quote of functional .procmailrc...]
So is there still a problem with our procmail/spamassassin?
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 /usr/share/doc/spamassassin-2.31/README
Do you have any comments on this, Chip?
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.
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.
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.
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.
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.