Subject: Re: Apology Re: Principles of Spam-abatement

From: "Dr. Jeffrey Race" <[email-masked]>
Date: Tue, 16 Mar 2004 09:47:51 +0700

On Mon, 15 Mar 2004 18:12:22 -0800, Ed Gerck wrote:
>BTW, how can we talk about "actions that have consequences" in terms of a 
>technical solution that the IETF can pursue?

The whole point is there are NO TECHNICAL SOLUTIONS and never will be.
(There are some technical aspects to improving traceability, however.)

IETF would not apply the consequences; the victims would apply the
(behavioral) consequences using  established guidelines, employing
technical measures already established in RFCs.

IETF and other standards bodies can bless agreed procedures for using
the existing technical steps in new behavioral ways.

There are two reasons this is crucial:

1) Courts often, perhaps usually, defer to declared norms of industry
   standards bodies, in establishing reasonableness of disputed 
   behavior.   We can be decisive in establishing these norms.  The
   courts can't easily act to use the COMPLETELY ADEQUATE EXISTING
   LAWS in part because of this lacuna.

2) Normative documents, and personal leadership, convert a group or a 
   mob into an "emergent structure" (say a business firm, a dance
   company, a charitable organization, a military unit, a religious
   order, a teen gang) in which the norms absolutely bind the behavior 
   of the participants, even to death.

I say, in a completely non-deprecating way, that these points from law
and sociology may not be apparent to engineers (or in fact to anyone else
who is not an attorney or a sociologist) but they are completely true
and completely binding on human behavior.

>The consequences are not 
>technical. In addition, they would need to be arbitrated and we know how 
>long, ineffective and expensive that can be.

No arbitration needed.  Please re-read the proposal.

My proposal (which received input from many people) is basically just
common sense.   That's what we need now.   The answers are in.  The
proof is in.  Let's do it.  Now.

Jeffrey Race

---

From: Ed Gerck <[email-masked]>
Date: Mon, 15 Mar 2004 19:44:05 -0800

> (There are some technical aspects to improving traceability, however.)

Actually, as discussed in another thread, there IS a technical solution for
spam. The technical solution is based on strongly reducing the *possibility* 
of undesired actions (spam) to exist. You don't have to talk about consequences 
if you deny the very conditions that allow the undesired action (spam) to exist. 
Yeah, of course,  there will still be the occasional message from a stranger 
that is not what it purports to be. But, at least, MTAs and MUAs would not 
greet that stranger and their MTA with open doors. The needed Internet 
paradigm, to do this, is "trust no one." 

As any parent knows, it is a lot better to make the undesired action unlikely 
than to enforce consequences for the undesired but likely action.

> IETF would not apply the consequences; 

One more reason for the IETF to stay away from mandatory retaliation (aka
consequences).

>  the victims would apply the

The victims are the least qualified parties to apply the retaliation you
suggest. This principle is well-established in history and legal systems 
worldwide. That's why we have attorneys, court system, judges, jury, 
appeals, etc.

>    LAWS in part because of this lacuna.

Are you a lawyer? It turns out that we the majority of the legal opinion 
is that, at least in those countries with common law such as the U.S., 
much of the legislation already in place for paper records and paper 
transactions also applies to electronic records. For example, when Telex 
was introduced,  UK court decisions rejecting attempts to repudiate Telex
contracts were based on jurisprudence and laws for contracts made using 
paper. Telegrams with their electronic dih-dhas were also used (and are 
used until today!) under the rule of legal evidence.

>    of the participants, even to death.

"to death" seems a bit extreme, but I agree spam is a problem.

> and completely binding on human behavior.

Nothing is 'completely true' or 'completely binding' in law or sociology. 
They are not exact sciences. This is not Pithagoras' formula. While I 
appreciate your efforts to be emphatic, infallibility is often denied by 
facts even in engineering ;-)

> No arbitration needed.  Please re-read the proposal.

I did, some time ago. Hence my comment. No arbitration means liability.
Who wants it, in business?

> proof is in.  Let's do it.  Now.

I am sure you know that common sense is not that common ;-)

That's why I believe there must be great caution and moderation in 
all of this. 

Cheers,
Ed Gerck

---

From: Dean Anderson <[email-masked]>
Date: Tue, 16 Mar 2004 11:11:22 -0500 (EST)

> The whole point is there are NO TECHNICAL SOLUTIONS and never will be.

Correct, and I gave an explanation for this in inforamtion theory.

> (There are some technical aspects to improving traceability, however.)

The traceability is about as good as it will get.  If you have an IP
address and a time, that is all you need, and like a phone number, all you
might hope to get.  While an open proxy can hide the true IP of the
abuser, you still get the IP of the open proxy.  Likewise, if the dialup
account is stolen, you may get the IP address assigned to users of the
dialup gateway, which also isn't the culprit.

Even cryptographic methods start by having ISP's issues certificates. The 
certificates, like other accounts might be thought of as disposable. Or 
they might be stolen.  

Authentication is not a solution to spam.  

As you might recall, after the east coast power outage, it was suspected 
that the outage might have been related to a virus.  While it turned out 
not to be, it didn't take long for the virus author to be tracked down by 
law enforcement. There is nothing wrong with the current traceability.

What anti-spammers want is to have access to private information. This
will not happen without proper legal procedures. CAN-SPAM explicitly
permits information to be obtained by subpoena, but basically, this was
all obtainable before, as AOL and many others have demonstrated.

>    LAWS in part because of this lacuna.

Example?

Given that you seem to think open relays are bad (from you proposal), and
since the only time I've ever heard such a claim involved open relays, I'm
guessing that's what you mean.

Having litigated the issue--it was so frivolous that it didn't get to a
filing but there were lawyers involved, I can report to you that the
reasonableness of running open relays in particular has nothing to do with
technical standards.  The central issue is that there a genuine reasons to
provide unauthenticated or post-authenticated relay services outside one's
assigned IP address space, and secondly, the claims that open relays are
somehow associated with spam or provide some benefit to spammers doesn't
hold up to legal scrutiny.  Open relays are not the same as anonymous
relays.  Open relay use doesn't in any way impede investigation of spam.  
Nor does open relay use impede spam blocking.

There are two types of people who speak against open relays:  The first
type are misled. They have very little idea of what an open relay is or
why they would be used. They've just been told that open relays are bad,
and have come to believe this fervently themselves.  It is an article of
faith, and not of logic.  The second type abuses them.  Genuine spammers
of the sort that would be subject to the CAN-SPAM act do not abuse open
relays.  Only radical anti-spammers search for, and abuse open relays.

> proof is in.  Let's do it.  Now.

Actually, common sense would be that anytime you interfere with someone's
rights, there will be legal procedures involved.  But this is another
weakness in the cherished assumptions of the radical anti-spammers. They
seem to think that they are the only people with rights.

---

From: Ed Gerck <[email-masked]>
Date: Tue, 16 Mar 2004 13:40:12 -0800

> Correct, and I gave an explanation for this in inforamtion theory.

What information theory says is that the probability of detecting
spam is less than 100%. This has nothing to do with what or what not
the IETF can do to prevent spam. This result is useful only for 
an end-user, to feel good about his spam filter not being 100% 
effective. This is a user result, not an IETF goal.

What interests the IETF are technical spam solutions, for example, 
that would prevent email that comes from unidentifiable or rogue 
senders/MTAs to be ever received. Not because spam is detected as 
such but because untrusted, unidentifiable or rogue senders/MTAs 
are detected. Yeah, this would still leave room for trusted and 
identifiable senders/MTAs to send spam messages. But such spammers 
are no longer a hidden target. And it would be a lot harder for 
someone to send spam on behalf of you.

These are examples of feasible technical, IETF-relevant solutions to 
spam, not at all denied by information theory. To implement these 
solutions, we need an Internet design where we recognize that the 
end points have become much less trusted than the connection. This 
is the opposite of what the DARPA Internet assumed and was designed 
for. So, some things gotta change.

For example, saying that you're "[email-masked]" should not be so 
easy to do when you're sending email, even though it should still 
be easy to set "[email-masked]" as your address in your MUA. 

Cheers,
Ed Gerck

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Mar 2004 15:11:43 -0700

>someone to send spam on behalf of you.
Yes!
I agree that the IETF can not stop spam. A very reasonable goal would be
to stop or make very unlikely, or difficult to send forged spam. Or at least
make it detectable early in the process of accepting email and hang up
on the spammer.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

---

From: Dean Anderson <[email-masked]>
Date: Tue, 16 Mar 2004 17:45:45 -0500 (EST)

On Tue, 16 Mar 2004, Ed Gerck wrote:

> spam is less than 100%. 

No, information theory doesn't say that at all.  Indeed, the probably of
detecting spam is probably very close to 100%

> This has nothing to do with what or what not the IETF can do to prevent
> spam.

No, it is quite useful: The IETF can do nothing to prevent spam.

> senders/MTAs to be ever received. 

The only thing that can acheive this is to turn off the computer.  

> Not because spam is detected as such but because untrusted,
> unidentifiable or rogue senders/MTAs are detected. Yeah, this would
> still leave room for trusted and identifiable senders/MTAs to send spam
> messages. But such spammers are no longer a hidden target. And it would
> be a lot harder for someone to send spam on behalf of you.
> 
> spam, not at all denied by information theory. 

The IETF can specify protocols with certain features, say PKI, but doing 
so will not prevent spam, since the IETF (nor anyone else) cannot specify 
a 'spam-free' protocol.  This is a result of information theory.

> To implement these solutions, we need an Internet design where we
> recognize that the end points have become much less trusted than the
> connection. This is the opposite of what the DARPA Internet assumed and
> was designed for. So, some things gotta change.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 16 Mar 2004 18:20:22 -0500 (EST)

> was designed for. So, some things gotta change.

I was going to say something before about this. In the original design,
only _some_ ports were to be more trusted, those below 1024. Back in the
mainframe day, the mainframe itself was clearly more trusted.  But it was
still the case that users could open untrusted ports, so the entire
machine was not trusted, and all endpoints were not assumed to be trusted.

And contrary to belief, we had spam (or abuse) back before
commercialization, too.  I remember starting a "network software engineer"
job in 1991 that included system administration at Kendall Square Research
(KSR). KSR was a supercomputer company, and employed some very smart
people.  Never-the-less, in my first week, I got to meet one bright young
VLSI engineer who had a cron job running that sent an email every 5
minutes saying "you're a jerk" to someone he had gotten into a flamewar on
some usenet news group. (We had a uucp 9600baud leased line, and were
waiting on a 56K to Nearnet)  That was a fun way to meet new people.  
"Hi, I'm the new guy in Swee's group. By the way, that special cron job
you have going, Knock it off."

> be easy to set "[email-masked]" as your address in your MUA. 

The From: address is just dressing. It makes no difference what its actual
value is, nor that it can or can't receive email.  As was pointed out,
many things only send email, and don't receive it. Those things will have
informative (or not) from addresses that are invalid for reception.

		--Dean

---

From: Ed Gerck <[email-masked]>
Date: Tue, 16 Mar 2004 17:09:09 -0800

> informative (or not) from addresses that are invalid for reception.

Things that send email but don't receive them can nonetheless
have a valid email entry for 'no mail accepted', with no mailbox.
In terms of trust as I defined before here [1], an email address 
for those things (or any other things) should have a *minimum* 
of three values:

+ 	trusted according to policy(+)
0 	trust value not assigned
- 	distrusted according to policy(-)

Of course, the positive and negative range can be expanded
in values as well. How to assign these values? How the trust
model works? Let me copy from an earlier discussion elsewhere.

 This is the wrong question to ask. The real answer is, "what trust 
 model would you like?" There is a built-in notion (given by the
 abstract trust definition in [1]) of the meta-rules that a trust 
 model has to follow, but I might buy a trust model from someone 
 and add that, design my own, or even augment one I bought. Thus, 
 I can ask for a fingerprint and check it against the FBI, Scotland
 Yard, and Surite databases, check their PGP key to make sure that 
 it was signed my Mother Theresa, ask for a letter of recommendation 
 from either the Pope or the Dalai Lama (except during Ramadan, when 
 only approval by an Iman will do), and then reject them out of 
 hand if I haven't had my second cup of coffee. 

 As flippant as I'm being, this has a lot of value. I write with a GUI
 framework because I don't have to worry my pretty little head about the
 details of how to draw a checkbox. I ask the system to draw it for me, and
 it does. It even handles what happens when it's clicked. I just ask the
 checkbox if it's on or off, and it tells me. If I want a special checkbox,
 I can make one of those as a subclass, and once I've done that work, I
 don't have to think about it again, I just use it. Similarly, if I use
 such a concept of trust, I may have to do some up front work to get 
 things the way I want but I can always use an off-the-shelf validity 
 mechanism. In either case, I just ask the trust framework if the 
 trust assertion is valid. The framework can combine rules of thumb 
 with special-cases as appropriate, and without my having to worry my 
 pretty little head about it.

Trust on the sender cannot be proven by the sender (self-assertions cannot 
induce trust -- e.g., "trust me" doesn't work), but must be calculated using 
sources independent of the sender. The sender may hint to a specific trust 
service used, and even provide it and its values, but we should be able to get 
that information from the service directly and/or chose our own trust services
independently. In doing so, trust on the sender is what the receiver 
determines at a specific time based on a behavior model for the sender.
If the sender cooperates, the process can be faster and easier. But the
sender cannot determine the process.

The problem is, thus, not how do you determine trust, especially with all 
the different definitions of spam possible, but how do you want to do it.

Cheers,
Ed Gerck

[1] http://nma.com/mcg-mirror/trustdef.htm

---

From: Ed Gerck <[email-masked]>
Date: Tue, 16 Mar 2004 18:48:08 -0800

Dean Anderson wrote:
> No, information theory doesn't say that at all. 

Sure it says, and that's why a spam filter will never be 100%
effective. I guess we agreed on this before ;-) We also agreed
that spam filters are a user matter, not IETF matter.

Now, you may want to refer to that mythical element, the 'spam-free' 
protocol, a protocol that an information theory model says cannot 
be built. I guess we also agreed before that a 'spam-free' protocol 
is impossible. The IETF should not attempt to develop it.

Thus, in asking for IETF technical solutions for spam, it is
obvious that I do not mean spam filters or 'spam-free' protocols.  
We would all be very happy with a protocol that is almost 
spam-free -- in fact, I believe we would be quite happy with 90% 
at this time. Me thinks we don't need 100% ;-)

An IETF technical solution to reduce spam is doable. Your comment
on 'spam-free' is useful-free ;-)

> No, it is quite useful: The IETF can do nothing to prevent spam.

;-) this mantra is becoming a spam.
 
> The only thing that can acheive this is to turn off the computer.

No, it's a matter of degree. Even if not all spam is preventable,
preventing email address spoofing (even to a degree) would have
a range of benefits. For example, I would no longer receive
those "undelivered" messages for email that I purportedly sent,
but actually never did. And people receiving email from me could 
actually trust to some extent the outcome of their filters. And, 
to be clear, I'm not talking about PKI. 

> a 'spam-free' protocol.  This is a result of information theory.

Because it can't be perfect, it can't be done? No one needs perfection.
All we need is to have a degree of spam-freeness that is acceptable.

Sterilized milk is not bacteria-free, it just has a reduced count
of bacteria -- which count is low enough to guarantee its stated
shelf life.

Cheers,
Ed Gerck, who doesn't believe in rejecting every possible spam bit.

---

From: "Robert G. Brown" <[email-masked]>
Date: Wed, 17 Mar 2004 00:44:58 -0500 (EST)

> the different definitions of spam possible, but how do you want to do it.

I wrote one whole response earlier but deleted it (fortunately, as Dean
went through my points far more tersely than I was about to).  Here I
just can't stand it.

Ed, are you not paying attention?

It is fundamentally, intrinsically, eternally IMPOSSIBLE TO IDENTIFY
INDIVIDUAL HUMANS on the internet.  I can sit at my laptop and create a
hundred entirely real accounts with no humans behind them, with real
humans behind them, with me behind them, with alien invaders who will
eat your head behind them.  From the other side of my network connection
YOU CANNOT TELL which of these are real and which are fake.  You will
never be able to tell without violating so many of my civil liberties
that I (and everybody else on the planet) would be out in the streets
rioting to get them back.

Mail sent out by my perfectly functional MTA (any of them that I might
choose to install or one that I might custom-write to serve a particular
purpose) is for all practical trust-based purposes ANONYMOUS.  Mail has
always been designed to be anonymous (paper mail too).  There are
individually authenticated services and there are anonymous services,
and mail transport is an anonymous service because it crosses
authentication boundaries.

Mail (paper or otherwise) has an envelope, sure, but the only thing on
it that you can trust even a little bit is the set of postmarks it
develops along its route to your mailbox (and even here, you can really
only trust the LAST postmark in the chain, the one one hop upstream).
Your MTA cannot fill in the envelope.  That can only be done by my (the
sender's) MTA unless you've developed that psychic mail transport
mechanism.

This is no different from paper mail.  YOU have to fill in the address
information on a paper envelope.  You control the pen as surely as you
control your sending MTA -- every byte or stroke can be truth or lie.
You can lie about your return address.  You can fill the envelope with
ricin and anthrax or with money and praise (I'd prefer the latter,
naturally).  I cannot tell if the envelope tells the truth before
opening and reading the message.  I cannot even tell with CERTAINTY that
the envelope tells the truth AFTER opening it except by an out of band
communication with the sender.

If you want to argue that all mail has to be sent the electronic
equivalent of "certified mail" in the paper world, forget it and think
through the metaphor.  First of all nobody EVER sends certified mail in
the paper world except when money is on the line because a) it COSTS
money to have it certified; and b) it is a pain in the ass to have it
certified (it costs time).  Finally, even in the paper world, "certified
mail" generally means that you send it TO a positively identified
receiver with a guarantee that they will receive it.  You are generally
NOT required to show some sort of id proving that the return address is
valid and that you are the person corresponding to the return address
and indemnity information.  Maybe you are.  Maybe you aren't.  Maybe
you're just a messenger boy.  Maybe you're sending well-certified
anthrax and lie about everything on the return/sender forms you fill
out.  In any event, you likely own, literally, the certifying machine
(the sender).

Spam and paper mail abuse is not a problem that can be solved by
addressing trust of identities.  It is fundamentally a problem WITH real
identification.  In the HUMAN world, it is remarkably difficult, and
remarkably uncommon, to validate that a human is who they say they are;
most glib examples that have been cited to show that it can easily be
done show the opposite -- that it is NOT easy and it IS expensive and a
PITA.  My kids have to bring birth certificates and photo id's to
certain things (SAT tests, school registrations).  These
documents/tokens are not easy to file, to find, to to keep straight and
available and are easily lost or stolen.  

I have to show certain forms of legally certified id in order to
validate certain transactions, mostly involving money, and I have to
jealously guard them as they are easily lost or stolen.  Rituals
involving them (such as getting a loan or cashing a check) are time
consuming and inconvenient.

As a general rule we do NOT walk into a party and strike up a
conversation with somebody and say "Hi, I'm Rob, here's my driver's
license, a couple of credit cards, my Duke ID, and do you need to see my
birth certificate or passport or will you talk to me know?"

All of which can be and are forged, by the way...

To extend the analogy to the Internet, make the party a masked ball,
many of whom are strangers.  I might wear a different costume every time
we meet and all you know of me is -- my card, presented at the door and
impeccably printed on the very best paper, that contains one valid piece
of information, the house from which I LAST came to arrive at the party.

In the human world, there is a degree of legal constraint that limits
forgery, and a degree of legal REstraint that protects privacy.

On the Internet, there are no laws preventing me from creating a new
"identity" for each and every transaction.  I could send one message to
this list as rgb, the next as brg, the next as hngryalien.  I could write
an agent that sends mail to a million people from a million different
(all transient) user ids that might or might not even correspond to real
accounts.  As long as the mail isn't in violation of a very few, mostly
very permissive, laws (no kiddie porn, no spam without an opt-out) it is
right as rain and totally legal.

You CANNOT trust assertions of personal identity on the Internet.  You
will NEVER be able to trust assertions of personal identity without
draconian laws (that I, the ACLU, and many others will oppose, as they
are a much greater threat to my personal liberty than mere spam) and a
certification mechanism that would be reminiscent of the Third Reich's
-- "identity cards" for all humans, carried at all times, required for
all transactions, with massive penalties for lying.  Otherwise, I'm
sending mail from MY laptop and I'll make new accounts up when I want to
and you can neither tell (you're on the wrong side of my security
boundary) nor stop me if you could tell.  Maybe they are for my kids.
Maybe they are for me, so I can use an alias email address when I'm
forced to give an email address to sign up for some service (one always
suspects that these addresses can be grazed or sold for spam mailing
lists).  Maybe the accounts I make are for fun and practice.  Maybe they
aren't even there, as I could be using telnet as an MTA and just making
them up as I go.  How ELSE can I arrange for my kids to get email from
[email-masked] at suitable times of year?

Let's examine the LOGIC of a mail transaction from the receiver's point
of view, at least under current network protocols.  A system connects.
All you know about that system is its IP number.  You CANNOT know what
is behind the IP number.  You CANNOT know the route that the packet took
(if any) before it arrived at the IP number immediately upstream because
even if a protocol supposedly encodes it, the sender has complete
control over the assembly of packets it transmits and can lie through
its digital teeth if it suits it to do so.  All you get is the packet,
and the ONLY part of the packet you can trust is some of its NETWORK
(not mail) header.  As in maybe the ethernet (or whatever physical layer
you are using) header, maybe part of the IP header.

You are therefore forced to "trust" the CONTENT of the packet to tell
you the rest of what you need to know, or the transaction will not work.
If the packet is part of a mail transfer exchange, it will contain
information like the destination, the source, the return address, the
content.

YOUR MTA CANNOT VALIDATE ANY OF THIS OUTSIDE OF WHAT IS IN DNS or other
network registries. The destination might not exist.  The source might
not exist.  The return address might not exist.  The content might be
true, false, legal, or illegal as hell (but encrypted).  The most the
MTA program can do is look up an IP number and see if the
header/envelope data is valid and well-formed and consistent.  It CANNOT
validate whether the alleged sender EXISTS, let alone whether or not it
(not "he" or "she", as it may or may not be human) should be trusted.
As far as the MTA is concerned, the mail is being sent by an MTA, not a
human.  What the MTA sends is obviously out of the control of the
receiver, and barring a psychic receiver or universal identity papers
and the Gestapo, the MTA can lie.

So please, please, please, stop trying to push a system that is supposed
to solve the spam problem based on "trust" of individual identity tokens
on the internet.  Individual identity tokens are intrinsically
impossible to arrange without literally completely restructuring human
society in very disagreeable ways; regulating spam by passing laws that
just take spammers out and shoot them would be easier, cheaper, and more
effective (and less likely to provoke a revolution).

If you want to focus energy on trust, worry about establishing trust of
an entity that is NOT trivial to alter and control without breaking the
network itself -- the network identity of the sending MACHINE(s).  I am
not able to know a damn thing about what is behind a sending MTA's IP
number, but I MUST know the sending MTA's IP number itself or we cannot
set up a TCP-based transaction.  The sender cannot (generally) forge
this because my return packets in the mandatory handshakes would not
reach them because they'd be ROUTED somewhere else by agents outside of
the sender's control. The hierarchical, routed, externally controlled
nature of network traffic and the fairly intelligently regulated
apportionment mechanisms for IP numbers make it relatively difficult,
and even somewhat expensive, to change IP numbers promiscuously, and the
network transaction just plain breaks if you stray from the protocols
and egregiously forge things.

You (or rather, your MTA) can, therefore, decide whether or not you
"trust" the sending IP number.  You will generally only know for SURE
the IP number one step upstream on a message that might have taken
several hops before delivery, but here there is a very reasonable chance
of building a chain of trust back to the sending MACHINE (not human,
machine!).  The delivery information in a mail message's envelope/header
is likely one of the MOST reliable parts of that header, as there is at
least one part of it that cannot be forged by the sender.  I might
indeed make a thousand accounts to fool you as to who I am, none of
which you can IN PRINCIPLE validate, trust-wise (since they may not
exist and are known to an MTA by electronic bits that can be set by my
whim) but you can observe over time that whenever you get mail from my
MACHINE, it tends to be garbage.  (You cannot tell even THAT without
looking -- psychic processes not allowed -- so you'd have to build an ex
post facto discrimination process and accumulate statistics to be able
to identify my machine as a problem).

Eventually, on the basis of this data, you might fairly conclude that my
MACHINE has been taken over by bad fairies, or that its owner is a bad
fairy, and stop listening to it and accepting mail from it; you can
never "filter out" the good fairy messages from bad fairy messages from
this one machine as the machine can hijack every single element of the
"identity" of trusted good fairies. If my machine (really my machine's
IP number) "belongs" to an organization that you could in some sense
"trust" (or at least reliably contact, with properly maintained whois db
information and a postmaster address that is both correctly aligned with
MX records and that points to a human) you might be able to send a
message to postmaster that bad fairies are at work and that mail from
the machine will regretfully no longer be accepted until they are hit
with Black Flag and their little wee corpses are swept up and burnt.

This approach would actually work to abate spam.  This actually DOES
work, right now, as what is likely the secondary method of controlling
evil spew after (or as a feature of) MUA and MTA filters.  Blacklists
and whitelists are nothing but shared or local assessments of trust, but
trust applied to MACHINES (or networks) that are relatively stable
entities and that are "locateable" via the routing of packets, usually
to within a single LAN or domain if not to an actual system in an actual
room, by using required information that won't ALL be untrustworthy.

This is why I like Jeff's suggestion of focussing energy on tightening
up this HOST or NETWORK based trust mechanism, and making the COMMON
PRACTICE of blacklisting abusive networks and hosts a bit LESS arbitrary
and possibly more effective.  I'm not entirely convinced that the IETF
can really help here -- as Dean suggests, it is quite possible that the
IETF can do NOTHING to abate the spam nuisance (which is not to say that
nothing is or will be done, just that the IETF will have no role in it).
Here, at least, it seems like there MIGHT be a role for it and that the
matter is worth pursuing.  Individual "trust" mechanisms, when we cannot
even establish an individual IDENTITY mechanism (because the IETF's
purview pretty much stops at the network boundary abstraction (the
network interface), are not worth pursuing.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:[email-masked]

---

From: Ed Gerck <[email-masked]>
Date: Tue, 16 Mar 2004 22:37:25 -0800

> Ed, are you not paying attention?

Read below and draw your own conclusions, please.
 
> INDIVIDUAL HUMANS on the internet.  

Who is talking about humans? I am talking about EMAIL ADDRESSES, 
MTAs, MUAs, END POINTS. Trust at the end points -- the end point 
is able to do TCP/IP, end points are not human. It is also not
relevant if there is, or there is not, a human in control of an 
end point. It can very well be another machine.

I also mentioned that trust should be based on the same definition
betwen machines as we use for millenia between humans. Why? So that 
machines could use well-developed, real-world, tested notions of
trust -- and be thus useful as our agents.

This answers the rest of your email. Are you paying attention? ;-)

Cheers,
Ed Gerck

PS: BTW, take a look at a work some 5 years ago allowing ISPs to 
identify who was at the keyboard by their usage pattern, in a 
household, to properly target advertising. Humans are more
identifiable on the Internet than you think. But this is
100% irrelevant to what I wrote about. Humans can't do TCP/IP.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 17 Mar 2004 12:26:13 -0500 (EST)

On Tue, 16 Mar 2004, Ed Gerck wrote:

> effective. I guess we agreed on this before ;-) 

I think you must have missed my message noting our disagreement.
http://www.ietf.org/mail-archive/ietf/Current/msg24213.html

> on 'spam-free' is useful-free ;-)

The IETF cannot reduce spam either.  Protocol changes are simply
gratiutious.  One might say that there is very little spam on X.400 mail
systems.  But it is simply because spammers aren't interested, not because
X.400 has some special immunity.  Spammers will simply adapt to any
gratuitous change.  At best, only a temporary reduction would be obtained,
until the spammers adapt. After they adapt, there is no reduction.

However, I think there are things that show some promise that might be
harder to adapt to, such as automated text summarization, bayesian
filters, mail agents that filter on the user's interest in the message
subject, and such. I think these are worth pursuing, but these are not
subjects for the IETF.  Further, there are still inverse methods for
spammers, so even these will simply be temporary.  But I think the benefit 
of intelligent agents and summarization and interest filtering could be 
very beneficial in filtering even non-spam mail.  

Ages ago, managers had secretaries filter there postal mail and phone
calls.  I'd love to have a 'secretary' filter my email, so that I could
subscribe to noisy lists and see only the messages that I was interested
in. But this is technology that isn't a protocol, nor does it seem to be
in need of a protocol, so there is little or no reason for the IETF to be
involved.

> ;-) this mantra is becoming a spam.

Or perhaps it is the mantra that the IETF can do something to reduce spam.

> to be clear, I'm not talking about PKI. 

Actually, I want to receive those bounced messages. Otherwise I don't know
if someone is out there trying to abuse me. Often, the perpetrator can be
identfied from these bounce messages, since they usually include the
original message and its mail headers, which give an IP address and a time
of use.  But it is easy to delete messages from "Mailer Daemon" if you
don't want them.

The problem here is to distinguish the real you from the not-real you.  
Or rather, to distinguish the unauthorized not-real you from both the
authorized not-real-you and the real-you. Real users use relays.  Real
users also use agents, like cron jobs to send email. How do you know the
cron job is not a spammer?  It might be abuse.  It might not be abuse. We
don't know until we check on it. There is no way to avoid this check.

RMX can't work, because real users need to be able to use a wide range of
relays, which depends on their physical location as well as their
arrangements for outsourcing, as well as the service offerings of multiple
providers. For example, Av8 Internet provides relay services for users of
earthlink, because those users have leased line services from Av8, but
email services from Earthlink, and earthlink doesn't do relay service
outside its IP address space.

How is the relay to know if the message is really from you or not really
from you?  Password (or per-user account) style authentication (such as
SMTP AUTH) hasn't had any effect on spam, and it doesn't scale well, and
isn't widely supported. Passwords can be stolen by viruses, or by
disgruntled users if they are well-known. If you exclude PKI, then
spoofing is easy. If you add PKI, then how do we know that the private key
has not been stolen by a virus?  Much or most of the junk/spam is now sent
from viruses. They can certainly start using the infected users identity
if necessary. We should be glad that they aren't.  Forcing them to use the
users identity would be another way to shoot ourselves in the foot.

But none of this would reduce spam, because spammers would simply adapt.

> All we need is to have a degree of spam-freeness that is acceptable.

No. But what we are left with is a whack-a-mole solution that is no better 
than what we have now.  All we can do is automate that whack-a-mole 
procedures. And of course, spammers can automate the avoidance procedures.  
These are constraints that are imposed by information theory, and the fact 
that spammers want to abuse the mail system.

> of bacteria -- which count is low enough to guarantee its stated

Bacteria are not as smart as people trying to abuse the system.  Assuming 
that spammers will be no smarter than bacteria is just another false 
assumption.  Though, perhaps we are getting to the core assumptions that 
people making these proposals are relying on.

		--Dean

---

From: Ed Gerck <[email-masked]>
Date: Wed, 17 Mar 2004 13:19:33 -0800

> http://www.ietf.org/mail-archive/ietf/Current/msg24213.html

Let me make sure. You think then that a spam filter can be 100% 
efficient? If you do, please log off and go sell it. If you
don't then I agree with you.

Cheers,
Ed Gerck

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Mar 2004 13:39:52 -0500 (EST)

> don't then I agree with you.

No, that isn't what I said.   You need to re-read the message. It is 
fairly clear.

		--Dean

---

From: Ed Gerck <[email-masked]>
Date: Thu, 18 Mar 2004 13:44:14 -0800

Dean,

I'm not gonna feed the troll. The bottom line is that spam
filters are not 100% effective and anti-spam protocols are not
100% effective either, in the same way that your car is not
100% fuel effective. The reason is pretty much the same.

Thus, your indefatigable assertion that there are no technical
solutions for spam strikes me as irrelevant. We all work with
and improves things that will never be 100% effective. The good
part of this is that we shan't run out of work ;-)

If you don't agree with any of the above, pls email me in PVT.

Cheers,
Ed Gerck

---

From: Paul Vixie <[email-masked]>
Date: 18 Mar 2004 22:20:51 +0000

[email-masked] (Ed Gerck) writes:

> Dean,
> 
> I'm not gonna feed the troll. ...

NOW you're not gonna feed the troll?  where's the "...any more!" ??

it does me no good to filter out postings from known whackjobs if you
and others are just going to reply anyway, often including the very
drivel that i'd avoided having to look at directly.

please show some self-restraint.
-- 
Paul Vixie

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Mar 2004 18:18:59 -0500 (EST)

Did anyone expect professional behavior from someone who doesn't have an
AUP on their own sites, someone who supports demonstrated abusers, someone
who associates with court-proven liars, and someone who posts misleading
information about their own legal experiences?  I didn't.

Clearly, technical competence does not equate to honesty and integrity.  
It also does not equate to professional conduct.  

And of course, those who lack intelligence to make sensible arguments have
to resort to name-calling.  I'm surprised it took this long to resort to
name-calling.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Mar 2004 18:09:10 -0500 (EST)

Well, you are the one trying to attribute statements that "you agree with"
to me, even though I've made it clear that we don't agree, and why we
don't agree.  

If you can't understand what your opponents position is, and what points
you agree and disagree with, there is no point in discussing it, until you
do.

		--Dean

---

From: Ed Gerck <[email-masked]>
Date: Tue, 16 Mar 2004 17:09:09 -0800

Cheers,
Ed Gerck

---

From: Dean Anderson <[email-masked]>
Date: Sun, 21 Mar 2004 16:41:39 -0500 (EST)

> have a valid email entry for 'no mail accepted', with no mailbox.

What difference is there between 'not accepted, not a valid mailbox', and
'not accepted, never heard of it before'?  Either can still be faked, so 
making a distinction does not remove such an abuse.

Such a distinction just makes the broken Verizon mailbox test be a
somewhat more "valid"  test, but it doesn't change the other negative and
non-scalable aspects of such testing.  More importantly, knowing this
information doesn't help you stop abuse.  It is clearly just a reaction to
the invalid assumptions made by the Verizon test, and an attempt to make
the assumptions less invalid.  However, there is no gain by doing so
because abusers would simply react by using "valid" addresses that are
either "valid, has mailbox", or "valid, no mailbox". rather than simply
randomly made-up addresses.  After abusers adapt, there is no benefit to
the alteration, yet ISPs will have a huge cost in making the changes.

The practice of using false and deceptive email addresses has been made
illegal by the CAN-SPAM Act, and genuine spammers have largely (or
completely) stopped doing this.  That leaves the abusers whose aim is
purely annoyance who fake from:  addresses. But such abusers aren't going
to stop faking from: addresses.  They will just start faking 'valid' from:
addresses that are either 'valid and receive email', or 'valid and don't
receive email'.  They simply adapt.

We have been making gratuitous, dead end, unsuccessful protocol
modifications for 10 years now. Unless you can show that this will
actually lead to something beneficial, it is just another in a series of
gratuitous and expensive changes with no benefits.

>  model would you like?" '

Those who suggest that the decision is not whether a trust model, but
'what kind of trust model would you like' are again jumping ahead of
themselves.  There is no evidence that we need to use a trust model nor
that a trust model will solve the problem. Just the opposite.

We've had a lot of experience with trust over the last 10 years--and we
have frequently found the advocates of trust to be untrustworthy
themselves.  We have seen repeatedly, again and again, that anti-spammer
leaders aren't trustworthy, and use their trusted positions
inappropriately for personal revenge. These aren't simply mistakes, but
are bald lies that are easily disproved. The leaders know, however, that
some people will be misled for some time, anyway.  Given that record, how
can we possibly __trust__ such a proposition?  We can't use a trust model.

Further, as previously pointed out, for a trust model to be effective, one
needs a method of effective identification which we don't have, and which
is a major problem to any trust model, even if the trust operators were
trustworthy.  A trust model won't work.

> the different definitions of spam possible, but how do you want to do it.

I disagree. The problem is how to stop abuse.  We have learned quite a bit
about that. Mostly, we have learned how not to do it.  Some suggest we
shouldn't worry about how to stop the problem, but should simply concern
ourselves with how to effect gratuitous changes. Of course, they don't
describe their changes as gratuitous, but it seems some do think the
question of whether the changes are gratuitous shouldn't be considered
since doing so impedes their implementation.  Obviously, no one wants to
implement gratuitous changes.

We have certainly learned not to do some things:

--- Trust models aren't a solution because the operators are dishonest and
untrustworthy, as history and experience with many dishonest blacklists
has demonstrated.

--- Trust models can't be fixed simply by having more honest operators,
since even a perfectly honest trust authority can't establish the identity
of users so that trust could be removed from abusers or added to
non-abusers.

--- Protocol changes aren't a solution, as experience with POP before
SMTP, SMTP AUTH, and theoretical results have shown.

We have also seen that the problem of Commercial Bulk Email (CBE) has gone
away with the CAN-SPAM Act.  We no longer have a CBE problem, but an email
abuse problem, which is related to the virus and cracking abuse problem.  
Such abuse is the most pernicious, and is conducted by people for illegal
purposes.  We expect or hope that the size of this group is relatively
small.

The solution therefore lies in the realm of legal procedures and law
enforcement which proscribes against certain types of behavior, and
possibly the automation of whack-a-mole tools that detect and react to
abuse, and the enforcement of the rules of law on the abusers.  However,
this is outside the mission of the IETF. Knowing the solution is outside
of its scope, the IETF should issue a statement that deplores the abuse of
IETF protocols, but acknowledges that theory and practice demonstrates
that the IETF cannot make protocols that will be free from abuse.

The existing protocols and present CALEA** support enables tracking the
abusers, and legal procedures can then be used to limit such activities.
Further, the problem of abuse is not limited to email abuse, but to
cracking, viruses, DDOS abuse, and other kinds of abuse that has been
proscribed as illegal.  It seems very clear that dependence on the
Internet will only increase over time, and that over time the activities
of persons using the Internet will become subject of greater legal
controls.

Therefore, the ASRG should be disbanded, since it cannot produce a
protocol that cannot be abused, nor can the existing protocols be altered
so that abuse is not possible.  The IETF should instead focus its energy
and resources on how procotols could be altered to support anticipated
changes to CALEA, and to support anticipated changes in legal controls.  
This purpose is only peripherally related to spam and spam-like abuse.

**CALEA stands for "Communications Assistance for Law Enforcement Act",
and specifies requirements for communications carriers to assist law
enforcement. Mainly, it is concerned with specifying capability
requirements for supporting interceptions and call-identifying information
and compliance with these requirements.