*This is a multi-post reply.*
At 12:31 PM 12/2/99 +0200, Era wrote:
> I figured out where the issue was.
> In the ackmail.rc:
> # Replace the body with the ack message
> :0 fbw
> | cat $ACKFILE
> I had to add a "-" (dash) either after or before the $ACKFILE.
Confusion. I can't see how this affects Procmail's PATH in any way.
Neither do I.
I *think* it has something to do with the pipe. The error that I was
getting in my log file was "Error while writing to cat".
I looked that up in the man pages, and it says:
"Nonexistent subdirectory, no write permission, pipe died or disk full."
Since A, B, and D aren't true, I'm thinking it's C....
I have no clue what putting that "-" (either before or after) did to the
pipe, all I know is that now it works...
At 06:17 PM 12/1/99 -0600, "David W. Tamkin" <dattier(_at_)Mcs(_dot_)Net> wrote:
> Era suggested to Mark,
> E> You could of course say something like
> E>
> E> :0
> E> * ! ^TO(_at_)mediaone(_dot_)net
> E> { INCLUDERC=ackmail.rc }
> Mark responded,
> H> This worked wonderfully, btw. :)
> Beats me how. That regexp should never match, so the condition, being
> negated, should always pass, and the INCLUDERC should always be processed.
> The expansion of ^TO cannot end in a letter or a digit, and I'd tend to
> expect that the local part of an address @mediaone.net will almost always
> end with such a character. It really ought to look more like this;
> :0
> * ! ^TO[a-z0-9_]+(_at_)mediaone\(_dot_)net
> { INCLUDERC=ackmail.rc }
I should have clarified. Era's recipe in itself didn't work, as I didn't
try it. I was not aware that you could nest an INCLUDERC in a recipe.
This is actually my format now:
# Kansas City
:0
* ^(To:|Cc:).*(abuse|security|fraud|spam)@kc\.rr\.com
{
INCLUDERC=ackmail.rc
:0c:
ce-kc
:0:
$BACKUP/ce-kc
}
and so on....
> H> SUBJ=`formail -xSubject:`
> That's much better, Mark. Another thing that was wrong with the original
> was the redundant `c' flag on a variable capture recipe. You might want,
> though, to put the -z option back, as usually there will be a space after
> the colon in the subject header, and you probably won't want a leading
space
> in $SUBJ.
> Here's a suggestion for handling both that and empty incoming subjects, and
> saving a process by not calling formail there at all:
> SUBJ='(no subject)' # default value
> :0h # if there is a non-blank subject, use that instead
> * ^Subject:[ ]*\/[^ ].*
> { SUBJ=$MATCH }
That's cool. So, then later on I would still call $SUBJ?
:0 fhw
| formail -rtI"From: $FROMSIG" \
-I"Reply-To: please_do_not_reply(_at_)rr(_dot_)com" \
-I"Precedence: junk" \
-I"Subject: [$ACKM] $SUBJ " \
-I"X-Loop: $MY_ADDR" \
-I"References:"
I wouldn't call $MATCH, correct?
W. Mark Herrick, Jr. <markh(_at_)va(_dot_)rr(_dot_)com> _.._
_.._
Senior Security Administrator ,','"_:./\/\,'_ `.`.
Team Lead - Usenet Operations /_:--:_ ( oo ) _:--:_\
Road Runner Security - 703.345.2477 /' `'`vv'`' `\
<abuse(_at_)rr(_dot_)com><security(_at_)rr(_dot_)com><fraud(_at_)rr(_dot_)com>