procmail
[Top] [All Lists]

Re: procmail bug? {nested blocks}

2005-06-12 11:48:13
At 12:35 2005-06-12 -0500, Damian Menscher wrote:
I may have found a bug in procmail (or maybe I'm just misinterpreting
the manpage ;)

I'm trying to filter out "virus bounce spam" (spam that advertises
the remote end's virus filter by spewing out bounce messages to mail
that supposedly came from you (but didn't, as the From: header was
spoofed)).

The idea is to look at messages from the remote mailer that contain,
in the body, headers from the original message they received.  These
headers often take the form:

Received: from server.ourdomain.com (infected.victim.com [222.222.222.222])

Assuming ourdomain.com has the netblock 111.111.x.x, it is safe to
key off the IP address.

And further assuming that the bounce message includes the supposed headers...

:0H

H is the default, so it is unnecessary to include it. USUALLY, it wouldn't be an inherent problem to include it, but this is the crux of the bug. Drop the H and see how things work.

<http://www.xray.mpe.mpg.de/mailing-lists/procmail/2002-08/msg00075.html>

* ^FROM_MAILER
{
   :0BD

You appear to be missing the trailing ':' to enable a lockfile. Also, why the case sensitivity?

   * ^Received: from .*ourdomain.com \(.*\[[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\]\)
   * !^Received: from .*ourdomain.com \(.*\[111.111.[0-9]+\.[0-9]+\]\)
   virus_bounce_spam
}

Basically, it should* look in the body for a Received: line that
claims to be from ourdomain.com, but isn't (as demonstrated by the
faked IP.

Simplification, and one which shouldn't encounter the bug:

:0:
* ^FROM_MAILER
* B ?? ^Received: from .*ourdomain.com \(.*\[[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\]\)
* B ?? !^Received: from .*ourdomain.com \(.*\[111.111.[0-9]+\.[0-9]+\]\)
virus_bounce_spam


Problem is, this doesn't seem to be working.

Your verbose logs tell you what?

But, as I understand it, the :B means it should *only* check the body,
not the headers.

There's a known bug with the 3.22 version of procmail where enabling H on a recipe causes all further recipes to act as if H is enabled on them.

---
 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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

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