Subject: [Asrg] Bogus reasoning

From: [email-masked]
Date: Tue, 01 Jul 2003 22:23:11 -0500

> As I stated before and you can try this for yourself, the cost of 
implementing 'GIEIS' would be exceeded by the loss to business by keeping 
the SMTP protocol.  Allow me to demonstrate this clearly for everyone.  
Yesterday, I calculated (at ciphertrust.com) that 1000 employees, earning an 
average of $15,000 per year, recieving 20 spam messages a day would result 
in losses of $31,250.  Now, America has approx.  300 Million inhabitants, 
lets say 2 thirds of the population are not affected by spam in the 
workplace.  That still leaves us with 100 Million who would be.  Now we'll 
assume that their average wage would be $15,000 per year (very reasonable 
assumption), if it cost 1000, $31,250, then it costs $31.25 per person, per 
year. $31.25 multiplied by 100 Million is $3,125,000,000 per year.  This is 
just for America alone.  'GIEIS' could absorb $1 Billion per year and still 
make business a substantial profit.  Oh, and one other point, I haven't even 
begun to add on the cost of virus', trojans, etc.  Therefore, 'GIEIS' has 
complete financial justificaton.

Good example of what starts out as a fairly reasonable argument but which then 
makes a large and unjustified leap at the end to a completely illegitimate and 
unjustified conclusion.

It's rather like the timeshare sales presentations which go something like this:

   1)  Do you like the resort?    (A: yes, of course.)

   2)  Can you afford it?         (A: yes.)

   3)  Good, sign here.

The fact is that there are often ALTERNATIVES which are MORE appealing and MORE 
cost-effective.

You can't say that "GIEIS" "has complete financial justification" until you 
demonstrate not only that IT solves the problem, but moreover that nothing else 
solves it better for less.

Personally, I don't think that *any* solution that to be effective requires 
re-engineering the entire world's E-mail infrastructure is a practical solution 
today.  There's just too much of it, in too many places, and with too little 
onsite technical expertise in many of those places.

Again, that's what I like about my "permission list" approach... where it can be 
implemented in as little as ONE SINGLE CLIENT SYSTEM and yield an immediate, 
direct benefit.  It's a scaleable and incrementally implementable approach, 
which is unlike just about ANYTHING else I've seen proposed here.  What's more, 
it's easy to understand and could be manipulated by the user more-or-less 
directly.  The user who benefits the most from it (and is thus motivated) is the 
user who sets up the permission list and maintains it.

It IS true that it doesn't (by itself) "eliminate" spam... but neither will 
anything else I've seen discussed here, either.  My system, in conjunction with 
a good content filter to clean up a lot of the residual plain ASCII text spams 
(and which are thus rendered FAR easier to filter) will probably yield the 
highest benefit, the fastest, for the lowest cost of anything we've been talking 
about.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 02 Jul 2003 11:56:51 -0400

At 10:23 PM 7/1/2003 -0500, [email-masked] wrote:
>[..]
>[..]

However, should we be considering a solution that replaces the email 
infrastructure as a long term answer to spam?

Yakov

---

From: [email-masked]
Date: Wed, 02 Jul 2003 11:50:53 -0500

>infrastructure as a long term answer to spam?

While it might be interesting to blue-sky that, I don't think that discussing it 
as a serious solution to the spam problem is very sensible.  We need something 
MUCH sooner than that, and I think the only practical way to achieve that is to 
build it on top of the system we have today.  And THAT means it must be 
incrementally deployable.  

Stuff that stops senders is nice, but obviously must be deployed universally in 
order to achieve the goal.  Otherwise we'll have a few responsible ISPs whose 
users (like everyone else) still get slammed with spam, and spam-friendly ISPs 
who can't be bothered to put the protections in place.  It only takes ONE 
spam-friendly ISP (and they could be ANYWHERE, including some lawless 
third-world country) as a "safe haven" for the entire world to still get 
spammed.

I personally think that it makes sense to have a recipient-end system (client 
site, or their ISP) where the effort can be made by those receiving the most 
direct benefit from the effort, and where they can proceed without having to 
convince anyone else about their methods.

I don't think that there is a single "silver bullet" (wooden stake?) that will 
instantly stop spam.  What's more likely is that we eventually and progressively 
just put enough sand in their gears that the great majority of them simply give 
up and decide to take up another career.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 02 Jul 2003 12:30:13 -0400

>incrementally deployable.

If we are forming a comprehensive plan for killing spam, then we should 
consider long term solutions as well. We can structure such plan to 
gradually move the Internet with short term, medium term and long term 
solutions, all leading to the long term solutions. I do not think any of 
the short or medium term proposals or approaches can kill spam entirely - 
even your approach will allow ASCII spam through. To completely kill all 
spam will require a long term solutions. However, we do not have to worry 
about a long term solutions right now, we can concentrate on the overall 
plan and specific short-medium term solutions.

>up and decide to take up another career.

It is very well possible that all of the short and medium term solutions 
will "put enough sand in their wheels" to stop them. Nevertheless, long 
term solutions should remain within our ear shot, even if we do not spend 
as much time on them as on short term stuff.

Yakov

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 02 Jul 2003 12:31:20 -0400

That is exactly what I have been saying, on and off, for the past month 
or so (when I thought it was wise to stop lurking).  The only really 
solution to the problem is a receiver side solution, whether it happens 
at the client or the MTA for the user.

Chuck Wegrzyn

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 02 Jul 2003 12:34:55 -0400

At 12:31 PM 7/2/2003 -0400, C. Wegrzyn wrote:

>That is exactly what I have been saying, on and off, for the past month or 
>so (when I thought it was wise to stop lurking).  The only really solution 
>to the problem is a receiver side solution, whether it happens at the 
>client or the MTA for the user.

Would that include consent systems?

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 02 Jul 2003 12:38:16 -0400

Yes. When I designed the solution that Authentica sells (I did the 
design over two years ago) it was a consent system. It uses VPNs and 
X500 certs as a proxy for consent. Simple, yes, but effective on a 
number of different levels.

Chuck

Yakov Shafranovich wrote:

>> That is exactly what I have been saying, on and off, for the past 
>> month or so (when I thought it was wise to stop lurking).  The only 
>> really solution to the problem is a receiver side solution, whether 
>> it happens at the client or the MTA for the user.
>
>

---

From: [email-masked]
Date: Wed, 02 Jul 2003 12:38:05 -0500

>consider long term solutions as well. 

Fine, but let's not do that to the exclusion of solving the problem.  That's 
like discussing what will be done on her first (or third!) drydocking while the 
Titanic is sinking.

>We can structure such plan to 
>even your approach will allow ASCII spam through. 

