Subject: RE: [Asrg] Willfull and intentional misunderstandings

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 6 May 2003 20:23:19 -0400

On Tuesday, May 06, 2003 6:28 PM, Dave Crocker [SMTP:[email-masked]] wrote:
8<...>8
> Proposals to control spam need to worry about reducing it, not making it
> more pristine.

Making 'spam' "more pristine" may be one step toward control.  IDK, is there a 
better more consistent methodology for accurately identifying 'spam' sources 
within the technical framework (at the implementation level) of the MTS?

-e

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 11 May 2003 00:13:37 -0400

>From: Eric Brunner-Williams in Portland Maine <[email-masked]>
>
>Yakov,
>
>Escuse my brevity.

No problem.

> > >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:
>
>There is a taxonomy, most of which I've characterized as "slow", and then
>there is

Do you mean "slow" as spammers who are "losing their skill" and are not 
agile enough? However, there are still plenty of those around and we need 
to stop them just as much as the "fast" spammers.

>... spammers using slave servers.
>
>
> > 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.
>
>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.
>
> > 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 ...
>
>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.

I was looking at the overall spam problem as follows: we have a network - 
the Internet, users - humans using it, and resources - bandwidth, servers, 
computers. The question is how to stop a user from abusing the network 
resources, namely our DLS customer. It does not make a different whether it 
is our DSL user who is actually sending the spam or the hacker that gained 
access to his computer. If we have proper safeguards on place, then we 
prevent both.

> > 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
>
>Hold that thought too. Is a node that transits from "nothingness" to "being"
>indetectible?

As you stated, the most we can do is trace it to the unfortunate DSL user 
whose computer was hacked. The node is detectable but can we do anything 
about it aside from limiting the legitimate user's email?

---------------------------------------------------------------------------------------------------
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)
---------------------------------------------------------------------------------------------------

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 11 May 2003 15:52:30 -0400

>From: Mike Rubel <[email-masked]>
>
>mr>Hmm, perhaps "rate limiter" was too strong a word.  I only meant that RMX
>mr>gives admins the ability to deploy a safety valve, when and where they
>mr>want to.  As a user, I would appreciate such a thing, just as I appreciate
>mr>it when my credit card company double-checks before approving an
>mr>unusually-large purchase.  Nobody's proposing that we start imposing some
>mr>arbitrary limits on people's ability to send legitimate email.
>
>ys> How would such safety valve work? The admin contacts the user, or looks a
>ys> the outbound SMTP traffic?
>
>I was thinking along the lines of contacting the user with a
>message like this:
>
>------------------------------------------------------------------------
>
>     Dear customer,
>
>     We apologize for this intrusion.
>
>     Our systems indicate that your computer attempted to send a large
>     number of emails over the last ten minutes.  Because unusually
>     large volumes of outbound email sometimes indicate the presence of
>     a computer virus, we wanted to check with you before proceeding.
>
>     These and further emails will be placed in a temporary
>     quarantine while we await your instructions.  We respect your
>     privacy, and will not read or otherwise disclose the messages
>     without your permission.
>
>     Please call (800) 123-4567 at your earliest convenience so that
>     we may process your request without further delay.  We appreciate
>     your business and look forward to serving you again in the future.
>
>                        --Your friendly email service providers
>
>     To change your notification settings, please go to:
>     https://www.exampleisp.com/my_account_settings/web_form.php
>
>------------------------------------------------------------------------
>
>A well-designed safety valve might be a feature worth advertising to
>customers; it has perceived value and helps reduce spam.  Think back to
>the credit card analogy again--unusual behavior alerts are billed as
>something of value to the customer, while at the same time reducing losses
>for the company.  Of course, the admins must be careful to avoid imposing,
>hence "large number of emails" and time period will be different for each
>user.  They should be given reasonable default values, and the
>notification limits could even be changed by the users themselves, as
>indicated by the secure web link in the example above.
>
>It is in this sense that I believe RMX (Danisch) and RMX-like proposals
>(Vixie, Fecyk) have the ability to limit the spam effect of poorly-secured
>desktop machines.
>
>Mike

In the same vain, we can also have some tool look at outbound email at 
alert the user with a similar message when too many "spam-like" emails go 
through. Some kind of an outbound spam filter, although I am not aware of 
any in existence.

Yakov