procmail bug? {nested blocks}

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.

So... I came up with the following:

:0H
* ^FROM_MAILER
{
:0BD
* ^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.

Problem is, this doesn't seem to be working. The internal block (the
part beginning with :0BD) is matching lines in the message _header_.
In particular, it's matching stuff from localhost, which looks like:

Received: from server.ourdomain.com (localhost.localdomain [127.0.0.1])

But, as I understand it, the :B means it should *only* check the body,
not the headers. So... what's going on? Best guess is that I'm
misinterpreting the following sentence in procmailrc(5):
"On a nesting block, the flags H and B only affect the conditions
leading up to the block, the flags h and b have no effect whatsoever."
I assumed (possibly incorrectly) that the H rule in my outer block
would affect only the outer block, and that I didn't need a b to pass
the body to the inner block.

We're using procmail v3.22 2001/09/10 from RedHat's procmail-3.22-9
package. Any advice appreciated.

Damian Menscher
--
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-

Re: procmail bug? {nested blocks}

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.
>
> So... I came up with the following:
>
> :0H
> * ^FROM_MAILER
> {
> :0BD
> * ^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.
>
> Problem is, this doesn't seem to be working. The internal block (the
> part beginning with :0BD) is matching lines in the message _header_.
> In particular, it's matching stuff from localhost, which looks like:
>
> Received: from server.ourdomain.com (localhost.localdomain [127.0.0.1])
>
> But, as I understand it, the :B means it should *only* check the body,
> not the headers. So... what's going on? Best guess is that I'm
> misinterpreting the following sentence in procmailrc(5):
> "On a nesting block, the flags H and B only affect the conditions
> leading up to the block, the flags h and b have no effect whatsoever."
> I assumed (possibly incorrectly) that the H rule in my outer block
> would affect only the outer block, and that I didn't need a b to pass
> the body to the inner block.
>
> We're using procmail v3.22 2001/09/10 from RedHat's procmail-3.22-9
> package. Any advice appreciated.
>
> Damian Menscher

There is a bug in some of the earlier versions of procmail v3.22 that is
fixed in the later versions where the first use of B or H flags has
procmail recipes subesequently looking at both the header and body of
messages instead of just the header or the body. This bug unfortunately
affects just about ever flavour of Linux/Unix/BSD that uses the buggy
procmail v3.22.

Fix is to either upgrade procmail to a version that has been fixed, or
downgrade to the earlier version of procmail, v3.15 (I think) which
works correctly, or you can stay with the current version but use the
following alternative style as a workaround to this particular bug.

Workaround example:
:0
* H ?? ^FROM_MAILER
{
:0D
* 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
}

Re: procmail bug? {nested blocks}

On comp.mail.misc, in , "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.
>
> So... I came up with the following:

