Subject: Re: [Asrg] How to defeat spam that uses encryption?

From: mathew <[email-masked]>
Date: Tue, 1 Apr 2003 09:14:00 -0500

On Monday, Mar 31, 2003, at 22:41 US/Eastern, Art Pollard wrote:
> Anyway, what they do is misspell words.  They use < and > to make 
> "se><"
> for example, 1's for l's 0's (zeros) for o's, etc.  It is of course 
> harder to read but the message is still quite understandable.  What is 
> more, it makes it virtually impossible for a filtering mechanism to 
> catch it unless the various tricks such as this were programmed into 
> it directly.

On the contrary, Bayesian spam filtering will learn that in no time. 
It'll notice that 100% of messages that contain "se><" or "v1agra" are 
spam. It's actually far easier to filter for that; as someone's pointed 
out already, use of attempts to get around spam filtering is a very 
good indicator of spamminess.

mathew

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 1 Apr 2003 07:21:53 -0800

> At 9:55 AM -0700 3/31/03, Vernon Schryver wrote:
> >easier to evade filters.  I've never built a filter that wouldn't be
> >easier to evade than to operate.  Spammers are always slow 
> and behind.
> >Why?
> 
> Because until recently so few people ran filters that it wasn't worth 
> the effort to work around them?

Transfer of information is much slower in the spam sender world
because the information on how to get arround filters is considered
a trade secret.

This is not like hacking where the script kiddies sit out in chat 
rooms boasting about how kewl they are and swapping their knowledge
of the latest crack.

Another reason is that the CDROMs with software used by list kiddies
tend to be pressed once and never updated.

	Phill

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 1 Apr 2003 11:09:17 -0500

At 12:59 PM -0700 3/31/03, Vernon Schryver wrote:
>No, that is wrong.  A filter can decode the SMTP body exactly as it
>will be decoded by the MUA.  If the MUA can decode the message enough

This turns out to be non-trivial when dealing with Microsoft 
software.  Microsoft has a habit of trying to "correct" for mistakes 
in the sending software.  And spammers take advantage of that fact. 
(Personally I think that correcting for mistakes is great when you 
talk about the user on your machine, and really stupid when you are 
talking about remote software. )

On the bright side, a spam filter doesn't need to decode most of 
those--it just needs to look for someone trying to take advantage of 
them... so long as there isn't legitimate mail out there using the 
same technique (intentionally or not).
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 31 Mar 2003 21:22:30 -0500

Vernon Schryver wrote:

> You must
> decode QP and Base64 before computing hashes, because there are MTAs
> that add and remove at least QP and I think sometimes Base64 encoding.

As a FYI, our sendmails are B64 encoding messages that have "too much" 8 
bit gunk.

Annoying.  Fortunately, our filters are ahead of that.

I do wish, however, that our _filters_ decoded what stuff is already 
encoded.

Maybe next deployment.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Apr 2003 08:42:19 -0800

> As a FYI, our sendmails are B64 encoding messages that have 

It sounds to me as if we could do with some sort of command
to say 'don't mangle I can handle 8-bit clean' in the
SMTP transfer.

SMTP almost certainly has one already, we really need a BCP 
to say observe it. The corruption of messages caused by
faulty MTAs that don't understand end to end is a major 
problem.

	Phill