You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/11/01 23:28:42 UTC

interesting paper on SoBig's authorship

http://authortravis.tripod.com/
http://www.geocities.com/author_travis/

veeeeery interesting!

--j.

Re: interesting paper on SoBig's authorship

Posted by Jeff Chan <je...@surbl.org>.
On Monday, November 1, 2004, 2:28:42 PM, Justin Mason wrote:
> http://authortravis.tripod.com/
> http://www.geocities.com/author_travis/

> veeeeery interesting!

> --j.

Nice work, whoever the mystery authors are...

Jeff C.
-- 
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/


Re[2]: interesting paper on SoBig's authorship

Posted by Robert Menschel <Ro...@Menschel.net>.
Hello Simon,

Monday, November 1, 2004, 6:04:53 PM, you wrote:

SB> One of the things mentioned in the article is that Spam ...
SB> is *ALSO* sent deliberately to addresses where it will
SB> bounce, with the actual intended recipient as the Return address
SB> ...\

SB> This is a technique I've been aware of for a long time now, and have
SB> brought the issue up in the past a couple of times, but are there any
SB> plan to combat this in future versions of SpamAssassin ?

I've been quite happy with
http://www.timj.co.uk/linux/bogus-virus-warnings.cf
from Tim Jackson. His scoring has been a bit more aggressive than I
like, but his rules work well for rejecting spam and virus bounces.

Bob Menschel



Re: interesting paper on SoBig's authorship

Posted by Simon Byrnand <si...@igrin.co.nz>.
> http://authortravis.tripod.com/
> http://www.geocities.com/author_travis/
>
> veeeeery interesting!
>
> --j.
>

One of the things mentioned in the article is that Spam Sent using
Send-Safe/Sobig as well as being delivered directly (using fake return
addresses etc) is *ALSO* sent deliberately to addresses where it will
bounce, with the actual intended recipient as the Return address - thus
the victim gets a bounce message with the spam attached, which usually
eludes spam filtering tools like Spamassassin. (Since the bounce isn't
actually spam, only the attachment within it)

This is a technique I've been aware of for a long time now, and have
brought the issue up in the past a couple of times, but are there any
plans to combat this in future versions of SpamAssassin ?

In recent times I'm seeing far more spam bounces, than normal spam
escaping spamassasin. (EG although spam bounces probably account for a
small percentage of spam at the moment, I find nearly all of them get past
spamassassin, and I think the percentage will increase)

As far as I can see it would basically mean scanning a message twice in
some cases, and the most efficient way to do it would be in SpamAssassin
itself, rather than hacking together external tools to extract the
attachment and two messages to SpamAssasin.

- 1st pass - scan as per normal.

- If the message is found to be spam using normal techniques, don't do
anything futher (eg, we got it, don't waste any more processing time)

- If the message is not spam, but it has what looks like an RFC822
attachment, (found in bounce messages) rescan the attachment as if it were
a message in its own right, (eg header rules apply to headers in the
attachment etc) and if THAT attachment is found to be spam, then we flag
it as spam with the score obtained within the attachment.

- If the attachment is clean, flag the message as ham, using the score
found in the containing (outside) message body.

Scanning attachments could be an optional .cf controlled feature.

The advantage I see is that in the vast majority of cases, the message is
still only scanned once, so the actual overhead is very low:

1) Ham doesn't often have attached emails, a few people like to forward
messages that way, but thankfully they're in the minority. ;-) So for the
majority of ham the code would just see there are no RFC822 attachments so
do nothing extra.

2) Normal spam will already be detected as spam anyway, so whether it has
a spammy attachment on top of that is irrelevant.

Case 1 and 2 account for the vast majority of messages.

As far as I can see there are only two obsticles - reliably detecting the
presense of an RFC822 style message bounce attachment and extracting it
for processing, (and being able to handle the case of nesting of attached
messages, or multiple attachments per message in a sensible way) and
coding in a bit of simple logic to decide whether to scan attachments.

Regards,
Simon



Re: interesting paper on SoBig's authorship

Posted by Jeff Chan <je...@surbl.org>.
On Monday, November 1, 2004, 2:57:02 PM, Dan Barker wrote:
> Must be interesting, it's over quota and won't render.

> Dan

It's up on the tripod site Justin mentioned:

  http://authortravis.tripod.com/


> <snip>
> http://www.geocities.com/author_travis/

> veeeeery interesting!

> --j.



Jeff C.
-- 
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/


Re: interesting paper on SoBig's authorship

Posted by Tom Collins <to...@tomlogic.com>.
Mirror of PDF (from Slashdot): http://wetsexygirl.com/WhoWroteSobig.pdf

Seriously.

On Nov 1, 2004, at 2:57 PM, Dan Barker wrote:
> Must be interesting, it's over quota and won't render.
>
> Dan
>
> <snip>
> http://www.geocities.com/author_travis/
>
> veeeeery interesting!
>
> --j.

--
Tom Collins  -  tom@tomlogic.com
QmailAdmin: http://qmailadmin.sf.net/  Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/


RE: interesting paper on SoBig's authorship

Posted by Dan Barker <db...@visioncomm.net>.
Must be interesting, it's over quota and won't render.

Dan

<snip>
http://www.geocities.com/author_travis/

veeeeery interesting!

--j.