Bug 66573 - Procmail damanges mailboxes if external filter programs not found
Procmail damanges mailboxes if external filter programs not found
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: procmail (Show other bugs)
7.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-12 09:48 EDT by Daniel Senie
Modified: 2007-04-18 12:43 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Daniel Senie 2002-06-12 09:48:53 EDT
Description of Problem:

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

  :0 fw
  |/path/to/program
  /dev/null

(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):

  procmail-3.21-0.71

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
    |/usr/local/bin/nosuchprogram
    /dev/null      

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 15:55:08 EDT
Get the one from 7.3 - it should install cleanly and fixes that problem.
Comment 2 Daniel Senie 2002-06-12 16:02:59 EDT
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 
MICROSOFT of you.

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 16:17:04 EDT
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 17:10:40 EDT
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

or

  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 17:14:57 EDT
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.