Subject: RE: [Asrg] 2. - Spam Characterization - Possible Measurements (wa s : RE: Two ways to look at spam)

From: Paul Judge <[email-masked]>
Date: Sat, 5 Jul 2003 18:13:28 -0400

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]] 
> Sent: Saturday, July 05, 2003 12:09 PM
> To: Paul Judge
> Cc: 'Barry Shein'; 'Yakov Shafranovich'; [email-masked]'
> Subject: Re: [Asrg] 2. - Spam Characterization - Possible 
> Measurements (was : RE: Two ways to look at spam)
> 
> 
> Paul,
> 
> Permit me to ask a difficult question:
> 
> 
> PJ> Here is a list of characteristics that I'd put together.
> 
> Why?

There are many reasons why one would want to understand characteristics of a
problem as a fundamental step towards attempting to solve that problem. 

> Essentially all of the characteristics that you have listed 
> are no better than second-order. That is, they are not key 
> characteristics to spam, but rather they are characteristics 
> of some spam today.

Spam measurement and characterization should not be confused with the
inventory of problems list. Spam characterization seeks to understand the
current state of the problem (read symptoms). The inventory of problems list
seeks to look at the reason for the problem or the core attributes that
allow the actions taken by spammers that result in these symptoms.
 
> Let's say that a sender of spam changed their operation, so 
> that they committed none of the sins, and showed none of the 
> characteristics, that you listed. Could they still send spam? 
> I believe the answer is yes.

Perhaps some incorrect assumptions were made about why these characteristics
are important. 

Your question above also assumes that spammers can change their operation to
avoid exhibiting ALL of these characteristics. I believe that to not be
accurate. 

Secondly, your question asks if they could still SEND spam. In some cases,
our goal is not to stop them from sending spam, but just to be able to
DETECT the spam. Now, the question should be 'Will we be able to detect
and/or prevent the spam?'

The two questions underneath all of this are: 1) Is this characteristic an
effective indicator of spam? And 2) Can they change the characteristic? 

There are four possible situations, but three that matter:

Question 1: Yes. Question 2: Yes.
Means: Valid indicator now, but not necessarily in the future.
A number of these characteristics provide a good indication of spam
messages. Even though spammers are able to change some of these
characteristics: some of it changes and some of it does not. Either way,
currently they provide effective means of spam detection. Also, realizing
that these characteristics evolve, the good spam detection systems have
also. See any heuristics-based spam detection system for reference. Problems
arise when a system creator mistakenly assumes that one of these
characteristics can not change.

Question 1: Yes. Question 2: No.
Means: Valid indicator now and moving forward:
This provide a good point of focus for new proposals. One quick example of
such a characteristic is the call-for-action. Most (not all) spam messages
include and must continue to include some call-for-action. There are of
course exceptions such as spam sent for the sake of sending and the
possibility of brand awareness spam that does not directly attempt to sell
anything.

Question 1: No.
Means: Not a valid indicator now:
Some of these characteristics do not provide a strong enough indication;
therefore we should not focus on detecting or preventing those. Such a
measurement study could make a strong statement about the usefulness of
certain paths that are being considered.

> Otherwise, all that you are doing is focusing on side-effects.

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Jul 2003 19:13:26 +0200

Paul,

>> are no better than second-order.
PJ> Spam measurement and characterization should not be confused with the
PJ> inventory of problems list. Spam characterization seeks to understand the
PJ> current state of the problem (read symptoms).

To what end?  What will be done with this characterization of "current"
symptoms, especially when we know that spammers are highly adaptable and
will change the symptoms, if they have to?

PJ>  The inventory of problems list
PJ> seeks to look at the reason for the problem or the core attributes that
PJ> allow the actions taken by spammers that result in these symptoms.

As I said, most of the list did not appear to be core.

Any arguments to the contrary -- for each item on the list -- could be
quite insightful.

PJ> Your question above also assumes that spammers can change their operation to
PJ> avoid exhibiting ALL of these characteristics. I believe that to not be
PJ> accurate.

We have already seen considerable examples of adaptive behavior.  For
example, my first use of spammassassin was highly successful, some
months ago.  Now it is almost useless.  (Yes, the ruleset needs to be
updated, but that is exactly my point.)

That's the first time I've seen such an assessment about the limitations
of spammers.

What is it that causes you to believe further adaptation is not likely
or possible?

PJ> Secondly, your question asks if they could still SEND spam. In some cases,
PJ> our goal is not to stop them from sending spam, but just to be able to
PJ> DETECT the spam.

Forgive me for believing that detection of spam should seek to use
criteria that are as persistent as we can make them.

PJ> Now, the question should be 'Will we be able to detect
PJ> and/or prevent the spam?'

The question should be, "Will we be able to develop mechanisms that
detect and/or prevent spam without requiring constant change over short
periods of time."

PJ> The two questions underneath all of this are: 1) Is this characteristic an
PJ> effective indicator of spam? And 2) Can they change the characteristic?

That is essentially what I originally asked, yes.

PJ> There are four possible situations, but three that matter:
PJ> Question 1: Yes. Question 2: Yes.
...
PJ> characteristics: some of it changes and some of it does not. Either way,
PJ> currently they provide effective means of spam detection.

Given that there is a goal of producing standards, at some point, and
that standards take a long time to produce and deploy, perhaps we should
be extremely concerned about focusing on characteristics that have
transient benefit?

PJ> Problems arise when a system creator mistakenly assumes that one of
PJ> these characteristics can not change.

Problems with standards arise when they do not attend to their life
cycle limitations.

PJ> Question 1: Yes. Question 2: No.
PJ> Means: Valid indicator now and moving forward:
PJ> This provide a good point of focus for new proposals.

It occurs to me that the line of analysis you are offering simply means
that we should attend to whether a characteristic is "core" or whether
it is merely a current indicator.

I'd consider that a pretty reasonable re-statement of my original
question, though I am not sure whether that is what you had in mind.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Barry Shein <[email-masked]>
Date: Mon, 7 Jul 2003 19:12:29 -0400

Well, there's one characterization from measurements mentioned which
spammers can't adapt to and that's their location (in)stability in IP
space.

This relates to the idea that the only reason spammers can operate
effectively is because they exploit thousands of hijacked computers
which gives them location mobility (not geographic but in ip space.)

If this can be shown to be true via measurement it leads to the
conclusion that perhaps the problem with spam is not what leads to
this idea of a "consent" framework as originally proposed in this
charter, but, instead, shows spam is almost entirely a security
problem.

Spammers can't adapt their way out of this observation because that
would mean they'd have to become location immobile which means we
could just block them and that'd be the end of spam.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 07 Jul 2003 20:33:21 -0400

Paul,

Perhaps we can start seeing some of the data based on these characteristics?

Yakov

---

From: Madscientist <[email-masked]>
Date: Mon, 07 Jul 2003 20:38:47 -0400

>could just block them and that'd be the end of spam.

If it were only that simple. The good news is that IP stability is a 
powerful tool for establishing senders and their behaviors - not perfect, 
but very, very good. The bad news is that the definition of spam is often 
very different from one RECEIVER to another... so the same IP source may be 
producing spam, or ham depending upon your point of view. Therefore, 
RECEIVER A and RECEIVER B would likely have identical policy definitions 
for the SENDER's identity, but different policy definitions for the 
disposition of the sender.

<RECEIVER>
   <ID VALUE=[email-masked] />
   <SENDER>
     <ID VALUE=01234 />
     <IP-SOURCE VALUE=111.222.123.231 />
   </SENDER>
   ...
   <GRANT-CONSENT>
     <SENDER-ID VALUE=01234 />
   </GRANT-CONSENT>
   ...
</RECEIVER-A>

<RECEIVER>
   <ID VALUE=[email-masked] />
   <SENDER>
     <ID VALUE=01234 / >
     <IP-SOURCE VALUE=111.222.123.231 />
   </SENDER>
   ...
   <DENY-CONSENT>
     <SENDER>
       <ID VALUE=01234 />
     </SENDER>
   </DENY-CONSENT>
   ...
</RECEIVER>

A given RECEIVER may even CONSENT to receive messages from the sender under 
some other conditions... which further complicates the definition process, 
but no without bounds.

_M

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Jul 2003 22:08:46 +0200

Barry,

BS> This relates to the idea that the only reason spammers can operate
BS> effectively is because they exploit thousands of hijacked computers
BS> which gives them location mobility (not geographic but in ip space.)

I think your line of reasoning is aided by a distinction I've taken to
making, between "rogue" spammers -- who are not accountable and for
which direct controls are not feasible -- versus "responsible" spammers
-- who are accountable, but too aggressive.

The path you are discussing pertains to rogue spammers, not responsible
ones.  That does not make it impractical, useless, or the like.  It
merely restricts it to one segment, and not the other.

The other has plenty of legal resources, and always will.  And they are
a serious problem, too.

d/

---

From: Barry Shein <[email-masked]>
Date: Thu, 10 Jul 2003 16:12:23 -0400

> -- who are accountable, but too aggressive.

I agree that's an important and useful distinction.

One advantage we tend to have with non-rogue spammers is that they are
generally easy to block (their IP sources are relatively stable and
they don't tend to hide their identities), although I'd agree that one
shouldn't have to waste their time blocking them out of exasperation,
life should be more orderly.

I recently had an experience with Apple who was sending one of their
mailing lists to all kinds of addresses here which never could have
existed (e.g., domains which never had email service.)

Requests to remove those addresses and generally clean up their act so
that kind of thing doesn't happen went completely ignored, not even
the usual automated response brush-off.

Oh well, not hard to imagine where that's going...Apple's just going
to get itself blacklisted piece by piece.

But my point is that is, thus far, the major annoyance to me from the
non-rogue are otherwise reasonably legitimate businesses that have
obtained mailing lists from questionable sources and/or won't clean up
their mailing lists, ever, so the number of mailings and user unknowns
just grows and grows as addresses age and die.

But why should they clean up their act? It's just more expense to
them, this way Apple et al can shift their costs to the recipient
systems.

That is, until they're just blacklisted entirely.

 > The other has plenty of legal resources, and always will.  And they are

I'll add a third class, and maybe a fourth if you want to split hairs:

Nutballs and sociopaths: These are people (or small groups of people)
who exhibit some of the superficial characteristics of spammers (they
send a lot of unwanted mail by automated means), but their purpose is
either unknowable (nutballs) or malicious (sociopaths.)

The problem with these groups are that many, e.g., economic controls
are likely to be useless with them since they seem to have no
commercial purpose.

Although not the biggest problem I think it's more common than people
imagine.

-- 
        -Barry Shein

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 10 Jul 2003 16:19:01 -0400

This was also the point of my email about the two kinds of spam I have 
seen. The first kind has no email address in the message body (what 
spammer would tell you how to get back at them). The second kind has an 
email address in the body of the message and the domain in the email 
address is to be found in the headers too.

I think Barry and I both missed a third kind as well. There are some 
that actually send you an email with some offer very attractive and an 
email address. Of course the offer is bogus - all they want you to do is 
click a URL on the email page that takes you back to some site. The 
purpose? To verify that you really are there. Is this a rogue spammer or 
not?

Chuck

---

From: Barry Shein <[email-masked]>
Date: Thu, 10 Jul 2003 17:20:08 -0400

On the same topic we've been getting this flood of 1-byte long mail
msgs from apparently hijacked PC's which doesn't seem to have much any
purpose. It's possible it's just a malfunctioning spambot zombie. It
looks like the attached example.

To save the obvious discussion:

   1. It seems to be a dictionary attack, none of those addresses
   actually exist.

   2. The subject varies but generally has that same pattern of
   some barely meaningful phrase, some spaces, and a seemingly
   random string. This is common among spam and has been for years.

   3. It comes from presumably infected broadband hosts.

   4. So what distinguishes it mostly is the one-byte (empty)
   message.

   5. It's possible it's just probing for legit addresses but
   the return address doesn't seem like it'll go anywhere so
   who'll hear the bounce?

	       -b

Queue entry:

RAA29529        1 Thu Jul 10 17:13 <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>
                                   <[email-masked]>

(data file just is a newline)

queue file:

V2
T1057871635
K1057871748
N1
P644
I128/1063/176
MUser unknown
Fb
$rSMTP
$snytimes.com
$_bzq-218-16-158.cablep.bezeqint.net [81.218.16.158]
S<[email-masked]>
C:<[email-masked]>
RPFD:<[email-masked]>
C:<[email-masked]>
RPFD:<[email-masked]>
C:<[email-masked]>
RPFD:<[email-masked]>
C:<[email-masked]>
RPFD:<[email-masked]>
C:<[email-masked]>
RPFD:<[email-masked]>
C:<[email-masked]>
RPFD:<[email-masked]>
H?P?Return-Path: <[email-masked]>
HReceived: from nytimes.com (bzq-218-16-158.cablep.bezeqint.net [81.218.16.158])
	by world.std.com (8.9.3/8.9.3) with SMTP id RAA29529;
	Thu, 10 Jul 2003 17:13:55 -0400 (EDT)
HMessage-ID: <bd7a01c346de$c079263f$8244fc93@12b8bp3>
HFrom: "Jack Davison" <[email-masked]>
HTo: [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked],
        [email-masked]
HSubject: legal action will be taken    n7kmj32oyzc8
HDate: Thu, 10 Jul 2003 12:27:05 +0000
HMIME-Version: 1.0
HX-Priority: 3
HX-MSMail-Priority: Normal
HX-Mailer: Microsoft Outlook Express 6.00.2800.1106
HX-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
HContent-Type: text/html
HContent-Transfer-Encoding: 8bit
.

-- 
        -Barry Shein