Indeed, and I propose a hypothesis that *nothing* (practical, anyhow) will 
prevent all possible spam from being sent.  IF you're going to allow people you 
don't know (yet) to send you E-mails (because they saw your Web site, or saw a 
letter to the editor you wrote to your local newspaper, or saw the ad you posted 
on the bulletin board at your local Kroger or something) then there's no way to 
guarantee that the content of that E-mail won't be something commercial which 
you didn't want and don't care to see.

Let's deal instead with the real problem... the high-volume repetitive 
intelligence-insulting stuff that tries to evade filters and muscle its way into 
our homes and our offices.

>To completely kill all spam will require a long term solutions. 

I think it would take more than that... I think it would take a MIRACLE, or a 
change in the basic physical laws of the universe.

Even making all E-mail identifiable doesn't prevent it from being spam... even 
if we CAN go back and absolutely identify the sender.  Disposable accounts, and 
all that.

>However, we do not have to worry 

On that point we agree.

>as much time on them as on short term stuff.

Fair enough.  Meanwhile, let's get some good, practical, implementable solutions 
on the record which can make a significant improvement (at least) in the 
immediate term.

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 02 Jul 2003 13:17:17 -0400

It seems we are getting hung up on two separate problems. Perhaps they 
should be separated out and dealt with. First is the short-term 
solutions to spam prevention. The second is the longer term problem.

In the former there are some very real things we can do to cut down the 
amount of spam. Some of them might be recommendations that users provide 
filtering. Others might be to include consent like systems.

The longer term solution should be predicted, I believe, on the idea the 
IPv6 is going to be the network of choice. It might very well also 
involve more radical changes to the email system (or I would like to 
think message deliver system - has anyone started to get IM spam - I have?).

Peace,
Chuck Wegrzyn

---

From: Barry Shein <[email-masked]>
Date: Wed, 2 Jul 2003 16:16:39 -0400

> infrastructure as a long term answer to spam?

Personally I think we should, with the following reasoning:

1. The (modern) spam problem has been around for at least 7 years,
   I have discussion notes with many of the same topics going back
   to at least 1996.

   Since we're still not making much progress I think it'd be a bad
   idea to cut off ideas, de facto, just because they have a longer
   horizon.

2. This is not to say that proposals with a longer horizon should in
   any way preclude ideas with a shorter adoption period. But as I see
   it, given the seven-plus year history, it may be unwise to rely
   only on the possibility that someone is going to come up with a
   quick fix.

3. It's not clear how to measure these claims that certain changes
   would require years and years to adopt.

   Although it might be reasonable to claim that it'd be years before
   a major new mail protocol were adopted universally, how much of the
   net would have to adopt it before it'd make a significant
   difference in spam reduction?

   For example, if the top 10 ISPs were to adopt some sort of
   significant infrastructure change which reduced spam passing
   through or to them wouldn't that likely reduce all spam
   significantly, even if it only represented a .0001% adoption?

   (this of course presumes some sort of continued inter-operability
   with non-adopters.)

4. Just the same, having looked at some of the suggested alternatives
   to SMTP, I'm not sure they're quite what they're claimed to be.

   By and large SMTP is just another little text-based:

	  VERB [NOUN]* <CRLF>

   protocol (HELO host.name, MAIL FROM:<[email-masked]>, etc.)

   The proposals I've seen just add some new verbs, possibly with the
   intention of replacing some existing verbs, but otherwise are
   pretty much the same thing.

   SMTP has had verbs added before (EHLO, ETRN, etc.)

   One could even imply a major change in implementation (e.g.,
   extensibility) and not really change the protocol much beyond
   adding some new verbs.

-- 
        -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: Barry Shein <[email-masked]>
Date: Wed, 2 Jul 2003 16:28:30 -0400

> at the client or the MTA for the user.

I believe that to be exactly wrong, and not just to be argumentative.

The problems are:

No such solution has been laid out which would discourage a spammer
from continuing to try to find victims. Many end-user solutions suffer
from adoptability problems, complexity of usage (e.g., managing a
Bayesian filtering system or whitelist.)

Being as spammers seem to be using upwards of millions (we don't know,
certainly thousands and thousands) of infected, hijacked hosts the
real possibility is that the net and mail servers in particular will
become so flooded with spam that it will cause the mail infrastructure
and many of its assumptions to fail in various ways (as it is
already.)

Independent of other observations there seems to be some agreement
that spam traffic is increasing exponentially. How long can that go on
before we have significant infrastructure problems (even if just in
cost)?

It remains to be proven whether spammers increase or decrease their
traffic in the face of discouragement (such as filters.)

There is reason to believe that in fact they increase their traffic
when confronted with various filtering etc, even if for no other
reason than the simple observation that for the past few years more
and more filtering has been put in place, and spam has grown rapidly
nonetheless.

Maybe it's a coincidence, maybe it's correlated:

Their cost is so low (using stolen/hijacked resources) that it becomes
worth their while to try less focused brute-force approaches when
challenged by filtering etc.

Put another way, the end-user/recipient proposals thus far are plagued
with the "arms race" problem.

-- 
        -Barry Shein

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 02 Jul 2003 16:30:13 -0400

>   idea to cut off ideas, de facto, just because they have a longer
Actually if memory serves me the first spam was sent by some guy at DEC 
when the Internet was still tightly controlled. I always thought the AUP 
was silly.

>   (this of course presumes some sort of continued inter-operability

I find this very hard to believe. I get so little spam from AOL, MSN or 
Yahoo now a days I doubt it would have any impact on the few hundred I 
get every day!

>   extensibility) and not really change the protocol much beyond
On this point I agree.

Chuck Wegrzyn

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 02 Jul 2003 16:37:34 -0400

Barry,

 What you are saying here is in line with an earlier statement I made. 
The economics are all screwed up for Internet usage. The strength of the 
Internet is the flat pricing - it has afforded a lot of new 
opportunities, like VoIP (and Vonage, for instance). On the other hand 
it has given us the spam problem.

 I believe the only real alternative is for every ISP (and this can be 
done I believe) to take on a per-email transaction fee.

Chuck Wegrzyn

---

From: "Elric Pedder" <[email-masked]>
Date: Wed, 2 Jul 2003 18:08:36 -0400

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of C. Wegrzyn
> Sent: July 2, 2003 16:38
> To: Barry Shein
> Cc: [email-masked]; Yakov Shafranovich; [email-masked]
> Subject: Re: 6. Solutions - Longterm - Replacing SMTP (Re: 
> [Asrg] Bogus reasoning)

> I believe the only real alternative is for every ISP (and 
> this can be done I believe) to take on a per-email 
> transaction fee.

This proposal is made quite often, but I cannot see how it
would work.

SMTP does not require the participation of any ISP other than
for the transmission of packets.  In order to levy a charge,
the ISP would have to monitor your traffic, detect SMTP 
usage, detect actual e-mail delivery, and bill you for it.

What you create is an incentive for users to avoid the
detection of SMTP delivery -- a whole new problem.

Without getting in to the "big brother" concepts or using
some sort of "centralised register of authorised e-mail
delivery agents" perhaps ISPs could bill a higher rate for 
port 25-destined traffic than other traffic, and require that 
every SMTP transaction contain only one RCPT address.

Unfortunately port 25-destined traffic does not actually
cost any more than other-port-destined traffic.  Therefore
in a competitive marketplace prices will be driven down to
cost+margin.

The only weapon I can think of against market competition is
the government.  So... would you accept a government tax on
e-mail?  

Ultimately, I just don't see how you could charge for e-mail.

-- 
Elric Pedder
Mailtraq Development (www.mailtraq.com)

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 02 Jul 2003 18:43:48 -0400

Elric, that is exactly correct. I'd say it isn't necessary to see if the 
email was delivered just that it was sent (think about the USPS - even 
if the mail doesn't make it to the destination you still put a stamp on 
it). Monitoring of traffic by an ISP isn't all that difficult.

The point isn't that anything costs anymore actually. You are merely 
trying to provide an economic disadvantage to sending out a million 
email messages!

Chuck Wegrzyn

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 02 Jul 2003 18:51:11 -0400

I don't know if everyone saw this announcement. It is interesting given 
the recent conversation we have been having about trust

 http://www.ribbs.usps.gov/files/fedreg/usps2003/03-15211.PDF

Chuck Wegrzyn

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 2 Jul 2003 20:31:00 -0400 (EDT)

> in a competitive marketplace prices will be driven down to

I think this reasoning is absolutely correct for leased line customers,
but if an ISP had a mail server that could count messages by submitter (I
know of none that do so) it could easily advertise "100 messages free per
day". The advantage to the ISP would be that spammers wouldn't bother to
register fake accounts to send millions of messages, and the limitation of
100 messages per day wouldn't discourage legitimate dial-up customers the
way a charge for each message would.

In fact, a marketing person might say that "100" sounds bigger than
"unlimited" to the average person. Surely that is why AOL promises
"1000 free hours" rather than "unlimited use for a month".

I really think the inability of sendmail and its ilk to count messages by
actual sender (not envelope or header addresses) is a major source
of the spam problem. SMTP AUTH is a mechanism which would allow such
counting, perhaps someday it will be used.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 02 Jul 2003 20:01:09 -0400

At 06:08 PM 7/2/2003 -0400, Elric Pedder wrote:

>for the transmission of packets.
>[..]

In the proposal put forth by William Dnes, there would be a parallel 
business email system based on charging. The two systems will interoperate 
as far as business email can be sent to personal mailboxes but not vice 
versa. In other systems, a centralized registrar is used.

Yakov

---

From: Barry Shein <[email-masked]>
Date: Wed, 2 Jul 2003 21:36:14 -0400

The idea of charging isn't all that difficult, you just have to find
an amenable model.

For example, you charge a sender to put email INTO an end-user's
mailbox (or not, feel free to accept mail directly into your own
system for free.)

No payment arrangement, no delivery.

Then just allow some free amount which covers most personal usage by
metering the inflow.

But one source sends more than, say, 10K msgs in a month, some
threshold, tell them they pay from here on or you drop all their mail
on the floor with the understanding that continuing to try will be
billed also (USE CONSTITUTES ACCEPTANCE OF TERMS) and bills pursued.

Reserve the right to make exceptions for any reason without
explanation (e.g., if you wanted to let the recent FTC responses
through.)

Now you have an economic incentive to go after spammers, and good
legal basis (theft of service, wire fraud, etc.)

To simplify matters turn it all over to a service to take care of the
billing etc.

-- 
        -Barry Shein

---

From: Selby Hatch <[email-masked]>
Date: Thu, 03 Jul 2003 02:27:33 -0600

[email-masked] wrote:
> prevent all possible spam from being sent.  

What will prevent spam from being sent? The undeniable knowledge that it
will not ever be received and seen.

(snip)

> change in the basic physical laws of the universe.

What will kill spam?

A total, comprehensive, complete, and absolute consent framework
will kill spam.

Under a consent framework, I instruct my incoming MTA not to accept
email from anyone who cannot prove (through some defined method) that
they have my consent to send me email.

If you send me an email and you can't prove to my MTA that you have
my consent, my MTA will not accept your email. It will disgard it or
bounce it -- my choice. If you want my consent, you can ask for it.
I may give consent, I may not respond.

When a consent framework is in place on MTAs, MUAs, Web based MUAs,
list servers, and wherever else it needs to be, people will use it.
It must be made user friendly.

They will hear about it on the media and from their tech friends and
they will want to know how they can use it. They will install the
latest upgrade of Outlook express on their "Windows computer" -- or
they will have their tech friends help them.

That will kill spam.

Unfortunately, some of the motivation to kill spam is lost to
much of the user community. The reason? Spam filters at the major
ISPs. If people were still receiving all of that unfiltered spam,
they would be much more motivated to use a consent based system.
In fact, they would be motivated to use white lists. I use a very
large white list in Exim to rescue false negatives from Spam Assassin. 
It doesn't cut down on internet traffic and I don't like it, but
I use it because I dislike spam more.

Once a consent framework is in place, filters should be turned
off to raise the email users' spam agitation level and motivate
the apathetic to use the consent framework.

Yakov Shafranovich wrote:
>
>> From: "Olson, Margaret" <[email-masked]>
>> To: "'Yakov Shafranovich'" <[email-masked]>
>> Subject: RE: [Asrg] 2. Problem Characterization - Defining spam within
>> con
>>
(snip)
>>
>> (Contrary to popular belief, I have no problem with requiring consent
>> to send mail.)
>>
>> Margaret.
>>

There, that's one person. There must be millions more.

We can discuss server authentication, sender accountability,
SMTP extensions, SMTP replacement, GIEIS, SPF, C/R, Reverse DNS,
HTML mail blocking, greylisting, etc. forever. We need to
simply require proof of consent. In the final analysis, I submit
that with the right technology there will come the time that:

When no one will accept spam, no one will send spam.

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 3 Jul 2003 13:36:08 -0400

Selby Hatch wrote:
> SMTP extensions, SMTP replacement, GIEIS, SPF, C/R, Reverse 
> DNS, HTML mail blocking, greylisting, etc. forever. 
> We need to simply require proof of consent. 

	Precisely. Excellent comment. Providing a method to explicitly
express and managee consent will drastically simplify the entire
problem. Fortunately, the mechanisms for accomplishing this are fairly
well understood and can be deployed initially without requiring
modification to fundamental protocols like SMTP and POP.

		bob wyman

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 03 Jul 2003 13:44:02 -0400

Yes...yes...yes!

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 3 Jul 2003 12:08:05 -0400

>they have my consent to send me email.

The consent systems I see proposed sound a lot like a phone system 
without a phone book.  In order to find out someone's phone number, 
you have to go out of band.

I keep following the logic of consent, but I keep not finding the way 
it's going to work--even if I ignore the UI issues, which I think are 
insurmountable.

Here's how my reasoning goes.

The current email system allows people to send email to people they 
don't know.  That's a feature.  Most people receive email from people 
they don't know, or at least people who they didn't know they knew 
(e.g. grandma on vacation, cousin at new address...).

Any consent system has to have a way for someone to contact me and 
ask for my consent.

That message must contain sufficient information so that I can 
determine if in fact I do want to talk to the person.

In the case of a person that I don't know, that means that they will 
have to provide a summary of *why* they want to talk to me.  (E.g. 
reporting a bug in your software, your system sent me a virus, our 
company changed its name, this is your grandmother sending mail from 
a cruise ship....).

I see absolutely no way to provide that information without providing 
a big enough window for spammers to send ads.

What am I missing?
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 3 Jul 2003 15:41:07 -0400

Kee Hinckley wrote:
> The current email system allows people to send email to 
> people they don't know.  That's a feature.
	Consent based systems need not interfere with this if the system
is used in order to provide preferred handling of mail which is
consented to while still allowing delivery of mail for which consent has
not been granted. For instance, mail which meets all consent rules might
be delivered to the main inbox while mail which does not would be
delivered to a "gray" inbox that would need to be scanned from time to
time. Personally, I don't see how a "graybox" can be avoided...

	Perhaps a good way to think about this would be to remember the
old phrase: "Have we been introduced?" and the once normal practice of
sending "Letters of Introduction." In the old world, you couldn't just
go off talking to anyone you wanted to. The expectation was that you
would be first introduced. If consent based systems become more popular,
what we're going to see is people doing things like writing letters of
introduction. For instance, I'll write an email saying: "Tom asked for
your email address today. He's a good guy and should be on your
whitelist."
	On a more technical line, we might see the creation of a
specific form of email message which is a "request for permission to
send." This would be something like a specific MIME type, perhaps XML
encoded, that would be recognized by consent based systems. One would
send a message in this form providing a self-introduction and requesting
permission to send. Of course, spammers might send such things, however,
my guess is that the response rates would be so phenomenally low that
they would soon stop doing so.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 3 Jul 2003 15:52:14 -0400

Kee Hinckley wrote:
> In order to find out someone's phone number, 
	No. The issue here isn't finding the phone number, its
determining whether or not the phone number you find is useful to *you*.
i.e. Depending on how the consent system is written, it is entirely
possible the many people could know your email address but only some of
them would be able to use it to actually get mail to you (or to your
"green" inbox).

	One addition to my earlier response on "Letters of
Introduction.":
	If the system of monitoring consent relies on PKI certificates
of some sort, then it could be made possible for someone who has been
granted permission to send to you to then "delegate" this permission to
others. For instance, if I know that "Tom" wants to talk with "Kee" and
that I have permission to do so but Tom doesn't, then I could issue a
token to Tom that gave him at least the temporary ability to send mail
to Kee. Kee, upon reading Tom's mail, would then decide whether to grant
Tom continued permission to send or to revoke that permission. Of
course, if I get stupid in handing out Kee's address to too many people,
Kee would probably revoke my permission to do so. (Note: it is
undoubtedly the case that viruses could force improper delegation of
grants. However, as long as delegated grants are time limited or
otherwise expire, the occasional bursts of spam should fade out
quickly.)

		bob wyman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kee
Hinckley
Sent: Thursday, July 03, 2003 12:08 PM
To: Selby Hatch
Cc: [email-masked]
Subject: Re: [Asrg] Nothing will stop spam???

What am I missing?
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP
Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to
accept responsibility for their own actions, or that they are so eager
to regulate everyone else's.

---

From: Selby Hatch <[email-masked]>
Date: Thu, 03 Jul 2003 18:10:30 -0600

Kee Hinckley wrote:

> without a phone book.  In order to find out someone's phone number, you 
> have to go out of band.
> 
> they don't know, or at least people who they didn't know they knew (e.g. 
> grandma on vacation, cousin at new address...).
> 
> Any consent system has to have a way for someone to contact me and ask 
> for my consent.
> 
> That message must contain sufficient information so that I can determine 
> if in fact I do want to talk to the person.
> 
> company changed its name, this is your grandmother sending mail from a 
> cruise ship....).
> 
> I see absolutely no way to provide that information without providing a 
> big enough window for spammers to send ads.
> 
> What am I missing?

I have proposed a message type that is limited to text only.
(see
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05814.html)
It is limited to a fixed number of characters, enough for a
name/identification and reason for correspondence. No URLs are
permitted. The only way to respond and give consent is by return
email to the from email address provided. No one can ask for
permission without a valid email address to provide a way for
consent to be returned.

A related issue is signing up for something, i.e. the FTCs do not call
list. Usually a confimation email is sent back to the person signing
up. The confirmation email usually contains a URL. Because of this,
the request for consent token message cannot be used. At time an
individual signs up, they would provide the consent token
for the FTC to use when then sent a confirmation email. The FTC WEB
site would require this along with the email address. This token
be available on the recipient's MTA so that when the confirmation
email was received, consent would be confimed.

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 3 Jul 2003 17:04:48 -0400

>time. Personally, I don't see how a "graybox" can be avoided...

Most spam filters use it in one way or another.  But we've already 
heard reports (e.g. with the yahoo/donotcall business) that people 
stop looking at them after a while.  And in fact that's been our 
experience with our customers--even though we send them a periodic 
summary via email.

But that's fine.  I can deal with that as an answer to the non-ui 
problems I see with consent.  In fact there is virtually no proposal 
anyone has made here (save the "replace the system" ones) that 
doesn't as it's heart depend on grayboxes and whitelisting. 
Unfortunately the first is vulnerable to volume, and the second to 
spoofing.

>your email address today. He's a good guy and should be on your

That sounds nice.  But it negates a lot of the current benefits of 
email.  (Immediacy.  The lack of a need for an introduction...)

>they would soon stop doing so.

But that falls back to my assertion that providing sufficient 
information to decide whether to talk to someone is going to be 
sufficient for a spammer to send an ad.

Whether that ad would get any response is something I don't think 
we're qualified to judge.  After all, most of us can't imagine why 
the existing ads get any response.  But I suspect that:
	Will you accept mail from someone who wants to sell you Iraqi
	Most Wanted Playing Cards.
would do just fine.

Sometimes I feel like we're the janitors in Kornbluth's "The Marching Morons".
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 3 Jul 2003 21:31:41 -0400

>permission without a valid email address to provide a way for

That sounds like it has potential.

>for the FTC to use when then sent a confirmation email. The FTC WEB

This would probably degenerate to a simple password, since anything 
else would require tight integration between the email client and the 
web browser (and a signup may occur when the email client isn't 
available, or even over the phone).  That's not necessarily bad, but 
it should be recognized.  The other issue here is that this requires 
modifying tens, if not hundreds, of thousands of web forms and their 
backend databases.  Given that, it seems wise to make it possible to 
include the consent token in the email address, potentially as an 
option.  (Although of course that won't work with the FTC site, since 
they decided to invent their own concept of what an email address 
looks like.)
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 03 Jul 2003 22:37:47 -0400

At 12:08 PM 7/3/2003 -0400, Kee Hinckley wrote:

>The consent systems I see proposed sound a lot like a phone system without 
>a phone book.  In order to find out someone's phone number, you have to go 
>out of band.
>
>I keep following the logic of consent, but I keep not finding the way it's 
>going to work--even if I ignore the UI issues, which I think are 
>insurmountable.
>
>The current email system allows people to send email to people they don't 
>know.  That's a feature.  Most people receive email from people they don't 
>know, or at least people who they didn't know they knew (e.g. grandma on 
>vacation, cousin at new address...).
>
>Any consent system has to have a way for someone to contact me and ask for 
>my consent.
>
>In the case of a person that I don't know, that means that they will have 
>to provide a summary of *why* they want to talk to me.  (E.g. reporting a 
>bug in your software, your system sent me a virus, our company changed its 
>name, this is your grandmother sending mail from a cruise ship....).
>

This is a big issue. Off the top of my head I can say that either  this 
initial introduction can be done via a simple ASCII message like Gordon 
suggested in a different thread cutting down on spamming tricks, or the 
consent system can analyze the incoming message and graylist if it looks 
too suspicouis. But you are correct, this is a big issue that need to be 
looked at.

Yakov

---

From: Bruce Stephens <[email-masked]>
Date: Fri, 04 Jul 2003 12:18:53 +0100

Kee Hinckley <[email-masked]> writes:

[...]

> have to provide a summary of *why* they want to talk to me.
> (E.g. reporting a bug in your software, your system sent me a virus,
> our company changed its name, this is your grandmother sending mail
> from a cruise ship....).
>

I don't think you're missing anything.

One answer is that a consent system (or an alternative to the existing
infrastructure) allows reliable separation of email that you know you
want to receive, and the rest.  

As you point out, that leaves the unexpected message from your
cruising grandmother along with the viagra ads, where you'll probably
never see it.

One possibility is the idea of introduction: your grandmother sends an
email to some mutual acquaintance, who forwards it to you.  Oops, that
probably wouldn't work in this case, but it would work in the more
normal case where nobody is travelling.  I'm not convinced that would
work, whether formalised in some way (so the MUA can provide help) or
not.  These chains of trust and things just don't seem to have been
that successful, IMHO.

Another is to introduce some kind of payment (estamps, or hashcash
(proof of work), or similar).  That still allows unsolicited ads, but
it should reduce the insane volumes to a more acceptable level.  A
consent system can be used there, too, to indicate the cost of getting
you to see unsolicited email.

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 4 Jul 2003 11:14:03 -0400

At 9:31 PM -0400 7/3/03, Kee Hinckley wrote:
>else would require tight integration between the email client and 
>the web browser (and a signup may occur when the email client isn't 
>option.  (Although of course that won't work with the FTC site, 
>since they decided to invent their own concept of what an email 
>address looks like.)

Sleeping on this I came up with some more issues (okay, I didn't 
sleep very well).

1. Like many systems, this ties in tightly with identity.  If I move 
to a new ISP (or Comcast gets sold *again*) my email address changes. 
How do I manage notifying all of my contacts.  Some people seem to 
think the address book model works, but I correspond with several 
orders of magnitude more people than are in my address book, and some 
of them I only send mail to every few years--I don't want to have to 
notify them all of a change, nor is it clear to me *how* I would 
notify them of a change without hitting the consent system again. 
It's probably technically feasible, albeit difficult, to do so if I 
know in advance of the change--but that doesn't always happen.  Right 
now people struggle with simple things like transferring their 
address book, never mind transferring consent.  A regular occurrence 
on wormalert is mail from someone to all of their contents with a 
brief comment like "sorry, just mailing myself a copy of my address 
book".  That's how they do it--they put everyone in the to, including 
their new address.  So.  Without a persistent concept of identity, 
consent is rather transient to the recipient, never mind the sender.

2. If a consent token does degenerate to a password, then two 
problems occur.  One, it can be sold along with your email address, 
just as email addresses are sold now.  You've basically made it 
simple for someone to transfer your consent.  the only way around 
that is to tie a consent token to the sender, which means complicated 
software, and a knowledge of what addresses will be used to contact 
you.  (Again, I think people working on this should focus first on a 
URL scheme for whitelisting.  E.g. 
whitelist:some-piece-of-information-identifying-senders.)  Secondly, 
a single password doesn't contain information about what you've 
consented to.  Did I tell them I want a receipt for my order, or that 
I want a daily advertisement?

Note that the latter problem is what I see as a major failing of 
do-not-spam-me lists.  How does a vendor know whether the presence of 
an address on that list applies to what aspect of an existing 
business relationship?  And if it doesn't, then what's the point? 
They shouldn't be sending you email anyway.  This isn't an issue with 
phone call lists because Sears doesn't call you up every day with a 
new ad, so you don't lose anything by putting yourself on a donotcall 
list.
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 4 Jul 2003 13:09:57 -0400

Kee Hinckley wrote:
> it negates a lot of the current benefits of email.  
> (Immediacy.  The lack of a need for an introduction...)
	I agree that the current lack of a need for introductions has
distinct benefits and it will be a nuisance to lose it, however, I think
we need to recognize that the world is not what it once was. In the "old
days" you could assume that anyone who was able to send email was
probably someone worth corresponding with and you could assume that they
probably held respect for the network and valued the rules and customs
for its use. We can no longer make these assumptions. The world has
changed. Today, it is precisely this "benefit" of easy access that
provides the opening for spammers. 
	There should be no question that moving to the kinds of systems
that are required to reduce spam will result in some loss of
opportunities for serendipity etc. However, this is a cost that we have
little choice but to accept. We should be thankful, I think, that we
were able to use the Internet in a "collegial" and "trusting" fashion
for as long as we did.

		bob wyman

---

From: "C. Wegrzyn" <[email-masked]>
Date: Fri, 04 Jul 2003 13:15:30 -0400

I've noticed recently that we have 3 or 4 separate conversations going 
on in parallel. I am finding it very difficult to keep things straight. 
I was wondering if it would be possible to get a summary of exactly 
where we are in ASRG.

Regards,
Chuck Wegrzyn

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 04 Jul 2003 14:12:02 -0400

At 01:15 PM 7/4/2003 -0400, C. Wegrzyn wrote:

>I've noticed recently that we have 3 or 4 separate conversations going on 
>in parallel. I am finding it very difficult to keep things straight. I was 
>wondering if it would be possible to get a summary of exactly where we are 
>in ASRG.
>
>Regards,
>Chuck Wegrzyn

We are trying to steer towards defining a consent framework but since the 
ASRG is seen sometimes as the authority on spam issues, every proposal 
under the sun makes its way here.

---

From: "C. Wegrzyn" <[email-masked]>
Date: Fri, 04 Jul 2003 20:29:09 -0400

Thanks Yakov. That is what I thought but with all the postings I was 
begining to wonder exactly what was going to be proposed.

Chuck Wegrzyn

Yakov Shafranovich wrote:

>> I've noticed recently that we have 3 or 4 separate conversations 
>> going on in parallel. I am finding it very difficult to keep things 
>> straight. I was wondering if it would be possible to get a summary of 
>> exactly where we are in ASRG.
>>
>> Regards,
>> Chuck Wegrzyn
>
>
> We are trying to steer towards defining a consent framework but since 
> the ASRG is seen sometimes as the authority on spam issues, every 
> proposal under the sun makes its way here.
>

---

From: Walter Dnes <[email-masked]>
Date: Mon, 7 Jul 2003 01:20:18 -0400

On Fri, Jul 04, 2003 at 11:14:03AM -0400, Kee Hinckley wrote

> How do I manage notifying all of my contacts.

  If it's important enough, get a personal domain, even if it's only a
cheap email+web re-direction service to your physical ISP.  You get to
keep the address when you change ISP.

> whitelist:some-piece-of-information-identifying-senders.)

  PGP (and GPG) already exist, and have been in use long enough that
