For anybody interested in researching this problem further.
ie. those are aren't in a position to upgrade past 3.21.
spamassassin procmailrc code has the following comment
# Work around procmail bug: any output on stderr will cause the "F" in
"From"
# to be dropped. This will re-add it.
Does anybody know if procmail outputs to stderr if a filter returns a
non zero exit status?
Is that the "Recovered from filter failure..." message or some such?
My latest test shows that if my filter ie. perl script returns a 0 exit
status the message will
go through fine. If however, it travels down the logic path that
returns a 1 exit status then
it will always chop off the leading "F"
I'm wondering if procmail writes to stderr when a filter exists with a
non zero exit status.
On Friday, October 25, 2002, at 09:04 PM, Robert Nicholson wrote:
I've been browsing the archives researching this problem some more
since I want to put together a case for upgrading past 3.21 via my ISP
at Verio.
Is that Philip says still the case?
http://MailMan.RWTH-Aachen.DE/pipermail/procmail/2002-March/008774.html
In my case when I see this problem there is nothing else that would be
writing to the mail folder.
I do not wish to use the "sed" hack as it causes me all kinds of
problems with the sequencing of my rules.
I want a rule to execute conditionally on the successful execution of
my filter but after my filter I have to run the sed hack so my rule is
then dependent on the hack rule instead of the previous rule.
I find it hard to believe that in my case this is a locking issue as
there is nothing else touching the folder.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail