Bug 66573 - Procmail damanges mailboxes if external filter programs not found
Summary: Procmail damanges mailboxes if external filter programs not found
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: procmail (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-06-12 13:48 UTC by Daniel Senie
Modified: 2007-04-18 16:43 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-06-12 20:03:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Daniel Senie 2002-06-12 13:48:53 UTC
Description of Problem:

If in procmail one places a rule to run an external program, such as:

  :0 fw

(assume the program is something that finds spam, and this rule then bit 
buckets the spam).

If program is not found, procmail logs the error as follows 

  procmail: Executing "/path/to/program"
  procmail: Program failure (203) of "/path/to/program"
  procmail: Rescue of unfiltered data succeeded

The problem is, when it "rescues" the text, it loses the first "F" in the 
message separator line, causing messages to be run together by any program 
reading the mailbox.

So, a message separator line looks like:

  rom dts@senie.com  Tue Mar 12 23:39:20 2002

after this error, when it should appear as:

  From dts@senie.com  Tue Mar 12 23:39:20 2002

Since this violates mbox format, mail is mangled.

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


How Reproducible:

  very. I have a very simple test case outlined below, which is 100% effective 
at showing the error.

Steps to Reproduce:
1. add in a procmail rule to execute a nonexistant program. Example:

    :0 fw

2. send mail to the account.
3. look at the resulting file and the procmail log (from file) for that account.

Comment 1 Trond Eivind Glomsrxd 2002-06-12 19:55:08 UTC
Get the one from 7.3 - it should install cleanly and fixes that problem.

Comment 2 Daniel Senie 2002-06-12 20:02:59 UTC
This bug represents a data trashing condition.

RedHat claims to support RedHat 7.0, 7.1 and 7.2, not just 7.3.

We buy RedHat Network support services so that the up2date command can apply 
fixes to known problems. Marking this bug as CLOSED CURRENTRELEASE is so very 

I'd like to see this put out as an errata for RedHat 7.0/7.1/7.2, or else we 
will be calling to discuss a refund of all the money we've paid for RedHat 
Network support.

Comment 3 Trond Eivind Glomsrxd 2002-06-12 20:17:04 UTC
It's a a boundary condition caused by a local configuration error. We support
RHL 7, but that does not mean we'll issue errata for every bug in that release -
that's reserved for security issues and bugs deemed very severe. Minor fixes go
into later versions (although this fix was introduced upstream).

Comment 4 David M. Cook 2002-06-12 21:10:40 UTC
If you have a recent version of up2date, you should be able to set
versionOverride to 7.3 and then up2date the procmail package. Run

  up2date up2date 

to get the latest up2date if you don't have it already, then run

  up2date --configure


  up2date --configure --nox

Type in 7.3 for the value of versionOverride.  Then up2date procmail

  up2date procmail

Then run

  up2date --configure --nox

again and clear out the value of versionOverride.

Comment 5 Trond Eivind Glomsrxd 2002-06-12 21:14:57 UTC
Try opening the last part as an RFE against Red Hat Network.

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