submarine-patents are unlikely (never say "never").  Front-ends for
signing exist in Windows, even.  No need to re-invent the wheel.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Barry Shein <[email-masked]>
Date: Mon, 7 Jul 2003 18:57:01 -0400

On July 5, 2003 at 18:18 [email-masked] (Dave Crocker) wrote:
 > Barry,
 > 
 > BS> The idea of charging isn't all that difficult, you just have to find
 > BS> an amenable model.
 > 
 > Forgive me, Barry, but the idea of world peace isn't all that difficult
 > either.  You just have to find an amenable model.

I'm not sure sarcasm adds a lot to the knowledge base.

 > Effective real change to complex, existing human social systems is
 > always difficult, and frequently has proved impossible.
 > 
 > I said always.
 > 
 > Feel free to cite large-scale examples to the contrary.

Yeah well this is just spam not world peace.

Besides, we've had relative world peace since WWII and most skirmishes
have been quite localized (no fun for the locals caught in the middle,
but no world wars either, and the cold war wasn't a war it was a
metaphor for diplomatic tension.)

And there's a reason for that, I'm not pursuing this without purpose.

Towards the end of WWII some of the larger nations who were allies at
the time sat down (e.g., at the Bretton Woods meetings, also the IMF)
and came up with a game theoretic way to make large scale war at least
among major industrialized nations less likely.

What they did was agree to become interdependent in the manufacture of
major weapons components.

So, a jet fighter might be built in the US (Lockheed), but its engines
or crucial navigational parts etc might be built by the UK
(Rolls-Royce) or Sweden (Volvo), etc.

Which makes it that much more difficult for the US to go to war
against the UK or Sweden or any of the other nations mutually
participating in this.

For example, there'd be quite a bit of warning that something was up
when the nation which planned to become belligerent started building
parts of war machinery it had agreed to rely on other countries for.

It's certainly not the only thing which keeps the US and UK out of war
with each other, obviously some pairings are highly unlikely anyhow,
but there are a lot of other nations involved who are more likely to
have fall-outs.

Thus we've seen war shift more and more to the "outsiders" who
generally don't fit into this rather clever scheme (and can't be made
to easily fit, they need another solution entirely.)

But at least we keep many of the nations who really could conduct
massive, destructive, widespread, warfare with each other as we saw in
WWII, in a position where that's likely to be inconvenient or at least
would force them to tip their hands early as they violated the terms
of the alliance.

The big problem today is that weapons of mass destruction (NBC) seem
capable of letting nations which are industrially, technologically,
and economically incapable of conducting widespread warfare in the
usual model cause the kind of destruction we had hoped was contained
to local skirmishing.

But, as I said, you have to find the right model.

So, yes, even world peace is amenable to such things.

-- 
        -Barry Shein

---

From: Selby Hatch <[email-masked]>
Date: Mon, 07 Jul 2003 21:14:28 -0600

>> they decided to invent their own concept of what an email address 
I considered the possibility of having a consent token as part of the
email address, something like recipient/[email-masked]. The major
problem with this is that the consent token is so closely tied to the
email address that it would be very easily compromised. You sell the
email address and the consent token in one simple transaction.

I view the consent token as a separate entity from the email address.
The consent token would be inserted from some source (address book,
keyboard, token repository, etc.) into a header by the MUA
-- implementation details.
> 
> Sleeping on this I came up with some more issues (okay, I didn't sleep 
> very well).
> 
> 1. Like many systems, this ties in tightly with identity.  If I move to 
> a new ISP (or Comcast gets sold *again*) my email address changes. How 
> do I manage notifying all of my contacts.  Some people seem to think the 
> address book model works, but I correspond with several orders of 
> magnitude more people than are in my address book, and some of them I 
> only send mail to every few years--I don't want to have to notify them 
> all of a change, nor is it clear to me *how* I would notify them of a 
> change without hitting the consent system again. It's probably 
> technically feasible, albeit difficult, to do so if I know in advance of 
> the change--but that doesn't always happen.  Right now people struggle 
> with simple things like transferring their address book, never mind 
> transferring consent.  A regular occurrence on wormalert is mail from 
> someone to all of their contents with a brief comment like "sorry, just 
> mailing myself a copy of my address book".  That's how they do it--they 
> put everyone in the to, including their new address.  So.  Without a 
> persistent concept of identity, consent is rather transient to the 
> recipient, never mind the sender.
Yes, unfortunately, unless you have a private domain, changing email 
addresses requires notifying senders. But, it should not require
giving out new consent tokens. The consent framework should be such
that if you change ISPs, consent tokens that are currently valid
would continue to be valid for your new email address at the new
ISP. Some mechanism should be in place to update the new MTA for
incoming mail with your old consent tokens.
> 
> 2. If a consent token does degenerate to a password, then two problems 
> occur.  One, it can be sold along with your email address, just as email 
> addresses are sold now.  You've basically made it simple for someone to 
> transfer your consent.  the only way around that is to tie a consent
> token to the sender, 
Yes.
which means complicated software, and a knowledge
> of what addresses will be used to contact you.  
Yes.
(Again, I think people
> working on this should focus first on a URL scheme for whitelisting.  
> E.g. whitelist:some-piece-of-information-identifying-senders.)  
> Secondly, a single password doesn't contain information about what 
> you've consented to.  Did I tell them I want a receipt for my order, or 
> that I want a daily advertisement?
The single password may not be sufficient information, but the 
relationship of the sender to the consent token and any attributes
that may be specified would be.
> do-not-spam-me lists.  How does a vendor know whether the presence of an 
> address on that list applies to what aspect of an existing business 
> relationship?  And if it doesn't, then what's the point? They shouldn't 
> be sending you email anyway.  This isn't an issue with phone call lists 
> because Sears doesn't call you up every day with a new ad, so you don't 
> lose anything by putting yourself on a donotcall list.
It would be up to the recipient to keep track of the sender/consent
token relationship. MUA software should do most of the work.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 8 Jul 2003 23:41:15 -0400

