Andrew followed up,
| One of your guesses is correct; /etc/procmailrc has code that
| delivers the messages.
| I am not sure how I will fix that, but I know it can be done. I am
| using Junkfilter, and this is what delivers the mail after Junkfilter
| has processed it:
I'm assuming that with the wrapping undone, it looks like this:
| INCLUDERC=$JFDIR/junkfilter
| :0
| * JFEXP ?? .
| {
| :0 f
| * JFSTATUS ?? 1
| | formail -i "X-junkfilter: $JFVERSION" -i "X-Spammer: $JFEXP"
|
| :0 E :
| | formail -i "X-junkfilter: $JFVERSION" -i "X-Spammer: $JFEXP" \
| >> $DEFAULT
|
| }
Well, yes, that will complete delivery of any message where $JFEXP includes a
character that is not a newline and $JFSTATUS does not include a numeral 1.
But what happens when JFEXP is empty, or when there's a 1 in JFSTATUS? Do
messages get to ~/.procmailrc then? If not, there's yet another barrier.
| I am not sure how to edit the last line so that the user .procmailrc
| can determine what to do with tagged messages based on the specific
| nature of the tag.
My suggestion is just to add the headers and don't deliver, just as you do
when there's a 1 in $JFSTATUS, and replace the code above with this:
INCLUDERC=$JFDIR/junkfilter
:0fwh # no need to run the body through the filter, nor to test JFSTATUS
* JFEXP ?? .
| formail -i "X-junkfilter: $JFVERSION" -i "X-Spammer: $JFEXP"
That way, as procmail proceeds into ~/.procmailrc, a user who wants procmail
to do things based on the values of JFEXP or JFSTATUS can do so, since the
variables will still be known to procmail there, while a user who doesn't use
procmail will be able to see the value of JFEXP in the X-Spammer: header.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail