Subject: RE: draft-danisch-dns-rr-smtp-02.txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 4 Jun 2003 16:03:12 -0700

> What would they set them to? The customers could use any ISP, 
> anywhere.

Not if they are going to use RMX... But that is only an option.

> Certificate based scheme? I must have missed that.

RMX is only the starting point, not the destination.

> The cost of altering the worlds DNS servers is usually 
> considered high.
> THe leverage seems to be non-existant.

This one change adopted by the right 10 ISPs allows something like 25% of
spam to be eliminated between those ISPs (until the spam senders react).

> The Code of conduct was not written to reduce spam.

Why do you think a code of conduct is going to work if it does not provide
an answer to the problems the ISPs legitimately face?

> He didn't have to write about spam. He wrote about 
> communications. 

I have read the paper several times, it does not have the implication you
think it does. Spam is not a covert channel, it is an overt channel.

> This is nothing other than a blacklist scheme.

No, the critical failure of blacklist schemes is that there is no
accountability for the blacklist to any party whatsoever. The people who
demand accountability from others, loudly and with threats refuse to accept
accountability or responsibility themselves.

> > That is not my fault or the fault of Hadmut. It is secure enough to
> > allow a meaningful level of control.
> 
> This has been disproven.  Spoofing UDP DNS replies is 
> significantly easier
> than spoofing TCP connections.

It is pretty easy to detect a DNS spoofing attempt if you are looking for
it. You can then switch to TCP/IP. 

> I would rather not have gratuitous change.

Then propose a better solution or convince people the problem is not
important.

Lack of progress or consensus in this forum is not going to affect
deployment of these ideas.

> It seemed to me at the MIT anti-spam conference that ISPs 
> were working on
> content analysis methods, and agreed that blacklists were not going to
> play a large role in the future.  At the end of the message, 
> as it were, the spammer has to talk about selling something.

Paul Graham's conference held on the MIT campus but not accredited or in any
way endorsed by MIT was about solving spam with content filtering using
Bayesian inference. Papers that proposed other approaches were all rejected
so the lack of other proposals is not indicative of ISP intentions.

> In interesting comment at the conference was from the MSN speaker, who
> indicated that their content filtering was such that MSN approved spam
> mail was being blocked.

At the FTC conference Ryan Hamlin, the general manager of Microsoft's
anti-spam initiatives specifically mentioned RMX by name and use of Reverse
DNS as indicative of the type of proposal they are considering with Yahoo
and AOL.

		Phill 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Thu, 05 Jun 2003 12:04:30 +1000

I doubt if the DNS is the right place to store this data.
	There is a high probability that the number of acceptable
	sources will exceed the DNS's ability to transmit.

	I suspect the correct way to handle this is to have the
	servers that are located via SRV records validate whether
	a given address and/or name is a valid source for this
	particular email address.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Wed, 4 Jun 2003 23:13:07 -0400 (EDT)

inline

> RMX is only the starting point, not the destination.

We can't go off in wild directions. We need to know that we will get a
return on the investment.  Spam isn't a big problem. Its an annoying
problem. It unclear what the breakdown in terms of Type 1, Type 2, and
Type 3 spam is. Type 3 spam is already, generally, a federal felony, with
a 5 year jail term, because it is illegal to break into a computer with a
virus or by other means.

> spam to be eliminated between those ISPs (until the spam senders react).

So, we spend a lot of money, time, and sweat, and get 10 minutes of
reduced spam?  This doesn't seem worth it.

One thought I had some time ago was filtering based on non-routeable,
non-RFC1918 addresses in headers.  I noticed that when headers are forged,
the abusers tends to just pick random numbers. Some percentage of those
are not routeable, and probably _weren't routed, thus making an easy
indicator of a forged header. Of course, spammers would just adjust to
picking routable numbers. The effort isn't worthwhile.

But a lot of spam issn't using forged headers (ie Recieved). I recently
went in search of a spam with forged headers (I save all my spam). I had
to go through 6 messages to find one with forged headers. The most popular
method has been use of open proxies, with no header forgery whatsoever
(other than forged from:  and such).   Type 1 and Type 2 spammers include
the contact information in the message. they have no need of forged
headers, or could trivially avoid it by using a domain that doesn't
receive email, if they don't want to get email responses.

Type 3 abusers aren't interested in anything besides annoyance. When they
crack a computer, or infect a computer with a virus, they steal the
legitimate users email identity. Header authentication doesn't stop this
kind of abuse.

> an answer to the problems the ISPs legitimately face?

Most ISPs don't "legitimately" face these problems.  See the description
of Type 3 abusers I posted earlier.

> think it does. Spam is not a covert channel, it is an overt channel.

It is a covert channel since the user isn't supposed to send it. In a
classified environment, they are not supposed to send the classified
documents, but manages to do so anyway via covert channels. The only real
difference is the lack of military classification on the document.  But
the difference isn't significant. You can't create a spam-free protocol.
If you could, I (and many others) would like to see it. It would be *real*
useful to those that have classified documents.

Nor does a covert channel require cooperation. The recent SSL timing
exploits demonstrated that side channels are also covert channels. You
can't prove a protocol doesn't have covert channels. You have to discover
them, and react to them.  This means that you always have to detect and
respond to spam.

Altering protocols is a waste of time.  A spammer can't be stopped until
their ISP stops them. ISPs are never going to give authority to terminate
accounts to people who aren't under its control.  Blacklists are simply
attempts to take control of an ISP's email.  It won't happen, for a
variety of technical and legal reasons (anti-trust). But mainly, it won't
happen because neither users nor ISPs (in general) want it to happen.

But of course, Type 3 abusers are mostly unconvicted felons. That doesn't
require voluntary cooperation from anyone. It just requires Law
Enforcement to get interested in tracking these people down. This is
already an easy task for Law Enforcement.

> accountability or responsibility themselves.

I agree that this is a critical failure, but I would add that it isn't the
only critical failure. Another problem with blacklists is that they
require too much human maintenance.  Abusers running large numbers of
virus-infected machines (Type 3 abusers) can easily outmanuever a
blacklist, while simultaneously causing a lot of collateral damage
(directly and indirectly through the blacklist). Collateral damage is the
goal of a Type 3 abuser.

> it. You can then switch to TCP/IP.

In a low volume lab environment, it is easy. In a high volume environment,
it is not.  It requires keeping counts of packets and request ids and
client addresses.

> Then propose a better solution or convince people the problem is not

The third alternative is to convince people not to make gratuitous changes
that won't solve the problem.

> deployment of these ideas.

Perhaps reason and non-standardization will affect them.

> so the lack of other proposals is not indicative of ISP intentions.

Bayesian was a big topic, but not the only topic.

You can read the abstracts at http://www.spamconference.org/abstracts.txt

You can also (I think) download the video.

Proceedings of the 2003 Spam Conference

     Teodor Zlatanov
        Gnus vs. Spam
     Bill Yerazunis
        Sparse Binary Polynomial Hash Message Filtering and The CRM114
                              Discriminator
     Jason Rennie
       Automatic Feature Induction for Text Classification
     John Graham-Cumming
       The Spammers' Compendium
     Paul Judge
       Spam Research: Establishing a Foundation and Moving Forward
     Paul Graham
       Better Bayesian Filtering
     Matt Sergeant
       Internet Level Spam Detection and SpamAssassin 2.50
     Joshua Goodman,
       Spam Filtering: From the Lab to the Real World
     Michael Salib
       Heuristics in the Blender
     David Lewis,
       (Spam vs.) Forty Years of Machine Learning for Text Classification
     Jon Praed,
       A Spam Litigator's View from the Front Lines
     Ken Schneider
       Fighting Spam in Real Time
     Brian Burton
       Bayesian Spam Filtering

> DNS as indicative of the type of proposal they are considering with Yahoo

Reverse DNS???  That doesn't sound much like the MSN presentation

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 05 Jun 2003 01:19:49 -0500

The cost-v-benefit for this RR will vary. Forged mail domains is a point
on the spam continuum, but it's also on the security continuum, the worm
continuum, and even the legal continuum such as idiots promising giveaways
for contests I'm not having. Frankly I don't even care whether this knocks
down any spam at all, I just want control over who gets to use my domain
name, regardless of their motives. If spammers move to some other domain
and keep spamming, then that's actually a victory in my book.

This approach gives all domain owners that same offer of protection,
assuming their network topology allows them to use it. For me it would be
easy since I always send mail through my own mail server no matter where
I'm at. For other folks it will mean using dynamic DNS or scripts to
append RRs pointing to wherever they happen to be. Other organizations
will have other problems, but none of that makes it unusable for the folks
who can use it.

Trying to block its development because some people can't use it isn't
really justified unless it harms the network. It could certainly be
improved (please limit the RR data to a single entry) but near as I can
tell it isn't a threat to global DNS stability since it is limited to
voluntary domains, and nodes have to request that specific RR for those
specific domains, and given the kinds of sites that will check this then
most of those lookups are likely to happen after the query path has
already been cached from other checks anyway, none of which we have any
control over.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/