Mailing List Archive: SpamAssassin: users

possible idea for backscatter problem

Index | Next | Previous | View Threaded

printer at afts

May 7, 2008, 2:58 PM

Post #1 of 17 (241 views)
Permalink

possible idea for backscatter problem

One of the users (actually the boss) had the email address harvested and we got clobbered
by backscatter. Looking at the emails of the various 'unable to deliver' type messages, I saw
what these could be filtered on, but don't know how to write up and implement the rule
outside of procmail. I don't want to use procmail for this since it I think it would be an
expensive routine for procmail to run.

In the body of the 'unable to deliver' message, the original message is quoted. One of the
lines quoted is the Message-ID: header from the original. The format of this line is always
wrong as it does not contain the FQDN that our server appends to the end of the hash
number , following the '@' symbol .

So, need a rule that would parse the "Message-ID:" in the body (or attachment) and not
header, and look for the @FQDN
Is this rule already out in the wild?
-p

mkettler_sa at verizon

May 7, 2008, 11:22 PM

Post #2 of 17 (226 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

.rp wrote:
> One of the users (actually the boss) had the email address harvested and we got clobbered
> by backscatter. Looking at the emails of the various 'unable to deliver' type messages, I saw
> what these could be filtered on, but don't know how to write up and implement the rule
> outside of procmail. I don't want to use procmail for this since it I think it would be an
> expensive routine for procmail to run.
>
> In the body of the 'unable to deliver' message, the original message is quoted. One of the
> lines quoted is the Message-ID: header from the original. The format of this line is always
> wrong as it does not contain the FQDN that our server appends to the end of the hash
> number , following the '@' symbol .
>
> So, need a rule that would parse the "Message-ID:" in the body (or attachment) and not
> header, and look for the @FQDN
> Is this rule already out in the wild?
>
(note: your To: was the bogofilter list, but this appeared on
spamassassin-users as well.. It looks like you bcc'ed the SA list.
Anyway, I'm answering on the SA list because that's where I picked up
the message from)

Not that I know of, but it would be fairly quick as a spamassassin rule.

You'd likely need a meta of some sort.

Theoretically, something like this should work. I'm leveraging some of
the stock ruleset here, by reusing BOUNCE_MESSAGE to detect if the
message really is a bounce, make sure it is in your ruleset.

----------

body __BOUNCE_HASMSGID /Message-ID:/
body __BOUNCE_MINE /Message-ID:.{1,40}.\@example\.com/

meta BOUNCE_NOTMINE (BOUNCE_MESSAGE && __BOUNCE_HASMSGID && !__BOUNCE_MINE)
score BOUNCE_NOTMINE 0.1
describe BOUNCE_NOTMINE Appears to be a bounce with a message without a
valid message ID.

----------

Modify the example.com part to suit your needs.

Be sure to run spamassassin --lint after adding it.

Note: I've intentionally set to score to 0.1, as this rule isn't tested.
It theoretically should do its job, but make sure it works properly
before you increase the score.

jm at jmason

May 8, 2008, 1:35 AM

Post #3 of 17 (227 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

Matt Kettler writes:
> .rp wrote:
> > One of the users (actually the boss) had the email address harvested and we got clobbered
> > by backscatter. Looking at the emails of the various 'unable to deliver' type messages, I saw
> > what these could be filtered on, but don't know how to write up and implement the rule
> > outside of procmail. I don't want to use procmail for this since it I think it would be an
> > expensive routine for procmail to run.
> >
> > In the body of the 'unable to deliver' message, the original message is quoted. One of the
> > lines quoted is the Message-ID: header from the original. The format of this line is always
> > wrong as it does not contain the FQDN that our server appends to the end of the hash
> > number , following the '@' symbol .
> >
> > So, need a rule that would parse the "Message-ID:" in the body (or attachment) and not
> > header, and look for the @FQDN
> > Is this rule already out in the wild?
> >
> (note: your To: was the bogofilter list, but this appeared on
> spamassassin-users as well.. It looks like you bcc'ed the SA list.
> Anyway, I'm answering on the SA list because that's where I picked up
> the message from)
>
> Not that I know of, but it would be fairly quick as a spamassassin rule.
>
> You'd likely need a meta of some sort.
>
> Theoretically, something like this should work. I'm leveraging some of
> the stock ruleset here, by reusing BOUNCE_MESSAGE to detect if the
> message really is a bounce, make sure it is in your ruleset.

Actually, that's overkill -- BOUNCE_MESSAGE _already_ does this.