>keyboard, token repository, etc.) into a header by the MUA

That's in the case of my sending email to someone else.  I'm trying 
to figure out how a separate consent token fits into the case of my 
subscribing to this mailing list (for instance).

>giving out new consent tokens. The consent framework should be such

Again, recipient vs. sender issue.  I should be fine receiving from 
people I've agreed to receive from.  However what is the process for 
updating *their* consent to receive from *me*?  And how does it work 
if I don't get the opportunity to notify them until *after* the 
change.  (E.g. just got laid off.)

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 8 Jul 2003 23:36:32 -0400

>keep the address when you change ISP.

I'm not talking about importance.  I'm talking about usability. 
Consent systems make domain name changes much more painful.

>signing exist in Windows, even.  No need to re-invent the wheel.

You've lost me.  What does this have to do with consent token's not 
degenerating to passwords, or with URL schemes for whitelisting?
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 09 Jul 2003 07:50:57 -0400

There are really two ways to handle this it seems. First is the notion 
of "consent" token that travels with the message; this is the key that 
unlocks the door on the receipient's email system. The second is the 
idea of a list kept at the receipient's email system.

The consent token traveling with the email seems to be somewhat 
problematic. It would have to prevent middlemen attacks and for that to 
happen the token would need to encode the source of the email message. I 
believe that is a problem.  For instance I have two email clients with 
two different email addresses - one being the company I work at and the 
other being my personal account. Now if the token includes the 
originating address I would have to have two different tokens. I would 
think we would want a single token regardless of where I am and whatever 
address I use and that would make a lot of work. But this single token 
would make it susceptible to middleman attacks.

In the receiver side screening mechanism, the second idea, I keep track 
of addresses that I am willing to accept. As noted earlier very little 
mail is sent through multiple MTA's (though I can tell you of one case 
that it will happen!). This is patently more simple. I both cases - the 
token and screening - I need to keep something to note who to allow 
through. But in the former instance the sender needs to do something as 
well. Seems like more work.

Am I missing something here?

Peace,
Chuck Wegrzyn

Kee Hinckley wrote:

> That's in the case of my sending email to someone else.  I'm trying to 
> figure out how a separate consent token fits into the case of my

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 09 Jul 2003 07:57:50 -0400

I thought you might all enjoy this article written in WinXPnews (please 
no Microsoft rants)...

*ISP Spam Filtering Services: Blessing or Curse?*

Over the last few weeks, several readers have written about their ISPs' 
spam filtering services – usually with complaints. On more than one 
occasion, we've heard that the ISP's software is preventing users from 
receiving mail they want to get (including the WinXPnews), along with 
the spam they don't want. In response to consumer complaints about the 
deluge of spam they get, more and more ISPs are getting into the act of 
installing spam filters at the server level, but some are implementing 
this feature more effectively than others. The number of "false 
positives" varies a lot, depending on the software that your ISP uses 
and how they have it configured.

The primary complaint from our readers is that they want more control 
over the filtering for their own accounts, and easier interfaces for 
reviewing and deleting the suspected spam that's been caught by the 
filters. Owen in California wrote that, using Earthlink's spam blocker 
tool, it took 15 minutes to delete 100 messages. At that rate, I would 
have to spend a couple of hours a day deleting spam.

The best filtering programs not only allow you to filter by keywords 
(both in the subject line and the body of the message), but also allow 
you to set both blacklists (addresses and/or domains that should always 
be blocked) and whitelists (addresses and/or domains that should never 
be blocked, even if the message content triggers other spam filters). 
The latter is a big help in preventing messages from important people 
from being "lost" due to the spam filters. Other options, such as a 
choice to block all external graphics or block HTML email altogether, 
are also handy.

How do you feel about ISP spam blocking? Does your provider do a good 
job with this, use filtering software that drives you nuts, or just let 
everything through? Do you think spam filtering should be done at the 
ISP level or would you prefer to control it at the user level? Let us 
know what you think, at [email-masked] 
<mailto:[email-masked]>.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 09 Jul 2003 07:48:06 -0400

"C. Wegrzyn" <[email-masked]> wrote:
> spam filtering services =96 usually with complaints. On more than one
> receiving mail they want to get

  So they don't implement the consent of the recipient.  That's bad.

  One more thing to add to a 'recommended practices' document, in a
"SHOULD NOT" section, along with outbound port 25 blocking.

  Alan DeKok.

---

From: [email-masked] (Justin Mason)
Date: Wed, 09 Jul 2003 09:58:32 -0700

> choice to block all external graphics or block HTML email altogether, 

Yeah, we (SpamAssassin) have been saying this for ages.   Unfortunately
I get several mails a day from end-users who have had SpamAssassin
installed by their ISP or web hosting company, with

  - filtering turned on for all accounts by default

  - no notification that it was installed

  - no configuration interface or way to perform white/blacklisting

  - only interface for users is via a call to tech support!

That results in pain for everyone involved -- except for the ISP,
I suppose.  A bad situation.    We strongly advise against this in
all our doco, but it still happens regularly... >:(

--j.

---

From: [email-masked]
Date: Wed, 09 Jul 2003 20:38:01 +0200

--On 9. July 2003 07:57 -0400 "C. Wegrzyn" <[email-masked]> wrote:

> I thought you might all enjoy this article written in WinXPnews (please no
> Microsoft rants)...
> 
> spam filtering services ? usually with complaints. On more than one
> receiving mail they want to get (including the WinXPnews), along with the
> spam they don't want.

Sunbelt spammed their winxpnew and w2knews from 2000 to 2002, and
have been widely blocklisted for their continued abuse.

Their spamvertized 'IHateSpam' is of no use for any clueful user
anyway which would never use Outbreak for obvious security reasons.

See <http://spews.org/html/S471.html> and Google.

Fortunately some people followed the boulder pledge:

<snip>
From: Eric Shanfelt ([email-masked])
Subject: Re: SPAM: Sunbelt-software spams, "The dog ate my backups" 
Newsgroups: news.admin.net-abuse.email
Date: 2000/06/19 

Hi all,

The Sunbelt spamming issue was brought to my attention last week. Just want
you to know that Windows 2000 Magazine and Duke Communications does not
endorse spam in any way and, as our privacy policy reflects, we have a
strict policy against UCE. We understood the Sunbelt newsletter to be opt-in
and sponsored it in good faith. Apparently we were misled. We will not be
sponsoring that newsletter again until it can be proven to be 100% opt-in (a
hard thing to do).

Eric Shanfelt ([email-masked])
Director of Online Media
Windows 2000 Magazine / SQL Server Magazine
</snap>

---

From: Barry Shein <[email-masked]>
Date: Wed, 9 Jul 2003 18:04:17 -0400

As an ISP my experience has been that people just want a spam filter
which works perfectly and without any effort, or little effort.

If it lets spam by, then it sucks.

If there are any false positives, then it sucks.

If a filter mostly works, then they claim spam isn't enough of a
problem to risk false positives (note the paradox.)

Yes there are tinkerers who will futz with spamassassin etc but
they're a tiny minority.

Most of the mail is your usual:

   I get a lot of spam on this account some of which is
   offensive. I pay you good money, if you can't keep this
   out of my account then I'll take my business elsewhere.

or

  Your filter rejected mail which was not spam. I pay you good
  money, if you can't keep the spam out of my account while
  ensuring I get all email I want then I'll take my business
  elsewhere.

etc.

It's a thankless position to be in.

-- 
        -Barry Shein

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 09 Jul 2003 18:13:14 -0400

Barry I agree. I was one of the cofounders of Destek.net, an ISP in Nashua.

Chuck Wegrzyn

---

From: Walter Dnes <[email-masked]>
Date: Thu, 10 Jul 2003 06:11:37 -0400

On Tue, Jul 08, 2003 at 11:36:32PM -0400, Kee Hinckley wrote

> degenerating to passwords, or with URL schemes for whitelisting?

  The best response is an example.  Here goes.  In both instances, we'll
assume extensions to SMTP.  ("EHLO").

  Password approach
  =================
  ASRG puts up an XML structure on its signup page.  The necessary
elements are something like
  - TOKEN = OOGA_BOOGA
  Subscribing consists clicking on a URL.  This will pop up a dialog in
the users's browser that...
  1) Submits the the user's email address to the mailing list
  2) Saves the XML token data to the user's account on his ISP.

  Spammer notices that this group is almost exclusively male, and a
p****-enlargement ad will be "100% targetted".  Spammer sends a spam
containing the additional SMTP command...
  TOKN: OOGA_BOOGA
Recipient's ISP checks their database, sees that this client has listed
OOGA_BOOGA as a valid consent token, and lets the spam through... oops.

  Key-based approach (similar to ssh)
  ==================
  ASRG puts up an XML structure on its signup page.  The necessary
elements are something like
  - TOKEN = blah_blah_blah, where blah_blah_blah is either public key or
    a URL pointing to a public key (DSA/RSA/whatever).
  Subscribing consists clicking on a URL.  This will pop up a dialog in
the users's browser that...
  1) Submits the the user's email address to the mailing list
  2) Saves the XML token data to the user's account on his ISP.

  The extended SMTP transaction would include the following...
(sender) "TOKN: blah_blah_blah"
The recipient's ISP consults its database.  If that recipient doesn't
have that token in its list, reject email.  If recipient has token, the
ISP's MTA will
  - calculate a short random character string
  - encrypt it using the public key passed or referenced in TOKN:
  - send back to sender...
    CHLG: sdfdjkssdkjhdui89348gobbledygook <encrypted string>
  The sender responds by transmitting back in cleartext, a decrypted
version of the CHLG: string.  If it's successful, the email is accepted.

  Advantages are similar to ssh
  - Any sender can generate their own keys for their own mailings; no
    central signing authority needed (Sorry Verisign<g>)
  - People can listen in to the exchange with a packet-sniffer, and
    nobody this side of the NSA will be able to forge the token.  The
    sender requires the private key corresponding to the public key in
    order to be able to successfully respond to CHLG:
  - Separate keys for separate lists are possible, for fine-grained
    control
  - The same private key can be shared amongst multiple senders if
    required
  - Listing/revoking is handled by client on their ISP.
  - No bounces to innocent 3rd parties.  An SMTP-time 5XX reject is
    issued instead

---

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

Barry,

 >> either.  You just have to find an amenable model.

BS> I'm not sure sarcasm adds a lot to the knowledge base.

That's why I made of point of continuing with pristine seriousness.

In fact, even the sarcasm was not really sarcasm. I believe the logic
you used was the same as I recited. I cited an extreme to make clear the
nature of the underlying logic I saw with your statement.

Besides, we do not have nearly enough serious levity on this list.
Silliness and offensiveness, sure, but not simple levity amidst serious
content.

 >> Feel free to cite large-scale examples to the contrary.

BS> Yeah well this is just spam not world peace.

BS> Besides, we've had relative world peace since WWII and most skirmishes
...
BS> And there's a reason for that, I'm not pursuing this without purpose.

You might want to look over the numbers of people killed from
inter-group violence every year, and reconsider your claim that we have
anything approaching world peace.

Localized solutions are not system solutions, no matter how significant
the locality.

So, again I will ask:  If you have any sort of engineering basis for
demonstrating a track record of success involving anything like the kind
of cooperation and technology you are proposing, please cite it.

As nasty as spam is, it is a not a world war, and countries are not
likely to have the same motivations for cooperation.  You may well try
to dispute that, but let me cite a small anecdote about the motivation
of governments to cede their authority over to a "world" government:

At one point in the earlier days of DNS name space expansion
discussions, an attorney suggested that dispute resolution be achieved
with actual international (ie, between and across nations) law (ie, law,
not contract enforcement as we now have.) Intellectual property issues
are a very serious international matter, with a considerable history of
international discussion.

A global, legal authority for domain name disputes would be a cleaner
solution that we are now using, so I was hopeful... until he explained
that there was no basis for such international law, now, and that it had
been under discussion for 100 years.

I am assuming that most folks want useful spam controls in a shorter
time-frame than centuries.

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: Thu, 10 Jul 2003 16:16:26 -0400

I think the underlying point, to cut to the quick, is that in the end
it's all game theory and one effective means of playing game theory is
to use real economics (money) to assign the cost weightings.

But "I'll cut, you choose" and similar games are also effective in
many walks of life.

Of course, the big problem in that always is when one side or the
other can cheat.

I know, easier said than done...

-- 
        -Barry Shein