Procmail losing mail?

Fetchmail, Sendmail and Procmail have been working together for years
now, delivering email to various places, observing various filter rules,
etc. Default goes to ././mail/inbox, or has up until recently.

The maillog records downloaded messages that Fetchmail hands off to
Sendmail, ending with the canonical "stat=Sent". But unless the message
is routed to a specific file, it apparently disappears. At least I
can't find where they go.

Problem is, I have no idea where to begin to look for such a problem: so
far as I know, nothing has been changed. The only quick fix I could
think of would be to put an explicit rule in the .procmailrc file that
everything not handled by 'formail' according to various filter files
should be appended to $MAILDIR/inbox.

So I added the following to the end of .procmailrc, and don't yet know
whether or not it will work, so I thought I'd check here:

----
# At this point, it would seem that the default doesn't work, so we need
# to make a rule
:0
* ? formail -x"From" -x"From:" -x"Sender:" \
-x"Reply-To:" -x"Return_Path:" -x"To" -x"To:"
inbox
----

Will that do the job, or have I created a monster?

Thanks for reading.

Longfellow

Re: Procmail losing mail?

Longfellow wrote:
> Fetchmail, Sendmail and Procmail have been working together for years
> now, delivering email to various places, observing various filter rules,
> etc. Default goes to ././mail/inbox, or has up until recently.
>
> The maillog records downloaded messages that Fetchmail hands off to
> Sendmail, ending with the canonical "stat=Sent". But unless the message
> is routed to a specific file, it apparently disappears. At least I
> can't find where they go.
>
> Problem is, I have no idea where to begin to look for such a problem: so
> far as I know, nothing has been changed. The only quick fix I could
> think of would be to put an explicit rule in the .procmailrc file that
> everything not handled by 'formail' according to various filter files
> should be appended to $MAILDIR/inbox.
>
> So I added the following to the end of .procmailrc, and don't yet know
> whether or not it will work, so I thought I'd check here:
>
> ----
> # At this point, it would seem that the default doesn't work, so we need
> # to make a rule
> :0
> * ? formail -x"From" -x"From:" -x"Sender:" \
> -x"Reply-To:" -x"Return_Path:" -x"To" -x"To:"
> inbox
> ----
>
> Will that do the job, or have I created a monster?

That's definitely a monster. :)

What you are telling procmail to do, is to execute formail in such a way
as to extract the information in the From, From:, Sender:, Reply-To:,
Return_path:, To, and To: headers, then if any of those headers exist at
all to dump the mail into a file called "inbox" in your home directory,
instead of to your default mailbox which is in the case of sendmail,
located at /var/spool/mail/username

In other words, the formail line isn't really necessary in that context.
If that is an exact copy of what you are doing, try looking for a
${HOME}/inbox file. I suspect that is where you will find your lost email.

I would suggest in your case, having fetchmail handoff the email
directly to procmail instead of having it do the additional step of
forwarding it to your local sendmail, which will typically handoff to
procmail anyway for the delivery. Misconfigured procmail recipes can
potentially lose email. You may need to examine your procmail logs, and
maybe generate some test emails to see what is actually going on.

-=-=-=-=-
in your ${HOME}/.fetchmailrc

set syslog
set idfile "/home/username/.fetchids"
set postmaster "postmaster"
set invisible

poll mail.example.net with proto pop3 and options no dns
user "someuser" there with password "somepassword" is someuser here and
wants mda "/usr/bin/procmail -d someuser"

-=-=-=-=-
Then in your ${HOME}/.procmailrc

# do whatever

# deliver filtered mail to inbox.
:0:
${DEFAULT}

Re: Procmail losing mail?

On 2006-04-14, Garen Erdoisa wrote:
> Longfellow wrote:


>> So I added the following to the end of .procmailrc, and don't yet know
>> whether or not it will work, so I thought I'd check here:
>>
>> ----
>> # At this point, it would seem that the default doesn't work, so we need
>> # to make a rule
>> :0
>> * ? formail -x"From" -x"From:" -x"Sender:" \
>> -x"Reply-To:" -x"Return_Path:" -x"To" -x"To:"
>> inbox
>> ----
>>
>> Will that do the job, or have I created a monster?
>
> That's definitely a monster. :)
>
> What you are telling procmail to do, is to execute formail in such a way
> as to extract the information in the From, From:, Sender:, Reply-To:,
> Return_path:, To, and To: headers, then if any of those headers exist at
> all to dump the mail into a file called "inbox" in your home directory,
> instead of to your default mailbox which is in the case of sendmail,
> located at /var/spool/mail/username

Interesting. The other three filters call out files that are in
$MAILDIR, not $HOME, and they work fine. I presumed the same would
apply in this case.

> In other words, the formail line isn't really necessary in that context.
> If that is an exact copy of what you are doing, try looking for a
> ${HOME}/inbox file. I suspect that is where you will find your lost email.

It will (see above) hopefully be in $MAILDIR/inbox, to which... hmmm,
let me look at that.

Okay, IIUC, /var/spool/mail/$USER is connected to $USERHOME/mbox. I
have that as a symlink to $MAILDIR/mbox ($MAILDIR is in a separate
partition). So, theoretically, anything in /var/././$USER should show
up in $MAILDIR/mbox, if not in $MAILDIR/inbox. I figured that if stuff
showed up in $MAILDIR/mbox instead of inbox, something was amiss. But
nothing has ever shown up there.

Nothing in /var/././$USER, either. In fact, I've got symlinks directly
from $MAILDIR to /var/spool/mail on both $USER and postmaster, which is
called out for fetchmail. Nothing in any of these.

> I would suggest in your case, having fetchmail handoff the email
> directly to procmail instead of having it do the additional step of
> forwarding it to your local sendmail, which will typically handoff to
> procmail anyway for the delivery. Misconfigured procmail recipes can
> potentially lose email. You may need to examine your procmail logs, and
> maybe generate some test emails to see what is actually going on.

Ye hairy demimonds!! I had actually forgotten all about that log!

Yep, stuff that should have shown up in the inbox has gone /dev/null...
:( No huge loss, but that should not have happened. It would appear,
then, that $DEFAULT has been assigned to /dev/null somehow.

Can't imagine how. Here's $HOME/.procmailrc:

---------
# This is a custom Procmail run control file. All entries are vetted.

PATH=$HOME/bin:/usr/bin:/usr/ucb:/bin:/usr/local/bin:.
MAILDIR=/data/mail
DEFAULT=$MAILDIR/inbox
LOGFILE=$MAILDIR/from
LOCKFILE=$HOME/.lockmail

# Process the whitelist
INCLUDERC=$MAILDIR/filters/email_white_list

# Test if the email's sender is in the blacklist
:0
* ? formail -x"From" -x"From:" -x"Sender:" \
-x"Reply-To:" -x"Return-Path:" -x"To:" \
| egrep -is -f $MAILDIR/filters/email_black_list
/dev/null

# Test if the email's sender is in the greylist
:0
* ? formail -x"From" -x"From:" -x"Sender:" \
-x"Reply-To:" -x"Return-Path:" -x"To" \
| egrep -is -f $MAILDIR/filters/email_grey_list
junk

# At this point, it would seem that the default doesn't work, so we need
# to make a rule
:0
* ? formail -x"From" -x"From:" -x"Sender:" \
-x"Reply-To:" -x"Return_Path:" -x"To" -x"To:"
inbox

# Anything that has not been delivered at the end will go to $DEFAULT
# using LOCKFILE=$DEFAULT$LOCKEXT
---------

And I've checked the blacklist several times: No typos, no ambiguous
entries. On reflection, there is one entry, "*.redirectme.net", that
has an initial asterisk (several hostnames at that location). Could
that possibly be a problem? IE, could procmail be interpreting anything
that has gotten past the white list as fodder for /dev/null? Academic,
I suppose, now that the default is explicit.

> -=-=-=-=-
> in your ${HOME}/.fetchmailrc
>
> set syslog
> set idfile "/home/username/.fetchids"
> set postmaster "postmaster"
> set invisible
>
> poll mail.example.net with proto pop3 and options no dns
> user "someuser" there with password "somepassword" is someuser here and
> wants mda "/usr/bin/procmail -d someuser"

I've got sendmail set up because at some point there will be other tasks
for it as MTA, and it has always "just worked".

> -=-=-=-=-
> Then in your ${HOME}/.procmailrc
>
> # do whatever
>
> # deliver filtered mail to inbox.
>:0:
> ${DEFAULT}
>

Aha, that's a good bit more elegant than my solution. The ":0" followed
by a colon is an explicit statement of "all mail", or some such? If so,
I shall replace my solution with this one.

So far, no unexpected email has arrived, so don't know what will happen,
but the point is to discover what went wrong and fix it. That hasn't
even begun, but thanks for the response!

Longfellow

Re: Procmail losing mail?

Longfellow wrote:
> On 2006-04-14, Garen Erdoisa wrote:
>> Longfellow wrote:
>>> [snip]
>> [snip]
>
> Interesting. The other three filters call out files that are in
> $MAILDIR, not $HOME, and they work fine. I presumed the same would
> apply in this case.

Procmail can do funny things with relative links. It's best in order to
avoid any problems to discipline yourself to using absolute path names,
or variables that expand to absolute path names for everything you do in
procmail that refers to a file or directory.

Also, if any particular recipe condition fails, procmail will just
silently skip that recipe unless you specifically code it to be noisy
about it. I do that by adding log lines in nested recipes to give a
better trace in the logs of what procmail actually did.

> [snip]
>
> Ye hairy demimonds!! I had actually forgotten all about that log!

:) In your .procmailrc, you can also turn on verbose logging for more
information. Just set VERBOSE=yes to do that.
You probability won't want to leave it on because this can create huge
procmail log files but it's to do that while debugging new or existing
recipes to see what procmail is doing under the hood so to speak.

>
> Yep, stuff that should have shown up in the inbox has gone /dev/null...
> :( No huge loss, but that should not have happened. It would appear,
> then, that $DEFAULT has been assigned to /dev/null somehow.

the value for DEFAULT should be passed to procmail via shell meta
variables, unless you changed it.
You can dump variables in procmail as follows.

# Define a new line character for use in log entries.
NL="
"

LOG="[$$]$_: DEFAULT=${DEFAULT}${NL}"

that will produce a procmail log line that looks something like:

[12345]/home/username/.procmailrc: DEFAULT=/home/username/maildir/mbox

where $$ =Process ID
$_ = current procmail filename


>
> Can't imagine how. Here's $HOME/.procmailrc:
>
> ---------
> # This is a custom Procmail run control file. All entries are vetted.
>
> PATH=$HOME/bin:/usr/bin:/usr/ucb:/bin:/usr/local/bin:.
> MAILDIR=/data/mail
> DEFAULT=$MAILDIR/inbox

DEFAULT will expand to /data/mail/inbox

You don't normally need to define this, or re-define this.
It will normally just be set to the default inbox which is passed to
procmail when it gets called.

> LOGFILE=$MAILDIR/from

LOGFILE will expand to /data/mail/from

> LOCKFILE=$HOME/.lockmail
LOCKFILE will expand to /home/username/.lockmail

Note: Defining a lockfile like this isn't really how it should be done.
More on this later.

>
> # Process the whitelist
> INCLUDERC=$MAILDIR/filters/email_white_list

INCLUDERC will expand to /data/mail/filters/email_white_list

>
> # Test if the email's sender is in the blacklist
> :0
> * ? formail -x"From" -x"From:" -x"Sender:" \
> -x"Reply-To:" -x"Return-Path:" -x"To:" \
> | egrep -is -f $MAILDIR/filters/email_black_list
> /dev/null

Ok, since you posted the full recipe I see what you are doing now.
You are using formail to extract the contents of those headers, then
using that information to see if anything in those headers matches with
a regular expression contained in /data/mail/filters/email_black_list

Such a file could contain multiple regular expressions each on one line.
I notice that you are running egrep with the -s switch. That might be a
problem. I don't use the -s or -q switch on egrep, so I'll need to do
some tests to see how it behaves.

Any hits on that blacklist file should terminate procmail processing and
will file the email in /dev/null

If you want to make procmail noisy about doing that you could rewrite
that recipe as follows

NL="
"

# Test if the email's sender is in the blacklist
:0
* ? formail -x"From" -x"From:" -x"Sender:" \
-x"Reply-To:" -x"Return-Path:" -x"To:" \
| egrep -is -f $MAILDIR/filters/email_black_list
{
LOG="[$$]$_: Found a blacklisted pattern in headers. Discarding
message.${NL}"
:0
/dev/null
}
# Else
:0 E
{ LOG="[$$]$_: No pattern match with email_black_list${NL}" }


Note, it's just a simple change to add procmail nesting blocks with LOG
lines stating what happened. You might think of it as more trouble to
do, but it can save you a lot of hassle in the long run.

> # Test if the email's sender is in the greylist
> :0
> * ? formail -x"From" -x"From:" -x"Sender:" \
> -x"Reply-To:" -x"Return-Path:" -x"To" \
> | egrep -is -f $MAILDIR/filters/email_grey_list
> junk

I would write this as:

# Test if the email's sender is in the greylist
:0:
* ? formail -x"From" -x"From:" -x"Sender:" \
-x"Reply-To:" -x"Return-Path:" -x"To" \
| egrep -is -f $MAILDIR/filters/email_grey_list
${MAILDIR}/junk

The ":0:" tells procmail to use an implied lockfile name that is derived
from the folder name. In this case that would be /data/mail/junk.lock
When procmail actually writes to this junk file, it will first check to
see if a lock file exists, if one exists, then it will wait for a while
(up to 15 minutes I think). When it finds the lockfile gone, procmail
will add it's own lockfile, then append the email currently in it's data
pipe to the file, then remove the lock file.

>
> # At this point, it would seem that the default doesn't work, so we need
> # to make a rule
> :0
> * ? formail -x"From" -x"From:" -x"Sender:" \
> -x"Reply-To:" -x"Return_Path:" -x"To" -x"To:"
> inbox

I would write this as:

# At this point, it would seem that the default doesn't work, so we need
# to make a rule
:0:
${MAILDIR}/inbox

You aren't egrepping anything, so there isn't really any need for a
recipe trigger condition.

Leaving a condition out, will have the rule always execute.
If you want to specify a lockfile instead of letting procmail figure one
out by itself, which is sometimes necessary, you can do that as follows:

:0: ${MAILDIR}/inbox.lock
${MAILDIR}/inbox

That might be necessary where you are writing to a named pipe, or
socket, or to a variable that may or may not expand to /dev/null and you
don't have write permissions in /dev to create a lockfile. In that case
you would create a local lockfile in your home directory that can be
written to.

If you don't see a need to use a lockfile, you can just leave the second
colon off

:0
/dev/null

Is fine in this case to have multiple processes writing to it.

but if you did this:

SPAMFOLDER=/dev/null

:0: ${MAILDIR}/spamfolder.lock
${SPAMFOLDER}

Then you could then define SPAMFOLDER to be either a real filename or
/dev/null and procmail would be work correctly with it either definition.

>
> # Anything that has not been delivered at the end will go to $DEFAULT
> # using LOCKFILE=$DEFAULT$LOCKEXT
> ---------
>
> And I've checked the blacklist several times: No typos, no ambiguous
> entries. On reflection, there is one entry, "*.redirectme.net", that
> has an initial asterisk (several hostnames at that location). Could
> that possibly be a problem? IE, could procmail be interpreting anything
> that has gotten past the white list as fodder for /dev/null? Academic,
> I suppose, now that the default is explicit.

If you want to test what you get, you could write a raw copy of a
suspect email to a file spam.txt and do this from the command line.

cat spam.txt |formail -x "Whatever" |egrep -if email_black_list

And see what you get.
If you get any hits at all, procmail would treat that as a non-zero exit
status, the test would be positive, thus causing the following action to
be taken.

>>[snip]
> Aha, that's a good bit more elegant than my solution. The ":0" followed
> by a colon is an explicit statement of "all mail", or some such? If so,
> I shall replace my solution with this one.

See above, the 2nd colon just instructs procmail to use an implied
lockfile for the following folder.

There are cases where it would not make sense to use a lockfile. In
those cases, you don't use the 2nd colon.

>
> So far, no unexpected email has arrived, so don't know what will happen,
> but the point is to discover what went wrong and fix it. That hasn't
> even begun, but thanks for the response!

You can force this issue also while debugging new recipes:

In one window do:
tail -f /path/to/procmail.log

And in another do:
cat spam.txt |procmail /home/username/.procmailrc

Or to test a recipe:
cat /path/to/spam.txt |procmail /home/username/test-procmail.rc

--
Garen

Re: Procmail losing mail?

Garen Erdoisa wrote:
> [snip]

> And see what you get.
> If you get any hits at all, procmail would treat that as a non-zero exit
> status, the test would be positive, thus causing the following action to
> be taken.

Correcting myself here for the record, I meant to say:

If you get any hits at all, procmail would treat that as a zero, or good
exit status, the test would be positive, thus causing the following
action to be taken.

>
>>> [snip]

--
Garen

Re: Procmail losing mail?

On 2006-04-15, Garen Erdoisa wrote:


>:) In your .procmailrc, you can also turn on verbose logging for more
> information. Just set VERBOSE=yes to do that.
> You probability won't want to leave it on because this can create huge
> procmail log files but it's to do that while debugging new or existing
> recipes to see what procmail is doing under the hood so to speak.

Okay, having digested this post, I set up a test routine with the
logfile and the inbox in $HOME. Copied a generic email to 'test.txt'.
Then I made another copy of ~/.procmailrc and edited it to point to the
new files and set the blacklist to the original full file. Also set
VERBOSE=yes.

Opened a tail -f on the logfile in one terminal, and did 'cat test.txt |
procmail $HOME/.procmailrc1' in another terminal. The logfile tail spit
out that the white list showed no hits, but that the blacklist did,
whereopen it assigned LASTFILE=/dev/null, and dumped the message.
Relevant part:

--------------
procmail: Executing " formail -x"From" -x"From:" -x"Sender:" \
-x"Reply-To:" -x"Return-Path:" -x"To:" \
| egrep -f $MAILDIR/filters/black.back"
procmail: Match on " formail -x"From" -x"From:" -x"Sender:" \
-x"Reply-To:" -x"Return-Path:" -x"To:" \
| egrep -f $MAILDIR/filters/black.back"
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
Folder: /dev/null
--------------

I tried passing a 0 byte file through and got the same response, so
presumably nothing in the file itself is triggering that routine. What
the VERBOSE doesn't tell me is exactly what is being matched, but I'd
bet that it's matching the first line of the blacklist. I think so
because the only blacklist file that doesn't trigger a match is a 0 byte
file.

Which suggests that something is going on within that stanza, which is an
exact match to the following one for the greylist. Yet when I commented
out the blacklist stanza, the greylist stanza found no match and passed
the file to $DEFAULT.

Is there an extra verbose mode where procmail will inform the logfile
what the match was that was found? I've looked at several authoritative
procmail websites (Tito Salmi and Nancy McGough, etc) and found no extra
noisy mode. Alternatively, is there a command that will have procmail
tell what the match was?

This is *weird*!

Longfellow

Re: Procmail losing mail?

Longfellow wrote:
> On 2006-04-15, Garen Erdoisa wrote:
>>
> [snip]
> I tried passing a 0 byte file through and got the same response, so
> presumably nothing in the file itself is triggering that routine. What
> the VERBOSE doesn't tell me is exactly what is being matched, but I'd
> bet that it's matching the first line of the blacklist. I think so
> because the only blacklist file that doesn't trigger a match is a 0 byte
> file.
>
> Which suggests that something is going on within that stanza, which is an
> exact match to the following one for the greylist. Yet when I commented
> out the blacklist stanza, the greylist stanza found no match and passed
> the file to $DEFAULT.
>
> Is there an extra verbose mode where procmail will inform the logfile
> what the match was that was found? I've looked at several authoritative
> procmail websites (Tito Salmi and Nancy McGough, etc) and found no extra
> noisy mode. Alternatively, is there a command that will have procmail
> tell what the match was?

Not really an extra level of verbosity, but there is a way to do this
anyway. It will require a slight re-design of your code.
Procmail has two ways it can execute external programs. You are using
one of them. In your method you are using the -s switch in egrep to
suppress any output from the egrep, which makes no difference to
procmail since it sends any output to /dev/null anyway when used in that
mode.

The other is to enclose your script inside of backticks and assign that
to a variable. You can them test or dump the variable to use it or see
what it contains or both.

Here is an example.

LOGFILE=/path/to/some/procmail.log
NL="
"

BUFFER=`formail -x "To:" -x "From:" |egrep -if blacklist_patterns`

:0
* ! BUFFER ?? ^^^^
{
LOG="[$$]$_: BUFFER=\"${BUFFER}\"${NL}"
}

In the above example, the first part will pass the data pipe to an
embedded shell script. The first command "formail" in that embedded
shell script will process the data contained in the procmail pipe, then
pipes it's filtered results on to the egrep command. That command will
compare the strings in the data pipe to regular expressions contained in
the "blacklist_patterns" file. If it finds a match, the output of the
match will be stored in the BUFFER variable.

That in turn is tested in the next recipe.
The syntax used there says "if BUFFER is not empty, then take the
action". The action in this case is just to log the contents of BUFFER
to the procmail log file, but could do anything you want it to do.

I use this type of structure in my procmail recipes all the time for
doing different things.

One thing you might check in your blacklist_patterns file, is if you
have any line with just a space and nothing else. Heh, if that is the
case, a space would match with most any extracted field data that
contained a space, thus returning a zero exit code causing the recipe
action to be triggered.

The blacklist_patterns file should contain no empty lines or spaces on
any one line. Another thing I noticed when reading the man page on
egrep, is that using the -s or -q switch can have egrep exit with zero
status saying it matched, even if there is an error in a regular
expression. I think that not all versions of egrep do this.

--
Garen

Re: Procmail losing mail?

On 2006-04-16, Garen Erdoisa wrote:


> Here is an example.
>
> LOGFILE=/path/to/some/procmail.log
> NL="
> "
>
> BUFFER=`formail -x "To:" -x "From:" |egrep -if blacklist_patterns`
>
>:0
> * ! BUFFER ?? ^^^^
> {
> LOG="[$$]$_: BUFFER=\"${BUFFER}\"${NL}"
> }
>
> In the above example, the first part will pass the data pipe to an
> embedded shell script. The first command "formail" in that embedded
> shell script will process the data contained in the procmail pipe, then
> pipes it's filtered results on to the egrep command. That command will
> compare the strings in the data pipe to regular expressions contained in
> the "blacklist_patterns" file. If it finds a match, the output of the
> match will be stored in the BUFFER variable.
>
> That in turn is tested in the next recipe.
> The syntax used there says "if BUFFER is not empty, then take the
> action". The action in this case is just to log the contents of BUFFER
> to the procmail log file, but could do anything you want it to do.

Okay. Did a new .procmailrc with just these two recipes in addition to
the usual assignments. This worked fine. If there was no match, it
said so:

--------------
procmail: Assigning "BITBUCKET=/dev/null"
procmail: Assigning "BLACKFILE=/data/mail/filters/black.back"
procmail: Assigning "NL=
"
procmail: Executing "formail -x"To:" -x"From:" -x"Reply-To:"
-x"Sender" -x"Return-Path" -x"To:" | egrep -if $BLACKFILE"
procmail: Assigning "BUFFER="
procmail: No match on ! "^^^^"
--------------

when I added the URL of the email to the blacklist, it found a match:

--------------
procmail: Assigning "BITBUCKET=/dev/null"
procmail: Assigning "BLACKFILE=/data/mail/filters/black.back"
procmail: Assigning "NL=
"
procmail: Executing "formail -x"To:" -x"From:" -x"Reply-To:"
-x"Sender" -x"Return-Path" -x"To:" | egrep -if $BLACKFILE"
procmail: Assigning "BUFFER= "
procmail: Match on ! "^^^^"
procmail: Assigning "LOG=[22553]/home/./.procmailrc2: BUFFER="{
}"
--------------

What this suggests is that the formula itself works as it should. I
think that what I'm going to do is to delete the offending recipe from
the test procmailrc and retype it.

~~~

Well, I don't know what to say, other than I may have witnessed one of
those genuine UNIX mysteries. Retyped the recipe *exactly*, and now it
works just fine!!! Ummm, actually not: I replaced the full path of the
blacklist with an assigned string variable in the recipe. Have no idea
in the world if that did or did not make a difference, but it works
now...

> I use this type of structure in my procmail recipes all the time for
> doing different things.

I'll save that one.

> One thing you might check in your blacklist_patterns file, is if you
> have any line with just a space and nothing else. Heh, if that is the
> case, a space would match with most any extracted field data that
> contained a space, thus returning a zero exit code causing the recipe
> action to be triggered.

Checked that. No empty lines and no spaces. Just email URLs.

> The blacklist_patterns file should contain no empty lines or spaces on
> any one line. Another thing I noticed when reading the man page on
> egrep, is that using the -s or -q switch can have egrep exit with zero
> status saying it matched, even if there is an error in a regular
> expression. I think that not all versions of egrep do this.
>
> --
> Garen

So now I'm going to retype the recipe in the real .procmailrc and send a
test email to see what happens.

~~~

Hallelujah and Amen!! I am now a confirmed devotee of the UNIX deux en
machina. I shall prostrate myself before the UNIX deities at least once
a year in fealty, for they have performed a $MIRACLE. I am a True
Believer!!! LOL!!!

Would you believe that I simply retyped the stanza itself, substituting
only a string variable for the relevant file, and now it works just
fine. An anomalous test email made it through past the bit bucket into
the inbox, and now I'll never discover what it was that was wrong.

But enough of that. You, sir, have been of extraordinary help and I do
appreciate it. I've learnt more than a thing or two about Procmail, and
finally recalled a time tested trouble-shooting ploy: when all else
fails, simply replace the malfunctioning part and get on with it!

All the best,

Longfellow