the VBounce plugin is intended to catch backscatter -- bounces in response
to mail you didn't send -- so it'll ignore bounces in response to mail you
_did_ send, by parsing the bounced message's Received: headers and looking
for the mailserver's name in there.

See the FAQ for more info...

--j.

mkettler_sa at verizon

May 8, 2008, 1:56 AM

Post #4 of 17 (227 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

Justin Mason wrote:
> Matt Kettler writes:
>
>> .rp wrote:
>>
>>> One of the users (actually the boss) had the email address harvested and we got clobbered
>>> by backscatter. Looking at the emails of the various 'unable to deliver' type messages, I saw
>>> what these could be filtered on, but don't know how to write up and implement the rule
>>> outside of procmail. I don't want to use procmail for this since it I think it would be an
>>> expensive routine for procmail to run.
>>>
>>> In the body of the 'unable to deliver' message, the original message is quoted. One of the
>>> lines quoted is the Message-ID: header from the original. The format of this line is always
>>> wrong as it does not contain the FQDN that our server appends to the end of the hash
>>> number , following the '@' symbol .
>>>
>>> So, need a rule that would parse the "Message-ID:" in the body (or attachment) and not
>>> header, and look for the @FQDN
>>> Is this rule already out in the wild?
>>>
>>>
>> (note: your To: was the bogofilter list, but this appeared on
>> spamassassin-users as well.. It looks like you bcc'ed the SA list.
>> Anyway, I'm answering on the SA list because that's where I picked up
>> the message from)
>>
>> Not that I know of, but it would be fairly quick as a spamassassin rule.
>>
>> You'd likely need a meta of some sort.
>>
>> Theoretically, something like this should work. I'm leveraging some of
>> the stock ruleset here, by reusing BOUNCE_MESSAGE to detect if the
>> message really is a bounce, make sure it is in your ruleset.
>>
>
> Actually, that's overkill -- BOUNCE_MESSAGE _already_ does this.
>

Whoops.. good point. I didn't read the code, I just saw the name and
assumed it did just what it says, and nothing more.

So, really all .rp needs to do is enable the vbounce plugin (which is
loaded by default )

jm at jmason

May 8, 2008, 2:02 AM

Post #5 of 17 (227 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

Matt Kettler writes:
> Justin Mason wrote:
> > Matt Kettler writes:
> >
> >> .rp wrote:
> >>
> >>> One of the users (actually the boss) had the email address harvested and we got clobbered
> >>> by backscatter. Looking at the emails of the various 'unable to deliver' type messages, I saw
> >>> what these could be filtered on, but don't know how to write up and implement the rule
> >>> outside of procmail. I don't want to use procmail for this since it I think it would be an
> >>> expensive routine for procmail to run.
> >>>
> >>> In the body of the 'unable to deliver' message, the original message is quoted. One of the
> >>> lines quoted is the Message-ID: header from the original. The format of this line is always
> >>> wrong as it does not contain the FQDN that our server appends to the end of the hash
> >>> number , following the '@' symbol .
> >>>
> >>> So, need a rule that would parse the "Message-ID:" in the body (or attachment) and not
> >>> header, and look for the @FQDN
> >>> Is this rule already out in the wild?
> >>>
> >>>
> >> (note: your To: was the bogofilter list, but this appeared on
> >> spamassassin-users as well.. It looks like you bcc'ed the SA list.
> >> Anyway, I'm answering on the SA list because that's where I picked up
> >> the message from)
> >>
> >> Not that I know of, but it would be fairly quick as a spamassassin rule.
> >>
> >> You'd likely need a meta of some sort.
> >>
> >> Theoretically, something like this should work. I'm leveraging some of
> >> the stock ruleset here, by reusing BOUNCE_MESSAGE to detect if the
> >> message really is a bounce, make sure it is in your ruleset.
> >>
> >
> > Actually, that's overkill -- BOUNCE_MESSAGE _already_ does this.
> >
>
> Whoops.. good point. I didn't read the code, I just saw the name and
> assumed it did just what it says, and nothing more.
>
> So, really all .rp needs to do is enable the vbounce plugin (which is
> loaded by default )

Yep. to enable it, just set "whitelist_bounce_relays" in the
configuration or user prefs.

--j.

jm at jmason

May 8, 2008, 2:03 AM

Post #6 of 17 (227 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

Henrik Krohns writes:
> On Thu, May 08, 2008 at 09:35:31AM +0100, Justin Mason wrote:
> >
> > the VBounce plugin is intended to catch backscatter -- bounces in response
> > to mail you didn't send -- so it'll ignore bounces in response to mail you
> > _did_ send, by parsing the bounced message's Received: headers and looking
> > for the mailserver's name in there.
>
> I've been trying it for myself. One thing I don't like is that all
> null-sender mail is assumed to be bounces. It creates many FPs.

Yes. What kind of null-sender mail from machines that are not in
whitelist_bounce_relays do you get?

> Also check https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5900

saw that...

--j.

hege at hege

May 8, 2008, 2:52 AM

Post #7 of 17 (223 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

On Thu, May 08, 2008 at 10:03:28AM +0100, Justin Mason wrote:
>
> Henrik Krohns writes:
> > On Thu, May 08, 2008 at 09:35:31AM +0100, Justin Mason wrote:
> > >
> > > the VBounce plugin is intended to catch backscatter -- bounces in response
> > > to mail you didn't send -- so it'll ignore bounces in response to mail you
> > > _did_ send, by parsing the bounced message's Received: headers and looking
> > > for the mailserver's name in there.
> >
> > I've been trying it for myself. One thing I don't like is that all
> > null-sender mail is assumed to be bounces. It creates many FPs.
>
> Yes. What kind of null-sender mail from machines that are not in
> whitelist_bounce_relays do you get?

I would assume this is common knowledge. :-)

- Mass mailings of all sorts, mailing lists, news
- Order confirmations
- Some very legimate mails from people using lotus notes, hotmail
- etc, etc..

You can just imagine a system/administrator thinking that it's wise to send
anything that "doesn't require a reply" as null. It's very common.

Do you want a bug opened?

jm at jmason

May 8, 2008, 3:35 AM

Post #8 of 17 (224 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

Henrik K writes:
> On Thu, May 08, 2008 at 10:03:28AM +0100, Justin Mason wrote:
> >
> > Henrik Krohns writes:
> > > On Thu, May 08, 2008 at 09:35:31AM +0100, Justin Mason wrote:
> > > >
> > > > the VBounce plugin is intended to catch backscatter -- bounces in response
> > > > to mail you didn't send -- so it'll ignore bounces in response to mail you
> > > > _did_ send, by parsing the bounced message's Received: headers and looking
> > > > for the mailserver's name in there.
> > >
> > > I've been trying it for myself. One thing I don't like is that all
> > > null-sender mail is assumed to be bounces. It creates many FPs.
> >
> > Yes. What kind of null-sender mail from machines that are not in
> > whitelist_bounce_relays do you get?
>
> I would assume this is common knowledge. :-)
>
> - Mass mailings of all sorts, mailing lists, news
> - Order confirmations
> - Some very legimate mails from people using lotus notes, hotmail
> - etc, etc..
>
> You can just imagine a system/administrator thinking that it's wise to send
> anything that "doesn't require a reply" as null. It's very common.

Not in my experience!

I haven't seen anything that isn't a bounce message, an out-of-office
notification, auto-replies, or other stuff targeted by the VBounce
ruleset. certainly not transactional mail. as far as I can tell, it's
*not* that common.

> Do you want a bug opened?

Nah, that's ok ;)

--j.

hege at hege

May 8, 2008, 3:53 AM

Post #9 of 17 (224 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

On Thu, May 08, 2008 at 11:35:30AM +0100, Justin Mason wrote:
>
> Not in my experience!
>
> I haven't seen anything that isn't a bounce message, an out-of-office
> notification, auto-replies, or other stuff targeted by the VBounce
> ruleset. certainly not transactional mail. as far as I can tell, it's
> *not* that common.

I can give you dozen sample emails from last week right now. Including
handwritten mails from people, that come from strange systems (Lotus, Live
Mail, Horde/IMP..) sending as null. There's a lot more, I don't have time to
check every mail. It *is* common. And this server only passes 15k mails a
day.

You are only talking about your own mailfeed, right? I can't believe you
would say this otherwise.

> > Do you want a bug opened?
>
> Nah, that's ok ;)

Well, frankly I have too much on my plate to start working on this too. So
I'll let it sleep for now. :)

rmueller at thinxsolutions

May 8, 2008, 6:11 AM

Post #10 of 17 (224 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

Henrik K schrieb:
> On Thu, May 08, 2008 at 11:35:30AM +0100, Justin Mason wrote:
>
>> Not in my experience!
>>
>> I haven't seen anything that isn't a bounce message, an out-of-office
>> notification, auto-replies, or other stuff targeted by the VBounce
>> ruleset. certainly not transactional mail. as far as I can tell, it's
>> *not* that common.
>>
>
> I can give you dozen sample emails from last week right now. Including
> handwritten mails from people, that come from strange systems (Lotus, Live
> Mail, Horde/IMP..) sending as null. There's a lot more, I don't have time to
> check every mail. It *is* common. And this server only passes 15k mails a
> day.
>
> You are only talking about your own mailfeed, right? I can't believe you
> would say this otherwise.
>
>
>>> Do you want a bug opened?
>>>
>> Nah, that's ok ;)
>>
>
> Well, frankly I have too much on my plate to start working on this too. So
> I'll let it sleep for now. :)
>
>
>
After my fix in the 20_vbounce.cf I had also several FPs, the most
significant the SA-bugzilla account confirmation mail. :-| Reason for
this was the simple match on 'daemon' in the "From:" -line regexp.
Is somebody already working on an enhancement of the ruleset?
Otherwise, if you can provide some of your FP's (and maybe some real
backscatter) I can imagine to put them together with mine and try to
improve the rules a little bit in the next few weeks.
BTW: Also for me 'null senders' are not common - never had problems with
this, except UBE. Correctly configured servers/clients should not
produce such mails, IMHO.
Robert

shanew at shanew

May 8, 2008, 6:14 AM

Post #11 of 17 (223 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

On Thu, 8 May 2008, Justin Mason wrote:

> Matt Kettler writes:
>> .rp wrote:
>>
>>> So, need a rule that would parse the "Message-ID:" in the body (or attachment) and not
>>> header, and look for the @FQDN
>>> Is this rule already out in the wild?
>>>
>> You'd likely need a meta of some sort.
>>
>> Theoretically, something like this should work. I'm leveraging some of
>> the stock ruleset here, by reusing BOUNCE_MESSAGE to detect if the
>> message really is a bounce, make sure it is in your ruleset.
>
> Actually, that's overkill -- BOUNCE_MESSAGE _already_ does this.
>
> the VBounce plugin is intended to catch backscatter -- bounces in response
> to mail you didn't send -- so it'll ignore bounces in response to mail you
> _did_ send, by parsing the bounced message's Received: headers and looking
> for the mailserver's name in there.

Pardon my ignorance if I'm just not understanding this right, but my
impression is that there's a possibility that messages marked the
BOUNCE_MESSAGE could be legitimate bounces (just not bounces generated
by a whitelisted server). Certainly I've read plenty of people on
this list advise against raising the vbounce rule scores as a way to
combat this new wave of seemingly intentional bounce spam, but rather
to filter all the bounces off to a separate folder.

But, doesn't the existence of a Message ID in the text of the bounce
that has a bogus or malformed email address provide a stronger
indication that this is not a valid bounce? In which case, such email
could be scored higher, rather than just sent to a bounce folder,
which is really what many of us would rather be doing with these
messages?

--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT iSchool
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew[at]shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew

hege at hege

May 8, 2008, 6:32 AM

Post #12 of 17 (224 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

On Thu, May 08, 2008 at 03:11:59PM +0200, Robert M�ller wrote:
>
> BTW: Also for me 'null senders' are not common - never had problems with
> this, except UBE.

Have you even looked at your traffic archives, if you keep one? How do you
know there isn't any problems if someone doesn't realize to report it?

I have concrete evidence.

> Correctly configured servers/clients should not produce such mails, IMHO.

That's just absurd. I could just as well say: "Correctly configured servers
don't create backscatter.". Yet we have the problem.

In case of VBounce, chances of FPs are even less acceptable. You are
supposed to reject or discard backscatter, I see no point in just tagging
it. So discarding is bad, but rejecting most likely means that sending party
doesn't get any notification of failure either.

Currently VBounce is only useful as "add little score and hope URIBL and
other checks match the returned body".

Hopefully someone has time to fix the too generic rules. We should only
match sure bounces.

rmueller at thinxsolutions

May 8, 2008, 7:31 AM

Post #13 of 17 (223 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

Henrik K schrieb:
> On Thu, May 08, 2008 at 03:11:59PM +0200, Robert M�ller wrote:
>
>> BTW: Also for me 'null senders' are not common - never had problems with
>> this, except UBE.
>>
>
> Have you even looked at your traffic archives, if you keep one? How do you
> know there isn't any problems if someone doesn't realize to report it?
>
I would have realized, if I had this problem, for sure.
> I have concrete evidence.
>
I believe you, no problem.
>
>> Correctly configured servers/clients should not produce such mails, IMHO.
>>
>
> That's just absurd. I could just as well say: "Correctly configured servers
> don't create backscatter.". Yet we have the problem.
>
I think you misunderstood me. Such mails are - in my experience - not
the majority, and therefore this issue is also for me not common and not
known as a big problem. Nothing more I wanted to say.
Now I hear different from you - fine, something learned.
> In case of VBounce, chances of FPs are even less acceptable. You are
> supposed to reject or discard backscatter, I see no point in just tagging
> it. So discarding is bad, but rejecting most likely means that sending party
> doesn't get any notification of failure either.
>
> Currently VBounce is only useful as "add little score and hope URIBL and
> other checks match the returned body".
>
ACK. Because this doesn't work in most cases, and the currently (for me)
unknown risk of FPs, I actually I sort them in a different folder.
> Hopefully someone has time to fix the too generic rules. We should only
> match sure bounces.
>
"Sure" is as always relative, but that was the goal, yes.
>
>

jm at jmason

May 8, 2008, 8:20 AM

Post #14 of 17 (222 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

> > In case of VBounce, chances of FPs are even less acceptable. You are
> > supposed to reject or discard backscatter

who says?

It seems perfectly fine to me to tag vbounce-filtered mail. In mail
filtering, there will always be FPs.

--j.

hege at hege

May 8, 2008, 8:34 AM

Post #15 of 17 (223 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

On Thu, May 08, 2008 at 04:20:42PM +0100, Justin Mason wrote:
>
> > > In case of VBounce, chances of FPs are even less acceptable. You are
> > > supposed to reject or discard backscatter
>
> who says?
>
> It seems perfectly fine to me to tag vbounce-filtered mail. In mail
> filtering, there will always be FPs.

Come on, we all know ISPs are not supposed to drop anything and that there
are users that insist on receiving all mail "to be sure".

This has nothing to do with VBounce (which is constantly touted as being
backscatter stopping tool). In not above scenarios, why would anyone want to
receive backscatter? VBounce is currently a FP-prone "match or not match"
tool for that purpose. Either you want backscatter or you don't.

For other things it's perfectly fine to tag "maybe spam" and discard "sure
spam". Now you can just hope that VBounce gets it over the discard limit.

printer at afts

May 11, 2008, 3:32 PM

Post #16 of 17 (184 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

Well I am confused.

# locate vbounce
/usr/share/spamassassin/updates_spamassassin_org/20_vbounce.cf
/usr/share/spamassassin/20_vbounce.cf
/var/lib/spamassassin/3.002000/updates_spamassassin_org/20_vbounce.cf

# locate VBounce
/usr/lib/perl5/vendor_perl/5.8.0/Mail/SpamAssassin/Plugin/VBounce.pm

both init.pre and v320.pre have the line
loadplugin Mail::SpamAssassin::Plugin::VBounce

yet in backscatter email, there is no mention of VBounce:

X-Spam-Status: Yes, score=4.1 required=3.9 tests=AWL,DATE_IN_PAST_96_XX,
FB_QUALITY_REPLICA,
MSGID_FROM_MTA_HEADER shortcircuit=no autolearn=disabled version=3.2.4
X-Spam-Report: * 1.0 DATE_IN_PAST_96_XX Date: is 96 hours or more before
Received: date * 3.9 FB_QUALITY_REPLICA BODY: Phrase: quality replica *
1.5 MSGID_FROM_MTA_HEADER Message-Id was added by a relay * -2.3 AWL
AWL: From: address is in the auto white-list

--- Below this line is a copy of the message.
Received: (qmail 6691 invoked from network); 2 May 2008 05:23:01 +0200
Received: from ppp254.stat120.pacific.net.ph (221.121.120.254)
by sd-1146.dedibox.fr with SMTP; 2 May 2008 05:23:00 +0200
Message-ID: <000501c8abfc$020217e2$e5ab44aa[at]hmbyy>

so how am I supposed to get this vbounce to work on backscatter's ?

___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.

guenther at rudersport

May 11, 2008, 7:34 PM

Post #17 of 17 (179 views)
Permalink

Re: possible idea for backscatter problem [In reply to]

On Sun, 2008-05-11 at 15:32 -0700, Tech Color printer wrote:
> so how am I supposed to get this vbounce to work on backscatter's ?

http://wiki.apache.org/spamassassin/FrequentlyAskedQuestions
http://wiki.apache.org/spamassassin/VBounceRuleset

Set whitelist_bounce_relays properly. Without knowing about legitimate
bounces, there are no illegitimate.

Also, as has been mentioned previously, do note that VBounce does NOT
block or otherwise raise the spam score significantly. You can do hat
yourself, or just filter as per the docs.

$ grep -A 2 procmail /usr/share/spamassassin/20_vbounce.cf

# If you use this, set up procmail or your mail app to spot the
# "ANY_BOUNCE_MESSAGE" rule hits in the X-Spam-Status line, and move
# messages that match that to a 'vbounce' folder.

guenther

--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com