As I think of other tests of this issue, I finally found that we're
running the subject versions of procmail/formail in our SmartList
server. The problem I see is that any invocation of:
formail -I <headerfield>
causes deletion of the entire email (and delivery, even within a
procmail filtering recipe).
I suppose it's generally unwise to mix versions of things, but I
thought I'd ask here for confirmation that these two don't play
well together. I think my ISP must have kept the procmail v3.10
because of something in SmartList, but I don't know what.
FWIW, I'll include the email I was composing before I tumbled onto
the version thing.
Cheers,
Jim
On Wed, Oct 29, 2003 at 2:37:34AM -0600, Andrew Edelstein wrote:
Well, what do those numerous "LOG=" statements SAY? You got it to tell
you WHERE it's breaking. So what else is it saying, other than that it
ran that recipe?
Well, they don't say much, as they stop at that point. :)
Since I get no error message from formail or procmail at this point,
those LOG bread crumbs are all I have to go on.
[Jim Osborn wrote:]
The environment is: procmail v3.22 2001/09/10, recently
upgraded from v3.10. Running on Linux 2.2.25, i586.
Well there you go. It didn't "just stop working". Formail was replaced
with a newer version.
The formail manpage at my ISP, which references v3.22, reads identically
in the -I section to the old v3.10 version, so I assume the behavior, at
least, should be the same:
"If headerfield consists only of a field-name,
it effectively deletes the field."
But it shouldn't delete the entire email!
Bizarrely, formail -A "blah blah" works just fine; it seems it's just
formail -I that misbehaves. I've confirmed that other formail -I <field>
statements cause mail deletion.
Here's an rcfile excerpt and a log excerpt that may illuminate things:
rcfile:
#see what we're really running:
LOG="debug (s20) (`hostname`): `date`
running: `uname -a`
procmail:`file \`which procmail\``
procmail link: `file /usr/smartlist.bin/procmail`
real procmail: `file /usr/bin/procmail.310`
procmail version: `procmail -v`
formail: `file \`which formail\``
real formail: `file /usr/bin/formail`
formail version: `formail -v`
"
...
LOG="debug (s20-post-missed) (`hostname`): `date`
"
...
LOG="debug (s20-post-happy) (`hostname`): `date`
"
#Remove X-Debug header
:0
* ^X-Debug: jimo
{
LOG="about to filter header x-debug line
"
VERBOSE=on
:0 fwh
| formail -I X-Debug
LOG="filtered x-debug line
"
}
...
<other recipes and debug logs>
---------------end of rcfile------------------------
log:
debug (s20) (mx1): Wed Oct 29 08:00:05 PST 2003
running: Linux mx1 2.2.25 #3 Sat Mar 22 21:07:46 PST 2003 i586 unknown
procmail:../.bin/procmail: symbolic link to /usr/smartlist.bin/procmail
procmail link: /usr/smartlist.bin/procmail: symbolic link to
/usr/bin/procmail.310
real procmail: /usr/bin/procmail.310: sticky executable, can't read
`/usr/bin/procmail.310' (Permission denied).
procmail version: procmail v3.10 1994/10/31 ...
formail: /usr/local/bin/formail: symbolic link to /usr/bin/formail
real formail: /usr/bin/formail: ELF 32-bit LSB executable, Intel 80386, version
1, dynamically linked, stripped
formail version: formail v3.22 2001/09/10 ...
...
debug (s20-post-missed) (mx1): Wed Oct 29 08:00:06 PST 2003
...
debug (s20-post-happy) (mx1): Wed Oct 29 08:00:06 PST 2003
about to filter header x-debug line
procmail: [25930] Wed Oct 29 08:00:06 2003
procmail: Executing "formail,-I,X-Debug"
-------------end of log file---------------------------------
That's it; there's nothing in the log after the formail -I statement.
That's the first formail -I statement in the rc file.
The procmail :0 fwh seems to be acting as a delivering recipe,
delivering into thin air! I tried substituting egrep -v for the
formail -I statement, with identical results: silent deletion of the
mail. So, apparently I have no way to remove header fields.
Interestingly, all invocations of sed also fail on this machine,
but in this case the log shows a errors like:
procmail: Program failure (-13) of " sed..."
procmail: Rescue of unfiltered data failed
I've never known procmail to be unable to rescue unfiltered data before;
anyone know under what conditions this happens?
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail