At 21:51 2001-07-19 +0100, Nancy McGough wrote:
For a long time now, I have been successfully using this recipe
:0:
* ? formail -rtzxTo: | fgrep -i -f $PMDIR/greenlist
in-greenbox
to place messages from people who I correspond with into my
greenbox. Recently some messages that have a From: (and `From ')
header that contain an email address that is *not* in my
greenlist have been delivered to my in-greenbox. One oddity is
formail -xFrom:
would be matching against the From: header. You are not using this syntax
- you're using the address which a reply would be directed to, which can
often be VERY different. See the manpage for formail...
that the From: header shows up between Received: headers so maybe
it is bogus and `formail -r' ignores it?
No. However, interspersed received headers is usually a sign of
spam. Unfortunatley, some list remailers bodge the headers and this can't
be relied upon as it once could be -- I merely emit a logfile entry about a
spam advisory, but don't ditch the message. It would be useful in scoring
though.
Is anyone else using a
recipe like this and seeing this? Part of my problem in trying to
debug this is that I don't really know what algorithm `formail
-r' uses to generate the autoreply To: header.
Here's a suggestion I offer at least once a week in this forum: turn on
verbose logging.
Since you can simply take the above rule and make a standalone rc file from
it (with a procmailrc wrapper that sets up a test environment - see the
references in the URL in my sig), then take your mailbox and pipe it into
formail to split it up and run it through procmail. on a standalone rcfile
(with verbose logging, but either storing them to a DIFFERENT mailbox or
throwing them away outright). Then run through the logfile and check what
it says.
I'd appreciate any
thoughts about how to debug this and figure out how those
spammers are getting false matches against my greenlist!
formail -r doesn't inherently use the From: address -- it follows the
precedence of replies, which includes Reply-To:. Check for other headers
which contain greenlist elements (perhaps your OWN email address?).
The logfile will be rather illuminating to you.
Just before queuing, I saw Pollywog <croak(_at_)shadypond(_dot_)com> post:
I am not sure about this, but shouldn't the -rtzxTo: be instead
-rtzx"To:" ?
No. One quotes headers when using -I and similar options, which may
involve content with WHITESPACE, which would otherwise be interpreted as
option delimiters.
I happen to use a nearly identical formail commandline to extract the
sender (as versus the From address) of a message:
:0h
SENDER=| formail -b -rtzxTo:
This can be done once at the top of the procmailrc (along with several
other common components - From:, To: (not cc), and Subject), which makes it
easy for other recipes elsewhere to make repetative use of them without
having to invoke formail on each recipe. It also helps to avoid multiple
match issues. With the above line, one would then rewrite the recipe in
question as:
:0:
* ? fgrep -i $SENDER $PMDIR/greenlist
in-greenbox
I actually use a method wherein the matched string (which would be emitted
by the grep) is stored in a variable, and that variable is used to emit a
meaningful logfile entry. Note that as originally written, I'm loggging
SPAM events (thus 'FAILKEY'), so the logfile entry is representative of
something being REMOVED from the mail spool - one might not normally want
to individually identify what address MATCHED in a good match. The
following is a quickly modified code fragment:
# this recipe doesn't DELIVER, it merely sets a variable based on whether the
# name is located in the greenlist file.
:0h
FAILKEY=fgrep -i $SENDER $PMDIR/greenlist
# If failkey is nonblank, we matched something. Oh goodie.
:0
* ! $FAILKEY ?? ^^^^
{
LOG="GREENLIST: Match against [$FAILKEY]
"
:0:
in-greenlist
}
The benefit of this is that the element from the greenlist (or whatever
sort of list it might be) is identified for your log -- a regular
invocation of fgrep - esp against a series of headers (which is how my form
of this recipe operates) will not identify WHAT matched, merely that there
was a match. Likewise, the MATCH operations of procmail won't do you any
good, because procmail isn't perorming the regex of the data - fgrep is.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail