Subject: Re: [Asrg] Willfull and intentional misunderstandings

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 09 May 2003 18:00:03 -0400

>From: Eric Brunner-Williams in Portland Maine <[email-masked]>
>
>technical capability:
>
> > ... an actual human being ... or it maybe an automatic software
> > system like <example>.
>
>trace:
> > ... parse the headers and the message ...
>
>shut down:
> > ... ISP shut down their site or email address ...
>
>How can this be useful for the mode Barry described:
>
> > One of the major sources of spam right now seems to be zombie robot
> > hosts, hosts who have had a virus injected into them which turns them
> > into unwitting spam slaves*.
> >
> > So the spam is being delivered by 123-456-789-123-dsl-pool.telco.com
> > and guess what it seems to be from 
> [email-masked]
> > who assures you that anything from (don't make me type it again)
> > is indeed from (I'm just not going to type it again.)
> >
> > Now what do you know?
>
>I'm still where Berry left off. I don't see anything in humans, or pseudo
>humans, headers and eventual administrative DoS that solves for "virally
>acquired spam slave servers".

Lets analyze where spam comes from. From experience I have seen the 
following sources:
1. Legitimate companies and real domains.
2. Companies that do not know any better and just use some mass mail 
software and a CD of thousands of addresses. This appears as something 
coming from
3. Professional spammers using ISPs that don't care
4. Professional spammers using open relays.
5. Professional spammers using private domains.
6. Professional spammers using slave servers.

Cases 1, 2, 3 and 4 all of these can be traced and dealt with. But that 
doesn't matter much from today and whether spoofing is present in the 
system or not, it will not make a difference. At some point the originating 
IP address will appear in the "Received:" headers and thats it. As for 
cases 5 and 6 spoofing is meaningless since tracing the originator will not 
make a difference anyway since in case #5 the whois information is false 
anyway and in case #6 as you said, there is nothing that can be done post 
facto. Perhaps, fixing spoofing can help us take care of the first four 
cases since automated tools can easier determine the origins of the spam. 
For spammers using private domains or slave servers, it will not help.

Based on this,  I will have to agree with you that spoofing or solving 
spoofing will not solve the spam problem. It seems that we have to look at 
the spam problem as a subset of a larger problem of how to prevent a 
network user from abusing the network resources, in this cases being the 
bandwidth. The underlying reason why spam is being sent is because it is 
very easy and cheap for any network user to utilize the network resources. 
Thus the solution is to make it expensive or restrict the user, but this is 
plagued with problems.

Additionally the question of slave servers poses a tremendous problem not 
just in regard to this issue, but in regard to all anti-spam solutions. In 
theory if a computer has been taken over, what prevents the trojan/virus 
from doing the following:
1. Emailing other users on the Internet directly.
2. Monitoring local SMTP traffic and finding out what SMTP server is used 
by the user. Then using that SMTP server for sending spam. RMX/rDNS will 
not help here since the email will come from a permitted IP range. SSL/TLS 
will not help since the trojan can capture the password used.
3. Perfoming tracert from the infected computer to some other site and 
trying to figure out the MTA for that domain for each domain listed in the 
trace route, possibly even via RMX/rDNS or some other proposal, and then 
using that MTA for spam.
4. Sending spam via [insert your method].

The only thing that will help in these instances is either putting a 
sending limit on the user, or using some kind of a secure operating system 
which (in theory) makes it impossible to monitor local SMTP traffic. No 
trojans to my knowledge have ever done this, but then again there has not 
been an incentive. They will adapt just like we will, and the spam problem 
might never go away.

>[2] http://www.unc.edu/depts/jomc/academics/dri/idog.html

Thanks for the link!

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------  

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

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 09 May 2003 18:45:58 -0400

Yakov,

Escuse my brevity.

> Lets analyze where spam comes from. From experience I have seen the 

There is a taxonomy, most of which I've characterized as "slow", and then
there is

... spammers using slave servers.

> bandwidth.

Hold that thought. It's not unqualified bandwidth. Not only is it SMTP,
but it has some immediacy property that is distinct from say, 3rd-party
persistent cookies and their replay times to namespaces dynamically
managed by technically capable advertizing networks, and it must possess
some additional properties.

> Thus the solution is to make it expensive or restrict the user ...

Hold that thought too. There is no user. His or her wintel box on a cdn
or dsl circuit is _yours_. You simply need to match your acquisition and
loss budgets, while working your delivery problem.

> which (in theory) makes it impossible to monitor local SMTP traffic. No 

Hold that thought too. Is a node that transits from "nothingness" to "being"
indetectible? 

> >[2] http://www.unc.edu/depts/jomc/academics/dri/idog.html

You're welcome.

Eric

---

From: Mike Rubel <[email-masked]>
Date: Sat, 10 May 2003 00:52:09 -0700 (PDT)

> will not help since the trojan can capture the password used.

Hi Yakov!

I believe RMX and other RMX-like proposals will help in the slave server
case.  The spammer can still use the slave to send spam, but if he wants
to send it using slave owner's identity, the messages must go out thru the
real outbound mail servers listed in the RMX records or they will be
rejected as forgeries.

Assume the outbound mail servers are well-secured relative to the slaves
(which are probably just desktop machines on home cable modems).  The mail
server admins can use rate-limiters which detect attempts by a user to
send a lot of messages at once and react appropriately.

If the server admins are not careful and have not installed rate-limiters,
then the spam gets through and the domain loses trust (by which I mean
Bayesian spam filters become more likely to reject MAIL FROM: it).  So the
admins have an incentive to be careful and install the limiters.

Mike