procmail
[Top] [All Lists]

Re: some spammers sneaking into my greenbox

2001-07-19 15:50:08
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

<Prev in Thread] Current Thread [Next in Thread>