>
>:0H
> * ^FROM_MAILER
> {
> :0BD
> * ^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.
>
> Problem is, this doesn't seem to be working. The internal
> block (the part beginning with :0BD) is matching lines in the
> message _header_. In particular, it's matching stuff from
> localhost, which looks like:
>
> Received: from server.ourdomain.com (localhost.localdomain
> [127.0.0.1])
>
> But, as I understand it, the :B means it should *only* check
> the body, not the headers. So... what's going on? Best
> guess is that I'm misinterpreting the following sentence in
> procmailrc(5): "On a nesting block, the flags H and B only
> affect the conditions leading up to the block, the flags h and
> b have no effect whatsoever." I assumed (possibly incorrectly)
> that the H rule in my outer block would affect only the outer
> block, and that I didn't need a b to pass the body to the inner
> block.
>

That's it. Try this instead:

:0HB
* ^FROM_MAILER
* ^Received: from .*ourdomain.com \(.*\[[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\]\)
{

....

}

> We're using procmail v3.22 2001/09/10 from RedHat's
> procmail-3.22-9 package. Any advice appreciated.
>

Hope that helps.

----------


Sigs are supposed to be sigs, not bulletin boards. They aren't
supposed to get in people's faces. The Netiquette limit is 4
lines, including spaces, after the delimeter "-- ".

As for you disclaimer regarding your employer, that's just
silly: They hired you to do this sort of work _for_ them.
Therefore, anything you have to say in public regarding
this sort of work _is_ them speaking.

AC

--
alanconnor AT earthlink DOT net
Use your real return address or I'll never know you
even tried to mail me. http://tinyurl.com/2t5kp

Re: procmail bug? {nested blocks}

Garen Erdoisa wrote:
> 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.
>>
>> So... I came up with the following:
>>
>> :0H
>> * ^FROM_MAILER
>> {
>> :0BD
>> * ^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.
>>
>> Problem is, this doesn't seem to be working. The internal block (the
>> part beginning with :0BD) is matching lines in the message _header_.
>> In particular, it's matching stuff from localhost, which looks like:
>>
>> Received: from server.ourdomain.com (localhost.localdomain [127.0.0.1])
>>
>> But, as I understand it, the :B means it should *only* check the body,
>> not the headers. So... what's going on? Best guess is that I'm
>> misinterpreting the following sentence in procmailrc(5):
>> "On a nesting block, the flags H and B only affect the conditions
>> leading up to the block, the flags h and b have no effect whatsoever."
>> I assumed (possibly incorrectly) that the H rule in my outer block
>> would affect only the outer block, and that I didn't need a b to pass
>> the body to the inner block.
>>
>> We're using procmail v3.22 2001/09/10 from RedHat's procmail-3.22-9
>> package. Any advice appreciated.
>>
>> Damian Menscher
>
>
> There is a bug in some of the earlier versions of procmail v3.22 that is
> fixed in the later versions where the first use of B or H flags has
> procmail recipes subesequently looking at both the header and body of
> messages instead of just the header or the body. This bug unfortunately
> affects just about ever flavour of Linux/Unix/BSD that uses the buggy
> procmail v3.22.
>
> Fix is to either upgrade procmail to a version that has been fixed, or
> downgrade to the earlier version of procmail, v3.15 (I think) which
> works correctly, or you can stay with the current version but use the
> following alternative style as a workaround to this particular bug.
>
> Workaround example:
> :0
> * H ?? ^FROM_MAILER
> {
> :0D
> * 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
> }

Garen,

Is there a patch or a way to determine whether the procmail v3.22 has
this bug?

AK

Re: procmail bug? {nested blocks}

AK wrote:
> Garen Erdoisa wrote:
>
>> 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.
>>>
>>> So... I came up with the following:
>>>
>>> :0H
>>> * ^FROM_MAILER
>>> {
>>> :0BD
>>> * ^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.
>>>
>>> Problem is, this doesn't seem to be working. The internal block (the
>>> part beginning with :0BD) is matching lines in the message _header_.
>>> In particular, it's matching stuff from localhost, which looks like:
>>>
>>> Received: from server.ourdomain.com (localhost.localdomain [127.0.0.1])
>>>
>>> But, as I understand it, the :B means it should *only* check the body,
>>> not the headers. So... what's going on? Best guess is that I'm
>>> misinterpreting the following sentence in procmailrc(5):
>>> "On a nesting block, the flags H and B only affect the conditions
>>> leading up to the block, the flags h and b have no effect whatsoever."
>>> I assumed (possibly incorrectly) that the H rule in my outer block
>>> would affect only the outer block, and that I didn't need a b to pass
>>> the body to the inner block.
>>>
>>> We're using procmail v3.22 2001/09/10 from RedHat's procmail-3.22-9
>>> package. Any advice appreciated.
>>>
>>> Damian Menscher
>>
>>
>>
>> There is a bug in some of the earlier versions of procmail v3.22 that
>> is fixed in the later versions where the first use of B or H flags has
>> procmail recipes subesequently looking at both the header and body of
>> messages instead of just the header or the body. This bug
>> unfortunately affects just about ever flavour of Linux/Unix/BSD that
>> uses the buggy procmail v3.22.
>>
>> Fix is to either upgrade procmail to a version that has been fixed, or
>> downgrade to the earlier version of procmail, v3.15 (I think) which
>> works correctly, or you can stay with the current version but use the
>> following alternative style as a workaround to this particular bug.
>>
>> Workaround example:
>> :0
>> * H ?? ^FROM_MAILER
>> {
>> :0D
>> * 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
>> }
>
>
> Garen,
>
> Is there a patch or a way to determine whether the procmail v3.22 has
> this bug?
I don't know about a patch, I'm still using the buggy procmail version
myself diliberately, so I can make sure procmail code that I write will
work correctly on either the bugged version or normal versions.

I know that Fedeora core 1 has the buggy procmail version, while Fedora
core 2 does not. I haven't checked fedeora core 3. Feedback from others
indicates that the buggy procmail version shipped with a lot of the
current linux/unix/bsd versions out there, so unless these have
subsequently been upgraded there are probabally a lot of installations
out there with the bug.

>
> AK

Credits for the following test go to the spambouncer development team.

This is a procmail test script you can use to check if you have the
buggy procmail v3.22 or not.

If you do have the bugged version, the m3 variable will match the string
in the header instead of the body as it should.

After saving the following 2 files, from the command line type
(presuming you are running some flavor of BSD/unix/linux)

procmail p.rc
or (using bash shell syntax to direct stderr to stdout)

procmail p.rc &1 |less

############################################################ ####
#########Save the following text to a file named "msg.txt" #####
From foo@bar.com
X-headermatchstick1

-- body begin
bodymatchstick2
-- body end


########Save the following to a file named "p.rc" #########
# Note, depending on how your news reader/email client saves
# messages you may have to convert an end of line CRLF to just a LF
# in the following procmail test recipe
# Some email clients will convert a LF to a CRLF when saving text
# messages to a file.

#==== p.rc ====
# procmail p.rc
VERBOSE=yes
MATCHSTICK="matchstick"

# Default style Normal test with variable expansion, should match header
only.
:0
* $ ^.*\/${MATCHSTICK}[1-9]
{ m1=$MATCH }

# 1st style Header flag test with variable expansion, should match
header only.
:0 H
* $ ^.*\/${MATCHSTICK}[1-9]
{ m2=$MATCH }

# 1st style Body flag test with variable expansion, Should match body only.
# Buggy procmail v3.22 will match with the header instead
:0 B
* $^.*\/${MATCHSTICK}[1-9]
{ m3=$MATCH }

# 2nd style Body flag test with variable expansion, Should match body only.
:0
* $ B ?? ^.*\/${MATCHSTICK}[1-9]
{ m4=$MATCH }

# 2nd style Header flag test with variable expansion, Should match
header only.
:0
* $ H ?? ^.*\/${MATCHSTICK}[1-9]
{ m5=$MATCH }

# 2nd style Header and Body flag test with variable expansion, should
match the string in body only.
:0
* $ BH ?? ^.*\/${MATCHSTICK}[2]
{ m6=$MATCH }

# 2nd style Header and Body flag test with variable expansion, should
match the string in header only.
:0
* $ BH ?? ^.*\/${MATCHSTICK}[1]
{ m7=$MATCH }

# 2nd style Header and Body flag test, should match the string in body only.
:0
* BH ?? ^.*\/matchstick[2]
{ m8=$MATCH }

# 2nd style Header and Body flag test, Should match the string in header
only.
:0
* BH ?? ^.*\/matchstick[1]
{ m9=$MATCH }

# 2nd style Header and Body flag test, should match both strings, header
and body
# then add the scores for a total score of 2. m10 should contain the
header match.
:0
* B ?? 1^0 ^matchstick[2]
* H ?? 1^0 ^.*\/matchstick[1]
{
score=$=
m10=$MATCH
}

# 2nd Style, same as above but with variable expansion also
# m11 should contain the body match.
: 0
* $ H ?? 1^0 ^${MATCHSTICK}[1]
* $ B ?? 1^0 ^.*\/${MATCHSTICK}[2]
{
score=$=
m11=$MATCH
}

:0
/dev/null