Subject: Re: [Asrg] FeedBack loops

From: Franck Martin <[email-masked]>
Date: Wed, 12 Nov 2008 11:24:21 +1200 (ANAT)

Yes it is a simple process, I was just thinking of having that process as a ready in-built engine, or third-party engine in MTAs. For the moment as said it is mainly custome code. If such capabilities would be available in sendmail or postfix, that would allow fbl to be implemented by large organisations (like universities, etc...) easily. 

Well the after the fact fbl, I was not particulary thinking of ARF, but I think the return receipts are becoming more and more useless. 

----- Original Message ----- 
From: "J.D. Falk" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Wednesday, 12 November, 2008 10:20:55 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] FeedBack loops 

On 11/11/2008 15:04, "Franck Martin" <[email-masked]> wrote: 

> Well a bit of background. 
> 
> Is the ARF standard well accepted, I see AOL and a couple use them. I see also 
> that hiding the user that reports the spam may not allow for the recipient of 
> the report to act correctly. 

Very well accepted, yes. Nearly every complaint feedback loop uses ARF. 

> Are there any tools/library available around ARF, to 1) create these reports 
> 2) parse/process them 

http://wordtothewise.com/resources/arf.html has some. 

> Any chance to have these tools build in in major MTAs ? Does it make sense? 

I'm not sure what that would achieve. The actual process is: 

1. $A sends a message to $B 
2. $B complains to $C (their ISP) about the message (example the "spam" 
button in the Yahoo! Mail web UI) 
3. $C encapsulates the message as ARF, and sends it to $A (if $A has signed 
up to receive that feedback) 

Lots of people want to make it more complicated, but it really is that 
simple today. 

> Could they be an after the fact fbl? let say I want to know if my email got 
> delivered, query an mta, supplying some data like domain/sender IP, and the 
> mta sends me any report over last few hours.. 

No, ARF isn't (as far as I know) used for delivery reports. It was created 
for -- and is primarily used for -- user complaints, as described above. 

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

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 11 Nov 2008 16:33:15 -0700

On 11/11/2008 16:24, "Franck Martin" <[email-masked]> wrote:

> Yes it is a simple process, I was just thinking of having that process as a
> ready in-built engine, or third-party engine in MTAs. For the moment as said
> it is mainly custome code. If such capabilities would be available in sendmail
> or postfix, that would allow fbl to be implemented by large organisations
> (like universities, etc...) easily.

I guess I'm just not understanding how that would work.  It's the MUA that
generates the complaint (upon user request), and passes it on to another
system so it can be processed & potentially forwarded on as an ARF message.

> Well the after the fact fbl, I was not particulary thinking of ARF, but I
> think the return receipts are becoming more and more useless.

Heh, no argument there -- but that's not the problem ARF was trying to
solve.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 11 Nov 2008 15:34:53 -0800

On Nov 11, 2008, at 3:24 PM, Franck Martin wrote:

> Yes it is a simple process, I was just thinking of having that  
> process as a ready in-built engine, or third-party engine in MTAs.  
> For the moment as said it is mainly custome code. If such  
> capabilities would be available in sendmail or postfix, that would  
> allow fbl to be implemented by large organisations (like  
> universities, etc...) easily.

ARF is pretty much unrelated to the MTA.

Sending of feedback loop reports is done by the MUA (for a fairly  
loose definition of MUA) and the handling of them is done by custom  
code that knows how to count and unsubscribe based on the reports -  
the ARF specific code in both cases is a trivial fraction of the whole  
application.

The MTA doesn't really get involved at all, other than to ship the ARF  
report around as an opaque RFC2822 message

Cheers,
   Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 11 Nov 2008 19:48:01 -0500

> ARF is pretty much unrelated to the MTA.

Well, you could certainly envisage an ARF implementation directly tied
into a filtering MTA that fires off an ARF for every spam it can
identify if it can figure out who to send it to.

However, given the volumes that even merely medium sized MTAs see, and
at least some possibility of false positives, even if it didn't blow the
ARF-recipients off the air, the volume and potential problems would
render it useless.

It just don't scale.

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 12 Nov 2008 07:45:22 -0500

> ARF-recipients off the air, the volume and potential problems would

I'm going to concur here, and in addition suggest that this is yet another
instance of an approach that fails a basic "sniff test" for any email
abuse technology: does it generate more email?   If the answer is "yes",
then it's probably a bad idea, because the last thing we need when we're
drowning in junk SMTP traffic is more.

Incidentally, I recently concluded an analysis of nearly 5 years worth of
feedback loop traffic from AOL.  (Which is the first one I started using
on a site of appreciable volume.)  This analysis, partially automated
and partially manual, arrived at the following interesting conclusion:
the FP rate is 100.000%.  Every single feedback loop report identifying
traffic as spam was wrong.

I don't say that to criticize AOL so much as I do the approach - which
is end-user-driven.  Let's keep in mind (as Marcus Ranum famously pointed
out) that half of users will click on anything that purports to contain
naked pictures of semi-famous females.  I don't think this population is
within a light-year of being qualified to make spam/not-spam decisions.
(And by the way, I have no reason to think that AOL's user population
is any better or worse at this than anyone else's.)

(By the way, has implications for the dubious approach of quarantining,
which also relies on the ability of end users to make spam/not-spam,
phish/not-phish, etc. decisions.  There is no reason to think that
they're any better at that.)

---Rsk

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 Nov 2008 11:00:31 -0700

> traffic as spam was wrong.

That just means you aren't sending what you'd consider to be spam.

If a statistically valid sample of an ISP's users (as processed by their own
user reputation systems) think something is spam, why would that ISP
disagree?

I know it's a big shift in thinking from the classic anti-spammer attitude,
particularly the pornography test (I know it when I see it.)  But, it's a
shift that all of the big ISPs have already made: they'll listen to their
users before they'll listen to random external parties.

---

From: Jose Celestino <[email-masked]>
Date: Wed, 12 Nov 2008 18:27:11 +0000

> traffic as spam was wrong.

I have the opposite experience.

> is any better or worse at this than anyone else's.)

No, users tend to fail on their evaluation lots of times. That's why you
should rely on multiple reports from diferent users and work over a
statistical analysis of that. Never on single reports.

-- 
Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc
----------------------------------------------------------------
"One man’s theology is another man’s belly laugh." -- Robert A. Heinlein
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Wed, 12 Nov 2008 11:16:01 -0800

>user reputation systems) think something is spam, why would that ISP

That's an interesting question.

>users before they'll listen to random external parties.

The pornography test is a way to avoid having to deal with the 
end-user's definition of spam.  I'm going to give an example based on 
your first question.  I'm subscribed to this mailing list.  Due to 
the high volume of list traffic, I no longer want to receive the 
emails.  I click on a button in my MUA to report the email as spam 
(it's unwanted).  A feedback report is sent to the mailing list owner 
with all user identifiers removed.  There are ways around that but 
let's not get into that.  How does the mailing list owner deal with 
the problem?

Regards,
-sm

---

From: Franck Martin <[email-masked]>
Date: Thu, 13 Nov 2008 07:40:17 +1200 (ANAT)

list washing if he knows who received the email and reported otherwise the list owner mark as spam the report ;) 

----- Original Message ----- 
From: "SM" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Thursday, 13 November, 2008 7:16:01 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] FeedBack loops 

Regards, 
-sm

---

From: der Mouse <[email-masked]>
Date: Wed, 12 Nov 2008 14:49:23 -0500 (EST)

> If a statistically valid sample of an ISP's users (as processed by
> their own user reputation systems) think something is spam, why would
> that ISP disagree?

Ummm...maybe because they know most end users don't know the difference
between spam and other forms of unwanted mail?

> I know it's a big shift in thinking from the classic anti-spammer
> attitude, particularly the pornography test (I know it when I see
> it.)  But, it's a shift that all of the big ISPs have already made:
> they'll listen to their users before they'll listen to random
> external parties.

And when it comes to "this is mail we want to block", they should.  But
when it comes to "this mail is spam", they shouldn't, or at the very
least should apply some local intelligence by someone who _does_ know
the difference.

One of the things I've noticed is that far too many people - on any
side - seem to lose track of the fact that mail can be non-spam and
still be eminently blockworthy.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 12 Nov 2008 15:21:52 -0500

> traffic as spam was wrong.

On a similar note, we average about 2-5 spamcop reports a week.  Only
two of them have been right in the past 5 or more years.

Rich's "result" is largely because he doesn't spam, his reports are by
fat-fingered TIS buttons.

Our "result" is because we have a /8, and therefore somewhere around 1%
of all forged Received headers are in our /8.  Even spamcop's header
parsing goofs, and when it does, we get dinged. [Yes, we deal with the
true positives, and Spamcop is made aware of the parsing goofs.  We are
satisfied with the current situation, despite the vast majority of the
reports being wrong.]

Our AOL FBL had a similar experience: 100% of our reports were wrong for
one of two reasons: fat-fingered TIS buttons, or, the fact that their
FBL generator couldn't cope with /8 declarations, and gave us reports
for someone else's allocation ;-)  AOL eventually turned it off because
we mutually decided it wasn't worth the bits.

That is by no means to imply that FBLs are always wrong, or even wrong
most of the time.  I'm sure that the vast majority of AOL's FBL reports
are absolutely right.  It's just that neither Rich nor us see a
"typical" picture.

> they're any better at that.)

Our experience has been, given the number of people who fall for phish
and other things, that the filters are more consistently accurate than
the humans in spam/non-spam determinations.  Even when the human is me
:-(  My FP rate of the quarantine folder (for an unfiltered account
relying on Tbird Bayes for local quarantine) really sucks.  Probably >50%.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 Nov 2008 13:24:29 -0700

> let's not get into that.  How does the mailing list owner deal with

I agree, that particular scenario is difficult.  However, not all feedback
reports have the user identifiers removed.  IIRC the ARF spec mentions that
the practice exists, but is not recommended.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 Nov 2008 13:29:01 -0700

> between spam and other forms of unwanted mail?

Why should that matter?  It's unwanted, and it got reported, and it's up to
the ISP to decide what to do about that.

> least should apply some local intelligence by someone who _does_ know

That's what reputation systems do.  Some of them do it well, some do it
poorly, but they all do it much faster and more accurately than the old
"which /24 has pissed off the sysadmin today?" method of spam-blocking.

> still be eminently blockworthy.

Maybe because they don't care if there's a difference between spam and other
forms of unwanted mail?

---

From: Franck Martin <[email-masked]>
Date: Thu, 13 Nov 2008 08:38:09 +1200 (ANAT)

It seems to me that FBL are good between MTAs. I'm not sure they are that good, to report back on mail originating from machines on a ISP network. You would have so many reports from zombies, it would not be funny. I think there are other tools to monitor your network activity and the presence of Zombies on your net. 

no?

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 Nov 2008 13:43:49 -0700

On 12/11/2008 13:38, "Franck Martin" <[email-masked]> wrote:

> It seems to me that FBL are good between MTAs. I'm not sure they are that
> good, to report back on mail originating from machines on a ISP network. You
> would have so many reports from zombies, it would not be funny. I think there
> are other tools to monitor your network activity and the presence of Zombies
> on your net.

Quite a few ISPs receive feedback on their entire network, which provides
both alerting and evidence of zombies or other badness.

This has, inevitably, led (along with other things) to spammers swapping
zombies much faster than before, so obviously it's not the only thing they
should be using.  But, it still helps.

I've seen basically this same conversation happen at least a dozen times in
the past few years.  Would it make sense for the ASRG to research & describe
how FBLs are used today?

---

From: der Mouse <[email-masked]>
Date: Wed, 12 Nov 2008 15:41:29 -0500 (EST)

>>> their own user reputation systems) think something is spam, why
>>> would that ISP disagree?
>> Ummm...maybe because they know most end users don't know the
>> difference between spam and other forms of unwanted mail?
> Why should that matter?

Because spam reports and unwanted-mail reports are very different
things and call for different reactions.  If I as a mailing list admin
get something saying just "this user doesn't want this mail any
longer", a quick unsub is a perfectly reasonable reaction.  If I get
something saying "this mail is spam", a much deeper investigation is
warranted - unless I think it really means the former and is just using
the wrong term, of course.

Conflating the two - which is what reporting unwanted mail as spam, or
spam as vanilla unwanted mail, does - is bad because it means impairing
the response to at least one of the underlying situations.

> It's unwanted, and it got reported, and it's up to the ISP to decide
> what to do about that.

Yes, but it got mis-reported, reported as something it's not.  This
will, at best, waste resources.

> Maybe because they don't care if there's a difference between spam
> and other forms of unwanted mail?

Then - unless within a fairly specific and narrow context - they're
stupid, because "spam" and "unwanted mail" are categories with subset
relations in neither direction, and the appropriate responses to the
four cateogries are all fairly distinct.  (Yes, spam can be wanted;
stealth spamtraps are the first example to come to mind.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Franck Martin <[email-masked]>
Date: Thu, 13 Nov 2008 08:57:40 +1200 (ANAT)

a BCP? or an Informational RFC ? 

That would make sense.

---

From: John Levine <[email-masked]>
Date: 12 Nov 2008 20:58:16 -0000

>the past few years.  Would it make sense for the ASRG to research & describe

Sounds good to me.  Thanks for volunteering.  Would you like me to add
a page or two to the wiki to coordinate?

R's,
John

---

From: John Levine <[email-masked]>
Date: 12 Nov 2008 21:01:22 -0000

>a BCP? or an Informational RFC ? 

RFCs from RGs are Informational.  And anyway, I don't think we have
enough experience with ARF and FBLs to offer BCP advice that isn't
totally obvious yet.

R's,
John

PS: Was that enough TLAs?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Jose Celestino <[email-masked]>
Date: Wed, 12 Nov 2008 21:09:01 +0000

Words by SM [Wed, Nov 12, 2008 at 11:16:01AM -0800]:
> The pornography test is a way to avoid having to deal with the end-user's 
> definition of spam.  I'm going to give an example based on your first 
> question.  I'm subscribed to this mailing list.  Due to the high volume of 
> list traffic, I no longer want to receive the emails.  I click on a button 
> in my MUA to report the email as spam (it's unwanted).  A feedback report 
> is sent to the mailing list owner with all user identifiers removed.  
> There are ways around that but let's not get into that.  How does the 
> mailing list owner deal with the problem?
>

What problem? It seems the user is the one with a problem. There are
ways to unsubscribe as there were to subscribe.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 Nov 2008 14:22:05 -0700

> a BCP? or an Informational RFC ?

Either way, we'd need to do the research to find out what the current
practices are.

>From the conversation on this list, you'd think FBLs were an entirely new
thing with completely random usage -- but if you talk to actual ISPs, it's
an entirely different story.

---

From: John Levine <[email-masked]>
Date: 12 Nov 2008 20:58:16 -0000

R's,
John

---

From: John Levine <[email-masked]>
Date: 12 Nov 2008 21:01:22 -0000

R's,
John

---

From: Matthias Leisi <[email-masked]>
Date: Wed, 12 Nov 2008 22:57:23 +0100

> an entirely different story.

Taking a step back: FBLs need not be restricted to ISPs as recipients.
Operators of black- and whitelist are potentially interested in some
feedbacks as well.

I know that we at dnswl.org would be interested (but the whole thing is
not fully thought through yet).

-- Matthias

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 Nov 2008 15:26:06 -0700

> Operators of black- and whitelist are potentially interested in some

And you can have that, if the report generator (usually an ISP working on
behalf of their user) wants to send it to you.

---

From: Franck Martin <[email-masked]>
Date: Thu, 13 Nov 2008 11:52:33 +1200 (ANAT)

Well, if JD do volunteer, I'd like to volunteer too. 

I'm about to ramp up an MTA installation, where we will need the report from feedback loops, so I can provide my candid eye as I discover all of it. 

Cheers 

----- Original Message ----- 
From: "John Levine" <[email-masked]> 
To: [email-masked] 
Cc: [email-masked] 
Sent: Thursday, 13 November, 2008 8:58:16 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] FeedBack loops 

R's, 
John

---

From: SM <[email-masked]>
Date: Wed, 12 Nov 2008 16:11:00 -0800

At 11:40 12-11-2008, Franck Martin wrote:
>list washing if he knows who received the email and reported 
>otherwise the list owner mark as spam the report ;)

Making the report as spam makes such a feedback loop redundant.

>the practice exists, but is not recommended.

The point was that there may be scenarios where feedback loops are 
not appropriate.  That doesn't mean that feedback loops are useless.

>ways to unsubscribe as there were to subscribe.

There are different perspectives to the problem.  It doesn't really 
matter whether the user is the one with the problem.  What matters is 
whether there is a possible solution.

Expecting people to use the "spam" button will lead to incorrect 
reports.  Now, if we can get the software triggering the report to 
generate an unsubscribe request instead, the quality of the feedback 
loop will be improved.  But that would be something beyond the scope of ARF.

Regards,
-sm

---

From: Franck Martin <[email-masked]>
Date: Thu, 13 Nov 2008 11:52:33 +1200 (ANAT)

Cheers 

----- Original Message ----- 
From: "John Levine" <[email-masked]> 
To: [email-masked] 
Cc: [email-masked] 
Sent: Thursday, 13 November, 2008 8:58:16 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] FeedBack loops 

R's, 
John

---

From: John Levine <[email-masked]>
Date: 13 Nov 2008 11:19:31 -0000

>loop will be improved.  But that would be something beyond the scope

I dunno about you, but whenever I get an ARF report on a message from
a mailing list, my software treats it as an unsubscribe.  I would be
surprised if other list managers didn't do the same.

R's,
John

---

From: Daniel Feenberg <[email-masked]>
Date: Thu, 13 Nov 2008 08:01:35 -0500 (EST)

> surprised if other list managers didn't do the same.

We do the same, and ARF reports are no particular bother to us. The 
members of this list who are incensed by ARF reports are running systems 
whree they do not have the ability to remove names, i.e. they are running 
MTAs for ISPs and want ARF reports limited to those that would justify 
canceling a customer contract. These of course are non-existant if you do 
not send spam.

System administrators in general are not good at empathy, and are quick to 
condem as useless or harmful anything that is not useful to them. Hence 
the overwrought condemnations of ARF in this forum. But of course the ARF 
reports themselves are an instance of AOL not showing empathy for the the 
many receipients who cannot act on an unsubscribe request for non-spam 
messages.

In general, the ARF mechanism has become an inferior substitute for the 
List-unsubscribe header documented in RFC2369 (see also 
http://www.list-unsubscribe.com/ ) but there is no reason that both cannot 
exisit in parallel. AOL should add an "Unsubscribe" button for messages 
with List-unsubscribe headers.

Daniel Feenberg

---

From: Daniel Feenberg <[email-masked]>
Date: Thu, 13 Nov 2008 08:01:35 -0500 (EST)

Daniel Feenberg

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 13 Nov 2008 11:12:00 -0500

> That just means you aren't sending what you'd consider to be spam.

What I would "consider" it or what anyone else would "consider" it
is unimportant and irrelevant.  What's important is reality: what is it?

In this case, it's all ordinary mailing list traffic from other members of
those same mailing lists.  That is: none of it actually is spam, therefore
it is obviously an error for anyone to report it as such.  (And yes,
of course it's all COI, and yes, of course I have all those records
in hand for every subscriber, and yes, RFC 2369 headers are present,
and yes, every message footer provides an unsubscription pointer, and
so on.  As some of you know, this is not my first day on the job.)

I have considerably more analysis to do, but it appears to me at this
time that the AOL "report as spam" button has been used exclusively:

	- in error
	- as a substitute for unsubscribing
	- as a means of expressing disagreement with message content
	- as a means of expressing antipathy toward message sender

I plan to extend this analysis to other feedback loops, but I'll be
somewhat surprised if users elsewhere behave differently.

But the bottom line seems obvious to me: end users, the same people
who fall for phishes by the millions, the same people who forward around
chain letters spouting long-debunked rumors, the same people who will
click on anything shiny, the same people who will download and run
almost anything, the same people who will surrender their passwords quite
easily, the same people who will drop in CDs or plug in USB sticks
given away in parking lots, and so on, are NOT the people that anyone
should be giving a "spam/not-spam" button to.

Marcus Ranum got to the same place a long time ago, in

	The Six Dumbest Ideas in Computer Security
	http://www.ranum.com/security/computer_security/editorials/dumb/

which says in the entry listing "Educating Users" as one of those
six dumb ideas:

	On the surface of things, the idea of "Educating Users" seems
	less than dumb: education is always good. On the other hand,
	like "Penetrate and Patch" if it was going to work, it would have
	worked by now. There have been numerous interesting studies that
	indicate that a significant percentage of users will trade their
	password for a candy bar, and the Anna Kournikova worm showed us
	that nearly 1/2 of humanity will click on anything purporting
	to contain nude pictures of semi-famous females.

---Rsk

---

From: Steve Atkins <[email-masked]>
Date: Thu, 13 Nov 2008 08:21:58 -0800

> 	- as a means of expressing antipathy toward message sender

Note that three out of four of those are people telling you
that you're sending them mail they don't want to receive.

That's... well, that's as good a working definition of spam as any
from the recipient perspective.

And in the fourth case ("in error") you really need to take their
report as true, even if you're fairly sure it isn't - who are you to
tell the recipient that the mail they are telling you that they
don't want really is mail they want?

If it's the word "spam" that's causing you to waste so much
time over this issue then forget that word. Read it as "mail
the recipient doesn't want", stop sending that mail to that
recipient and move on.

It's really not rocket science, and
it's operationally fairly easy compared to some other email
related issues. (Not so easy that it's immediately obvious,
though, so a "Dick and Jane handle FBLs" document would
be nice).

Cheers,
   Steve

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 13 Nov 2008 10:53:30 -0700

> somewhat surprised if users elsewhere behave differently.

You're making that judgment based on an intentionally limited sample of
complaints.

Your sample does not reflect whether the complaints can be useful to ISPs,
or to commercial mailers -- two groups which represent the vast majority of
feedback recipients, and thus of the ARF userbase.

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 13 Nov 2008 09:07:27 -0800

On Nov 13,  8:21am, Steve Atkins wrote:
}
} If it's the word "spam" that's causing you to waste so much
} time over this issue then forget that word. Read it as "mail
} the recipient doesn't want", stop sending that mail to that
} recipient and move on.

The distinction, of course, is between mail that a specific recipient
doesn't want, and mail that may be presumed unwanted by others.

The problem is with the application of that information by the entity
generating the feedback, and whether that entity trusts user X to make
decisions on behalf of user Y.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Steve Atkins <[email-masked]>
Date: Thu, 13 Nov 2008 10:06:38 -0800

> decisions on behalf of user Y.

We're not talking about application of that information by the
entity generating the feedback, so this is irrelevant
to feedback loops.

We're talking about use by the entity receiving the feedback
(typically the sender of the mail that is being reported).

ISPs with a TiS button do use the data for things other than
feedback loops, of course, but that's a completely
different subject and really shouldn't be intermingled
with this one.

Cheers,
   Steve

---

From: Dotzero <[email-masked]>
Date: Thu, 13 Nov 2008 13:47:01 -0500

> doesn't want, and mail that may be presumed unwanted by others.

Not really, think of it as data and metadata.

> decisions on behalf of user Y.

Receivers are in many respects complaint driven. So if one user
complains about mail from a particular origin there may be no action
taken even if the origin changes nothing in their behavior. On the
other hand, if a receiver has users over a certain threshold (however
they define the threshold) complaining about mail from a particular
origin then the receiver is likely to take some action.

Use of the word "SPAM" is a red herring. If AOL changed the button to
"I don't want to receive this mail anymore" would you be happier? The
user is saying "I don't want" and the receiver is willing to pass that
message along. I agree that some users don't necessarily understand
what they are really asking for or it may be hard for the sender to
discern whether it is a particular type of email that the user doesn't
want or all mail, etc.

Bottom line, we need to get past the is it "SPAM" or is it I don't
want question.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Barry Shein <[email-masked]>
Date: Thu, 13 Nov 2008 14:43:22 -0500

How about: If it's commercial, and it hasn't been paid for by the
sender (i.e., to the ISP who might pass that along as s/he sees fit),
and the ISP declares that it should have been paid for, then it is
spam?

Period. The rest is implementation detail.

I mean, how f****** crazy have we become?

The only way to make a resource valuable is to make it scarce.

We have done quite the opposite on the spam front so encouraged its
proliferation.

Q1. But what is commercial? And how high is the sky? And what's the
meaning of summer?

A1.1 It's commercial if the ISP says it is. Don't like the definition?
POUND DIRT, find another provider, etc.

Q2. But how are you going to make this policy airtight and perfectly
impermeable because as WE ALL KNOW if just ONE message slips thru
unbilled then WE MUST LET ALL MESSAGES THROUGH FOR FREE!

A2.1 Is your whole family mentally ill, or is it just you?

A2.2 Charging for something creates an economics around its
control. So how well is the IETF paying y'all to participate in ASRG?
Oh, right, yeah I know...phew (shakes head in disbelief.) See A2.1.

Q3. But it's morally wrong to charge for commercial (i.e., any) email!
Your customers are already paying for it! What about commercial email
THEY WANT!

A3.1 I assume this is the reason your postal service delivers all your
(commercial) mail w/o charging postage? Ooops, waitaminit.

A3.1 See A2.1.

---

Put simply, anti-spam should be a process of creating a cost to
sending commercial (and, by extension, any) email: to delineating and
implementing policies, protocols, etc.

Any other goal (sub-goals aside), like how are we going to keep this
all you can eat party going and just discourage people who eat too
much (why, some fill their pockets!!!) is nutso nutso nutso.

-- 
        -Barry Shein

The World              | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Login: Nationwide
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Steve Atkins <[email-masked]>
Date: Thu, 13 Nov 2008 11:48:57 -0800

This is nothing to do with feedback loops.

---

From: Barry Shein <[email-masked]>
Date: Thu, 13 Nov 2008 14:50:14 -0500

> the ISP to decide what to do about that.

I realize you're talking abstractly but 99% or more of the AOL
feedback loop stuff we get here at The World is people who joined
completely innocuous mailing lists much like this one and decide one
day they don't want to be on it any more so just pound the SPAM button
in response to every new list message they get until somebody (here)
takes them off. It's easy, it works.

The other 1% mostly completely inexplicable, probably accidents, like
"we'll be at Mom's around 3PM, is Becky coming?" (from/to people with
the same last name), SPAM!

-- 
        -Barry Shein

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 12:16:49 -0800

Actually the underlying intellectual conceit of market fundamentalism is that the market is a perfectly tuned feedback loop.
 
The are a huge number of problems with that view. Not least the fact that like any other ideology, market fundamentalism is too simple to be a univeral solution to every problem and the fact that as with marxism and any other ideology that is tried in practice, the proponents are certain to carve out exceptions whenever the ideology does not meet their a-priori goals.
 
But on a strict level of control theory, the existence of a feedback loop does not imply effective control. There is the question of gain and the rather more subtle issue of timing. Poorly tuned control loops can make the problem worse.

In this case the value to me of sending this email to this list is rather less than the value a spammer would obtain through successful spamming. The value to me of sending this message is almost certainly negative: if I had to pay to send it I would almost certainly occupy my time more profitably doing something else. Ergo there is no price regime that has the desired outcome.

and then there is the fact that in the fifteen plus years I have been looking at micropayments, nobody has proposed a scheme that looks remotely viable to me as a solution in this instance.
 
We do not need to charge for inappropriate use of email, we only need to penalize inappropriate use.

________________________________

From: [email-masked] on behalf of Steve Atkins
Sent: Thu 11/13/2008 2:48 PM
To: Anti-Spam Research Group - IRTF
Subject: [Asrg] Email Postage (was Re: FeedBack loops)

On Nov 13, 2008, at 11:43 AM, Barry Shein wrote:

> The World              | [email-masked]           | http://www.TheWorld.com <http://www.theworld.com/>

---

From: Barry Shein <[email-masked]>
Date: Thu, 13 Nov 2008 16:02:03 -0500

> Actually the underlying intellectual conceit of market fundamentalism is that the market is a perfectly tuned feedback loop.

No one said anything about "market fundamentalism". Charging zero is
not communism, and charging something is not unbridled capitalism.

 > In this case the value to me of sending this email to this list is rather less than the value a spammer would obtain through successful spamming. The value to me of sending this message is almost…

Ergo shmergo, that presumes a particular pricing regimen, set up the
straw men and knock 'em down.

It is not uncommon for spammers to send 1 billion msgs / day.

Presumably that's somewhere in the range they need to be successful
(by their own measure.)

So if I limited you to 1 million messages per day (for free, after
that you pay) perhaps you could operate as you do now but the spammers
would be out of business.

Or maybe 1,000 msgs/day, etc.

Ergo, you're talking nonsense.

 > and then there is the fact that in the fifteen plus years I have been looking at micropayments, nobody has proposed a scheme that looks remotely viable to me as a solution in this instance.

More straw men. Nobody mentioned micropayments.

Your sentence can be reduced to: No postal system or non-free
telephone system (etc.) can possibly work, it would require
micropayments and I am certain no such scheme is viable.

Ergo, failure to understand reality is not reality's fault.

 > We do not need to charge for inappropriate use of email, we only need to penalize inappropriate use.

And thus is borne the underlying police-state impulses of uncharged
schemes. Since it's all free the only way to control its use is to
hang overconsumers in the town square.

No, I say there is a compromise. Reasonable, personal usage can be
"free" (i.e., disappears into other charges), commercial, bulk usage
can be charged.

The problem is we've drunk the kool-aid (fitting, jonestown 30th
anniversary is November 18th) and have come to adopt an assumption
that there is "good" commercial bulk email and "bad" commercial bulk
email.

Again, look at your postal system, they have a notion of commercial
mail, do they deliver commercial mail the recipient wants for free?

It's really not that hard.

-- 
        -Barry Shein

---

From: Seth <[email-masked]>
Date: Thu, 13 Nov 2008 16:41:17 -0500 (EST)

> Or maybe 1,000 msgs/day, etc.

How do you know who "I" am?

Limit a spammer to 1000 messages/day, and he'll just steal 1 million
"identities" and send his billion spams.  He does it through tens of
millions of hijacked zombies now, anyway.

So, tell me _how_ you plan to limit everybody to 1,000 (free) messages
per day.

Seth

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 13 Nov 2008 16:54:18 -0500

> that you're sending them mail they don't want to receive.

Maybe.  But how am I supposed to read their minds and figure out which of
those possibilities (or other ones that didn't occur to me) are in play?
All I can know for sure is that they have pushed a button labeled
"report as spam" in reference to a message that is not spam.  Everything
beyond that is guesswork.

So maybe you're right.  Maybe they don't want to be on that particular
mailing list any more, or maybe they don't want any more mail on that
particular topic, or maybe they don't want any more mail from that
particular fellow list-member, or maybe something else entirely...
but there's no way for me to know which.  (Well, unless I ask them and
they answer, and given the volumes involved, that's not very practical.)

So maybe you're not right.  Given the facts-in-hand, how am I to tell?

I have, by the way, in the case of *some* lists, tried the approach
of removing those reporting ordinary list traffic as spam.  One of the
things I've noticed is that a significant percentage re-subscribe,
then subsequently report more ordinary list traffic as spam.  I've even
noticed a handful of people reporting *their own messages to a list* as spam.

Let me see if I can put this in a larger context.  Feedback loops
are often used as (partial) input to operational SMTP policies.
Those policies, along with HTTP and FTP and SSH and DNS and other
policies, are all part of a bundle I consider "site security policy".
I don't think it's a good idea to hand users a knob that controls
any part of that.

---Rsk

---

From: Barry Shein <[email-masked]>
Date: Thu, 13 Nov 2008 17:17:45 -0500

> So, tell me _how_ you plan to limit everybody to 1,000 (free) messages

The tone of hopelessness and despair is noted.

The plan is to create an economy around bulk commercial messaging, all
bulk commercial messaging.

Then we won't have to rely on free volunteers stealing a few minutes
here and there at work to solve this complex, global problem by
repeating the same tired, defeatist remarks over and over thinking
they've added something.

Perhaps as an exercise we should take a month, stop all spam-related
topics, and discuss how the global postal system or telephone system
should work. Because it seems to me that there is little ability here
to even converge on existing realities, let alone propose new
regimens.

By that I mean people here regularly "stand up" and disprove to a
great degree of certainty that, e.g., cell phone systems (as they
exist) cannot possibly be made to work, postage sytems, telephone
systems in general, etc. etc. and in their mind declare the matter
thus closed.

It's really rather remarkable, like watching a bunch of self-declared
physicists prove beyond a reasonable doubt (to themselves) that
bumblebees cannot possibly fly* simply because the conclusion
satisfies the constraints they wish to impose on the result.

Of course here the process is transparently simple: No email charges
may exist, always work backwards from that desired conclusion.

* http://www.straightdope.com/columns/read/1076/is-it-aerodynamically-impossible-for-bumblebees-to-fly

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Thu, 13 Nov 2008 17:27:45 -0500

> they answer, and given the volumes involved, that's not very practical.)

Ask 1% of them and report back? Or whatever sample size would seem
statistically significant? It needn't be very large.

 > then subsequently report more ordinary list traffic as spam.

They're going on vacation, or overwhelmed for a while. The SPAM button
has become the list membership management / nomail button. It works!

  I've even
 > noticed a handful of people reporting *their own messages to a list* as spam.

Accidents happen. Some of those accidents are the meat between the
keyboard and the chair. I have no doubt occasionally someone gets
frustrated with the volume or character of their email and just fire
thru their inbox holding down the spam button (assuming it
auto-repeats, but whatever.)

The first error in any observation about large groups of people is to
assume most of them will act rationally and in their own
interest. Even the dismal science (economics) has gave up on that a
long time ago.

 > I don't think it's a good idea to hand users a knob that controls

How about this:

They're mostly something dreamed up by marketing departments working
in concert with engineers to make the end-user think something is
being done about spam but at about zero cost to the organization.

The idea probably started with "hey, you know how hospitals have had
great success with giving people their own pain meds button? How
studies have shown they actually use *less* pain meds when they feel
in control and are generally happier about their pain control? How
about a SPAM button?"

-- 
        -Barry Shein

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 14:35:28 -0800

And in which universe is this type of rhetoric an effective means of attracting support?
 
The IETF is not an ideological political movement, nor is it a religious cult. The talk radio approach is not so effective here.
 
My postal mail is 90% junk and the rest almost invariably shows evidence of an attempt by a postal worker to open it, presumably in the hope of finding something worth stealing. I don't think the postal system will be around for very long.
 
In practice the 'telephone system' is being dismantled as we speak. Most of the actual data transport is VOIP these days. I have three lines into the house, all VOIP. Over the next few decades the 'telephone system' will continue to reduce in size and scope until all that is left is the SS7 system as a vestigial appendix on the Internet.

From: [email-masked] on behalf of Barry Shein
Sent: Thu 11/13/2008 5:17 PM
To: Anti-Spam Research Group - IRTF
Subject: Re: [Asrg] Email Postage (was Re: FeedBack loops)

* http://www.straightdope.com/columns/read/1076/is-it-aerodynamically-impossible-for-bumHmm, blebees-to-fly

--
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Thu, 13 Nov 2008 18:12:21 -0500

> The IETF is not an ideological political movement, nor is it a religious cult. The talk radio approach is not so effective here.

Of course it is, just look at the heated dogma thrown back when
someone suggests developing a methodology for charging for bulk
commercial email. You'd think I'd stood up and interrupted the service
to ask if the congregation could please discuss atheism for a bit.

 > My postal mail is 90% junk and the rest almost invariably shows
 > evidence of an attempt by a postal worker to open it, presumably in
 > the hope of finding something worth stealing. I don't think the
 > postal system will be around for very long.

So therefore postal systems don't work?

This shouldn't even qualify as anecdotal evidence, it's too laden with
polemic.

You...don't...think? Gosh.

 > In practice the 'telephone system' is being dismantled as we
 > speak. Most of the actual data transport is VOIP these days. I have
 > three lines into the house, all VOIP. Over the next few decades the
 > 'telephone system' will continue to reduce in size and scope until
 > all that is left is the SS7 system as a vestigial appendix on the
 > Internet.

Look, the assertion being addressed was that it's impossible, simply
impossible, to charge per use.

Whether you find it *attractive* or the wave of the future is
irrelevant.

But clearly it's not *impossible*.

Second, no one was suggesting (necessarily) any such system, certainly
not me.

I was suggesting charging bulk commercial senders.

Even the dumb postal systems have figured this one out.

I realize every one of you knows this but it immediately flies out of
one's head when one wants to ridicule an idea and the image is put
forward that Publisher's Clearing House has Ed McMahon in the basement
licking 100 million first-class stamps one by one...

Nah, zip-sorting, postage meters, pre-printed, pre-paid "envelopes",
ya know, stuff that scales and has been proven to scale. That is, it
has been used in real life on a huge scale, daily, for decades,
regardless of proofs here that bumblebees cannot fly and urgings to
close the matter once and for all.

C'mon, can we exit the realm of cheesy rhetoric and try to speak to
each other like, well, at least to the level of beings sentient enough
to have gotten this far without suffering a fatal keyboard injury?

You don't like the postal system...so therefore it can't
work...sheesh, wouldja listen to yourself?

I'll counter with: Print up 100,000 ads for whatever you do for a
living and try to get the post office to send them for free. Be sure
to either disguise the sender or convince the postmaster-general the
recipients really/really/really want your flyer. Tell us how it works
out.

The...post office...can't...possibly...work...wow.

-- 
        -Barry Shein

---

From: Seth <[email-masked]>
Date: Thu, 13 Nov 2008 18:17:21 -0500 (EST)

> impossible, to charge per use.

It's clearly not impossible.  It's been done.

It was about as successful as sheep flying.

> I was suggesting charging bulk commercial senders.

Who charges them?  Who enforces the charges?  Who collects?

> Even the dumb postal systems have figured this one out.

They charge for *services they provide*.  So do Internet providers.
You want to change their billing model?  If yours is better, you'll
compete them into the ground.  Go for it.

Seth

---

From: David Wall <[email-masked]>
Date: Thu, 13 Nov 2008 15:26:58 -0800

> Who charges them?  Who enforces the charges?  Who collects?

I propose that you send the payments to me.
> compete them into the ground.  Go for it.
Well, you'll need to beat most ISPs for it to work since the spammers 
will use those that don't, and half the world will be sending using the 
other, so unless your email system is happy to reach only half of the 
worldwide users, you'll be a winner. 

Besides, we can't even get everyone to buy into IPv6, DNS-SEC, 
SenderID/SPF, DomainKeys...and nobody is even proposing you charge us to 
use them.  Any change that affects every email server in the world is 
probably "hard" no matter how much you grumble that you have a 
solution.  If you have a solution, you will be rich, so make yourself 
and your investors rich.

David

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 13 Nov 2008 19:34:58 -0800

On Nov 13,  5:17pm, Barry Shein wrote:
}
} Perhaps as an exercise we should take a month, stop all spam-related
} topics, and discuss how the global postal system or telephone system
} should work.

I would be interested to have you expand upon your analogy to the
postal and telephone systems.  In particular, both of these came
into existence as monopolies, and it has only been a relatively
recent development (as compared to the long history of the postal
and telephone services) that there is a competitive economy in
either market.

In both cases there was a high initial barrier to entry, and for the
postal system the need to transport tangible objects remains one.

What mechanism do you propose that would either establish similar
barriers for Internet transactions, or bring a similar economy into
existence even though such barriers do not exist?  Who becomes the
regional monopoly with the power to set prices and refuse service
to those who don't pay?

There used to be such a barrier to joining the Internet.  One had to
have at least one willing peer, and one had to pay for the dedicated
data connection to one's peers, and the peers had to agree on the
traffic they'd carry.  Seems to me that was the period during which
a different decision could have been made, to make the entire system
closed to those who didn't pay the "postage" for the data that they
emitted, whatever that data might be.  Is it really not too late?
If not, is it really a net benefit to go back?  (Yes, pun intended.)

Certainly one could establish a new monopoly, and some people might
even pay to use it because of its exclusivity.  (I seem to recall some
startups attempting exactly that in the last few years, but I don't
know what happened to them.)  Is there a passenger railway system
anywhere in the world that survives without government subsidy?  Is it
in a region where people have private cars and access to cheap fuel
and good roads and parking?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 12:06:04 +0000

--On 12 November 2008 11:16:01 -0800 SM <[email-masked]> wrote:

>> If a statistically valid sample of an ISP's users (as processed by their
>> own user reputation systems) think something is spam, why would that ISP
>> disagree?
>
>> attitude, particularly the pornography test (I know it when I see it.)
>> But, it's a shift that all of the big ISPs have already made: they'll
>> listen to their users before they'll listen to random external parties.
>
> question.  I'm subscribed to this mailing list.  Due to the high volume
> of list traffic, I no longer want to receive the emails.  I click on a
> button in my MUA to report the email as spam (it's unwanted).  A feedback
> report is sent to the mailing list owner with all user identifiers
> removed.  There are ways around that but let's not get into that.  How
> does the mailing list owner deal with the problem?

Some email service providers offer one-click spam reporting, with a 
mechanism that the user only has to learn once.

List owners need to make it as easy to unsubscribe as to report the spam, 
or at least try to make it as easy as possible.

For example, a prominent one-click unsubscribe link that isn't hidden in 
the message headers.

List-Unsubscribe: headers will only be helpful when the major email 
clients, and major webmail providers expose them in their interfaces. And 
the the address in the header should encode the subscribed email address, 
so that it can be used even after the message has been forwarded to another 
address.

It's a legal requirement in the UK that unsolicited marketing messages 
(which here include messages promoting the aims of non-profit 
organisations, perhaps including ASRG) should include a simple method of 
unsubscribing. I'd argue that this list doesn't, even though an address is 
provided in the footer, it isn't described as an unsubscription address.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 12:18:39 +0000

--On 13 November 2008 08:01:35 -0500 Daniel Feenberg <[email-masked]> 
wrote:

> http://www.list-unsubscribe.com/ ) but there is no reason that both
> cannot exisit in parallel. AOL should add an "Unsubscribe" button for
> messages with List-unsubscribe headers.

That, or just use the unsubscribe mechanism when the user hits the spam 
button.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 12:18:39 +0000

---

From: John Levine <[email-masked]>
Date: 14 Nov 2008 10:29:17 -0000

> The IETF is not an ideological political movement, nor is it a
> religious cult.

How can you say that with a straight face after this week's DNSBL food fight?

R's from Cambridge,
John

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 12:35:49 +0000

> ways to unsubscribe as there were to subscribe.

The list owner has a problem if the list is persitently being reported and 
then filtered as spam, and therefore other list members are not receiving 
messages.

---

From: John Levine <[email-masked]>
Date: 14 Nov 2008 12:42:20 -0000

>From what I've seen, feedback loops are mostly useful in two situations:

- ESPs and others who send a lot of list mail, to catch both people who
subscribed and changed their minds, or for an ESP, lists that are not
what the customer claimed they were

- ISPs and others with large farms of PCs, to identify zombies and
misbehaving customers

If you run a well behaved network, most of the FBL reports will be
wrong.  Think of it as having a relatively constant level of noise,
and if your spam signal is low, all you'll see is the noise.  This
doesn't mean they're useless, it means you're not who they were
designed for.

>noticed a handful of people reporting *their own messages to a list* as spam.

Sure.  So?  Serves them right.

R's,
John

---

From: John Levine <[email-masked]>
Date: 14 Nov 2008 12:42:20 -0000

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 14 Nov 2008 06:14:02 -0800

At 04:06 14-11-2008, Ian Eiloart wrote:
>List owners need to make it as easy to unsubscribe as to report the 
>spam, or at least try to make it as easy as possible.

Some list owners already do.

>For example, a prominent one-click unsubscribe link that isn't 
>hidden in the message headers.

It's not hidden in the message headers; the problem is that it's not 
accessible in some MUAs.  As a comparison, the "From:" or the 
"Subject:" are part of the message headers.  Most MUAs allow you to 
access that information.

>It's a legal requirement in the UK that unsolicited marketing 
>messages (which here include messages promoting the aims of 
>non-profit organisations, perhaps including ASRG) should include a 
>simple method of unsubscribing. I'd argue that this list doesn't, 
>even though an address is provided in the footer, it isn't described 
>as an unsubscription address.

This message has a List-Unsubscribe header.  The use of that header 
is documented.  I'd say that this list does provide a means to 
unsubscribe.  I agree that the footer cannot be described as an 
unsubscription address.

Regards,
-sm

---

From: mathew <[email-masked]>
Date: Fri, 14 Nov 2008 09:50:27 -0600

On Nov 13, 2008, at 17:26, David Wall wrote:
> Well, you'll need to beat most ISPs for it to work since the  
> spammers will use those that don't, and half the world will be  
> sending using the other, so unless your email system is happy to  
> reach only half of the worldwide users, you'll be a winner.

Facebook's e-mail system can only reach other people who have signed  
up for Facebook, and who you've mutually identified as a friend. Yet  
surveys suggest (*) that amongst younger people, Facebook and other  
social networking sites have completely usurped the purpose of e-mail,  
and that young people perceive e-mail as something that old people use.

But clearly this is impossible, so it cannot have happened.

The spammers are trying to work on cracking Facebook, of course.

mathew
[ (*) Sorry, don't have free references to hand. ]

---

From: mathew <[email-masked]>
Date: Fri, 14 Nov 2008 10:02:48 -0600

> and telephone services) that there is a competitive economy in

That may be true in the US, but it was not true in the UK, where  
postage was invented. The Office of the Master of the Posts was around  
for over a century before monopoly of service was granted.

It also took about that long to work out that charging the sender was  
a good idea, so perhaps the Internet will be ready for the concept  
around 2100 CE.

> regional monopoly with the power to set prices and refuse service

I propose attention bonds. Under such a scheme, no monopoly is  
required to set prices or refuse service.

mathew

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 14 Nov 2008 16:31:40 +0000

--On 14 November 2008 06:14:02 -0800 SM <[email-masked]> wrote:

> This message has a List-Unsubscribe header.  The use of that header is
> documented.  I'd say that this list does provide a means to unsubscribe.
> I agree that the footer cannot be described as an unsubscription address.

Well, the question is how you define the word "simple". It isn't there by 
accident. The word "should" is an error. It's a requirement, so I should 
have said "must".

For users of this list, we'd hope that you're correct. The mechanism may be 
simple enough, and there's the link to the web page in the footer.

For users of any list that is NOT for people with an expertise in email, 
you'd have to provide a mechanism that an ordinary person found simple. By 
analogy, as easy to use as the brake pedal in a car.

I'd argue that the message header is not a simple mechanism, because most 
email clients don't expose it. I also think that the link to 
<https://www.irtf.org/mailman/listinfo/asrg> would not qualify because:
(a) my browser tells me that the web page is not secure (the security 
certificate isn't valid for the host name)
(b) the unsubscribe section is at the foot of the page
(c) I have to remember which address I subscribed with
(c) I have to wait for a confirmation message to complete the 
unsubscription.

The exact wording of the requirement is at paragraph 22.(3)(c) of the UK's 
Privacy and Electronic Communications (EC Directive) Regulations 2003:

(c) the recipient has been given a SIMPLE MEANS OF REFUSING (free of charge 
except for the costs of the transmission of the refusal) the use of his 
contact details for the purposes of such direct marketing, at the time that 
the details were initially collected, and, where he did not initially 
refuse the use of the details, AT THE TIME OF EACH SUBSEQUENT COMMUNICATION.

<http://www.opsi.gov.uk/si/si2003/20032426.htm>

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 14 Nov 2008 12:20:40 -0500

On Fri, Nov 14, 2008 at 04:31:40PM +0000, Ian Eiloart wrote:
> email clients don't expose it.

I have to agree with you, reluctantly, that this is currently true.

But I think we have a relatively easy answer to this sub-problem:
encourage email client authors to do exactly that.  This in turn,
may encourage more mailing list operators to support these headers.

---Rsk

---

From: Barry Shein <[email-masked]>
Date: Fri, 14 Nov 2008 14:40:48 -0500

On November 13, 2008 at 19:34 [email-masked] (Bart Schaefer) wrote:
 > into existence as monopolies,

Phone service was offered to the general public around 1878. AT&T
started to become considered a monopoly in 1907, 30 years later. The
monopoly was broken up effective 1/1/1984.

Anyhow, it's not really relevant to the original question which was
whether or not so-called "micropayment" systems are possible. Clearly
they are possible, as exemplified by phone systems (both landline and
wireless), SMS billing, postal systems, what have you.

And, further, that's not even what was being proposed. Saying that
commercial bulk e-mailers should pay does not imply micropayments at
all.

It's just the favorite red herring to toss out: That would require
micropayments, micropayments are impossible, THEREFORE any system
which attempts to cause bulk emailers to pay is impossible, THEREFORE
STFU. QED. (preferably all said in one breath.)

But as I pointed out in a previous message even postal systems (rather
archaic entities) don't actually require bulk senders to lick each
stamp.

(Well, postal systems did tend to be created by governments as
monopolies of a sort. For example, their existence didn't preclude all
sorts of other courier services from Wells Fargo (founded 1852) to
Fedex (in the US), so it was usually a monopoly on a very narrowly
defined set of services.)

 > and it has only been a relatively

(I've lost what "it" is in this sentence)

 > regional monopoly with the power to set prices and refuse service

No one has proposed a monopoly, so this is a straw man.

 > traffic they'd carry.

It would be useful if you were more specific about what years or era
you're talking about.

Since I was there and active back when, the ARPAnet days...a peer
needn't be willing, only able. It wasn't even their equipment so this
doesn't make a lot of sense.

To get a connection DARPA allocated a port on an IMP to you. Which
port would even become your primary IP address.

For example at BU when I hooked them up we were 10.4.0.44 which meant
port 4 on imp 44 (10.* was the ARPAnet, the zero was silent) which was
in the 9th floor machine room at 545 Tech Square (MIT LCS), the box
was white and about a 5U and hooked to a BBN IMP.

DARPA paid for it all. With some very narrow and later exceptions
(e.g., CSNET/X.25) you couldn't buy anything, you either were approved
for a "free" (to the organization) connection, or you didn't get one
at all.

That was what changed when Gore et al moved it all to NSF creating the
NSFnet. At that point you could buy your way in if you were a
recognized bona-fide research and/or educational institution by NSF's
rules. And along with "buy" came a big budget to pay for hookups for
poor cousins (e.g., small private colleges etc.) since the roughly
$100K per hookup cost could be daunting to some of them.

Then, ca 1989, all hell broke loose.

  Seems to me that was the period during which
 > If not, is it really a net benefit to go back?  (Yes, pun intended.)

I think you're making this overly global.

 > and good roads and parking?

Such a system for charging bulk emailers could be made quite simple,
the devil is of course in the detail.

You create a header.

In that header is a cryptographically secure string which is the
postage which was purchased from a recognized issuance party. Think,
as an analogy, SSL certificates.

A site could choose to accept or reject such "stamped" email.

Monies collected for such postage could be divided up, I won't belabor
this detail.

Some rules exist to acquire such postage for non-commercial sites,
end-users, etc., probably amounting to about free.

Anyhow, obviously the entire idea would comprise many pages of details
but I hope that outlines an overview of a plausible system which
doesn't require micropayments, monopolies, or all the other straw man
nonsense which gets thrown at the stage like rotten tomatoes when the
idea comes up.

-- 
        -Barry Shein

---

From: David Wall <[email-masked]>
Date: Fri, 14 Nov 2008 14:04:59 -0800

> the devil is of course in the detail.
And in its implementation...
> as an analogy, SSL certificates.
I'm thinking SSL certs, yet even today, few email servers use SSL to 
protect email communications because most do not care to pay extra, and 
those that do typically use self-signed certs that keep the data 
encrypted, if not sanctioned by a CA.  Apparently CAs no longer even 
claim anything because you need to be an "extended verification" cert to 
do what a regular cert used to offer -- that they checked your ID before 
issuing you one.  Besides, an SSL cert is non-transactional unlike 
postage.  Furthermore, much spam, as has been pointed out numerous times 
before, is sent by hijacked user computers, so the original spammer is 
not actually sending the email and thus would not be paying.
> A site could choose to accept or reject such "stamped" email.
And those that chose to reject would receive no email from 99.999% of 
the people out there.
> Monies collected for such postage could be divided up, I won't belabor
Please don't, since this would be very hard.  Give an example where such 
a scheme exists outside of your proposal.  Your phone and postal mail 
examples certainly do not.
> end-users, etc., probably amounting to about free.
"Some rules" eh?  We just have to agree on those rules, right?  That 
shouldn't pose any difficulties....
> nonsense which gets thrown at the stage like rotten tomatoes when the
The difficultly is nobody likes spam, but nobody wants to pay to send an 
email beyond what they already pay for Internet service.  Pay per use 
for anything trivial (like email) tends to disappear into flat 
subscriptions, which is what ISPs do now when they charge us for 
access.  And this mailing list would die if we had to pay to send.

My company offers a secure web email platform in which zero spam and 
zero viruses are sent as all users are authenticated to send and receive 
-- which by itself doesn't preclude these things, but reputation does 
when you can prove such abuse came from you and you can be turned off 
immediately from future use.  Furthermore, large files can be sent 
without size limitations imposed by many email systems.  All data is 
encrypted on disk and when in transit.  Electronic signatures can be 
applied.  Timestamps are accurate, no email headers to spoof, guaranteed 
return receipts and tracking, etc.  We have thousands of paying 
customers and hundreds of thousands of users (only senders pay -- and 
they pay subscriptions, not per use).  But this is a drop in the bucket 
compared to the massively distributed email system and its users.  Why?  
Because there are some business communications situations that really 
need our service and they are willing to pay for those benefits, but 
most people would not pay when regular email with all its warts, viruses 
and scams is free.  So while we're totally for making regular email 
expensive so our product is more universally attractive, it's just not 
likely going to happen. 

There are too many email users, too many email servers and too many 
email clients around the world to coordinate for a such a new standard.  
It would require world-wide government cooperation and mandates -- and 
if you're holding your breath for that, good luck to you.  It's not a 
technical issue.  Just because you can devise a scheme won't make it 
happen.  And if you can make it happen, do so and become filthy rich 
rather than complaining we all don't get it.  Just do it!

David

---

From: Barry Shein <[email-masked]>
Date: Fri, 14 Nov 2008 18:25:53 -0500

> And in its implementation...

Well, I could post my observations in C or Perl if you prefer. There
is something to be said for that ("running code!") but this is a
research group.

 > > A site could choose to accept or reject such "stamped" email.

First, if you wish to accept spam and other commercial email then feel
free to ignore all this jazz, just like you can with ssl info.

Second, like ssl one would hope that any sort of valid cryptographic
verification would include identifying the permitted sending hosts for
that cryptogram (i.e., ssl certs are tied to a host or site.)

That is, you couldn't (at least in theory) generate your own postage
and have it accepted as valid by anyone interested. You're right that
if the recipient hasn't any interest there's little one can do but so
what?

And you couldn't send mail with a "valid" postage cryptogram from just
any computer (e.g., a hijacked PC), SSL certs have that intent also.

I know you could have thought all that through for yourself but you're
just resisting the idea, no?

 > And those that chose to reject would receive no email from 99.999% of 

That would be a bad implementation, yes.

 > Please don't, since this would be very hard.

Giving away money is hard???

  Give an example where such 
 > examples certainly do not.

It's a new medium, we're inventing some things.

Anyhow, an example? How about click-thru advertising a la google?

 > shouldn't pose any difficulties....

No more so than, e.g., SSL certificates or click-thru advertising (or
SMTP for that matter.)

You want to play, fine, here's how it's done...(RFCs etc.)

You don't? Fine! Accept what you like by your own algorithms, or
accept everything, write your own mail system, etc. none of my
business.

Anyhow, isn't that why we're all here? To try to design some rules we
all may play by in a consistent manner?

You're just resisting, right?

 > access.  And this mailing list would die if we had to pay to send.

I guess no matter how many times I explain this each person gets to
come to the plate and bat out the same straw men...

THIS INVOLVES BULK COMMERCIAL EMAIL.

There is absolutely no reason why you would pay anything.

Real commercial emailers might send out millions of emails per day or
month anyhow.

I get some sort of boring come-on from Amazon almost every day because
I once bought a book from them. Why should they be able to do that for
free? They must be sending out tens of millions of these per day,
maybe more.

They can't ship me a book for free, even if I have a prior business
relationship with them. Even if I asked for the book and paid for it,
they still have to pay (well, charge, cause the shipper to be paid)
for shipping.

Spammers by many accounts approach A BILLION messages per day!

Now, where would you say your usage, or even the usage of a list like
this, fits in to that picture?

Almost indistinguishable from zero.

So, without trying to detail to the last bit of minutiae doesn't that
seem to lead towards a system which might charge large bulk emailers
while preserving the current status quo for most others?

Say it gave you, YOU, don't go running for other hypothetical
examples, 100,000 free messages per day for non-commercial use. Would
that cover it? Would it work for amazon or some spammer?

Even for someone like the IETF...they buy SSL certificates, no? I
assume SSL certs cost IETF thousands of dollars a year. That's ok.

So let's say umbrella "postage" was available to a non-profit, say
100M msgs a month for $500/year? Would that break the bank?

Or they could send w/o postage and people who wanted to receive their
stuff could put an exception rule in their checker if they have a
checker:

    if(from(IETF)) then acceptWithoutPostage().

(whatever "from(IETF)" means, SPF, DKIM, etc.)

Similar for end-user ISPs, non-commercial usage postage license, 1B
msgs/month, $1,000/year. It'd be in the noise, mainly a processing
fee. And they would do well to pass on to their customers the idea
that if any are doing bulk commercial emailing they will need their
own license. Etc.

 > expensive so our product is more universally attractive, it's just not 

Ok, straw man, right?

 > email clients around the world to coordinate for a such a new standard.  

Then I guess we better disband the entire IETF on that basis! Why
doesn't this reasoning apply to everything that goes on here?

 > rather than complaining we all don't get it.  Just do it!

Hey look, I'm not complaining, I'm injecting some ideas.

You're the one whining about them, and mostly nonsensically I may add.

Have you ever considered re-reading your own posts with a little
self-criticism? A skeptical eye? Imagining how someone who doesn't
agree with you 100% a priori might read them?

Then maybe you would spare us nonsensical comments like "there are too
many email users, too many mail servers, too many email clients around
the world to coordinate for such a new standard." on a STANDARDS GROUP
(well, research for standards group) mailing list!

Sheesh. Just listen to yourself, have you no shame?

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 15 Nov 2008 00:36:51 -0000

>required to set prices or refuse service.

Ooh, there's a bad idea I haven't seen for a while.

It's patented, you know, although the guy who owns the patent gave up
on trying to commercialize it and now runs yet another less than
fabulous C/R antispam service.

R's,
John

---

From: John Levine <[email-masked]>
Date: 15 Nov 2008 00:45:54 -0000

>Monies collected for such postage could be divided up, I won't belabor

Gee, you stop just when you're getting to the insoluble problems.

Look, we know how to build small closed e-mail systems that charge per
message.  MCI Mail did OK for a while until the Internet made it
irrelevant.  What we don't know is how to scale it up to anything like
the size of the Internet mail system, nor how to do settlements among
the huge numbers of mail systems that exist.

To pick an obvious and well-known hard problem, how do you plan to
prevent double spending of your stamps, and make your solution scale
up to an interestingly large amount of mail?  I know you think I'm
just being defeatist, but handwaving has never been much of a
substitute for engineering, and the engineering problems in metering
large volumes of anything are hard.

Spam is particularly hard, since no payment system I know of, micro or
otherwise, has been designed for an environment where 95% of the
putative payments are bogus.

R's,
John

---

From: John Levine <[email-masked]>
Date: 15 Nov 2008 00:36:51 -0000

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Fri, 14 Nov 2008 20:46:21 -0500

You asked, right?

 > Gee, you stop just when you're getting to the insoluble problems.

Well, we're all getting zero now to receive bulk commercial email.

I suppose one's sense of justice makes zero better than a system where
one is getting something, but something perceived as not perfectly
fair. The human mind is like that.

But the obvious attack would be you "send back" the stamps you
accepted and you get so much per stamp, money which came out of what
was paid for those "stamps". With luck and perserverance you could get
a nice two-slice toaster.

Actually I don't see this as being something which goes to end-users
directly, that would increase overhead significantly.

That wouldn't prevent an ISP for example crediting against your
account charges, or everyone's account charges, or turning it into
pennies and dumping it into the nearest salvation army bucket if they
like. That's really just marketing when you get down to it.

Probably the best way to express that is that a "license" to collect
and redeem such "stamps" might reasonably have some base cost which'd
probably be prohibitive for individuals (have you looked at what ICANN
charges for a new TLD? It's like $500,000 to start the process, all
tolled.)

But, really, this is far more detail than would need to be proscribed
in a proposal. How it might work is engineering, what it might cost
is, well, not engineering.

 > the huge numbers of mail systems that exist.

I don't propose charging per message.

I don't propose charging per message.

I don't propose...how many times do I have to say this?

Well, at least not in the way it is being described. MCI Mail REALLY
charged per message.

I'm saying that (how simply can I put this) someone like an Amazon or
JoeSpammer would have to buy cryptographic stamps for each message
they want to send out. Or, more likely, a range and they have the
software to generate the "stamps" within that range.

The recipient, at any level, some ISPs or other orgs might do this,
some might pass it entirely to the end-user, can choose to check the
validity of those "stamps", or not. If it is valid they can also
accept the message (they can accept invalid ones also if they like but
they'll never get paid for that)...

Ya know, let's make this simpler, it's a lot like click-thru
advertising in some ways. Someone has to accept/click, somehow these
have to be accounted for and that accounting is used in a charging
scheme.

Anyhow, anyone (in my imaginings) could send out email w/o any
"postage" (free or otherwise) at all, they'd just be at the mercy of
the ISP or recipient or company or university, whatever, to accept it
or not w/o postage, kinda like choosing to accept a site w/ a
self-signed certificate.

 > large volumes of anything are hard.

I don't think you're being defeatist, just resistant and asking
questions you could answer for yourself.

Like here's an easy scenario:

At the point something like this was implemented there's now money on
the table.

If you double-spend (and get caught), YOU GO TO JAIL!

To "spend" at all you need some sort of license, it leads right back
to you or else no one would accept your messages, right?

I mean, what stops iTunes from double-spending, from only counting
every other mp3 (whatever) downloaded in reports to the record
companies? They'd go to jail (a collective term for lose their
franchise, get sued, etc etc etc.)

But there are ecurrency methods which can make this non-trivial. And
there's a reputation system inherent. Now that it's cryptographically
signed you know who it is and if someone is a crook it's a lot easier
to discard their mail w/o reading.

For example, would you really expect, e.g., Amazon to maliciously
(accidents can happen) double-spend in such a system? Nah. So we get
back to blacklists and all that if you care. But at least you're doing
the first-line filtering right at your site (whether MTA or MUA is a
policy matter.)

The real point is tho that once you have an economy, just like with
music, once someone is relying on it for income and fair play, then
they can do all sorts of things like sampling, offer rewards
(cut+paste stamps you get into our site [so we can check for dupes]
and win prizes!), whatever.

 > putative payments are bogus.

Spam is particularly hard because nobody has much motivation to spend
much money (and all it buys) enforcing anti-spam behavior.

Hey, I've heard it first hand, yelled at me by a three-letter
government agency rep: EMAIL IS AN OPEN SYSTEM, ANYONE CAN INJECT
ANYTHING FOR FREE, UNLESS IT'S INHERENTLY ILLEGAL (e.g., child porn)
WE HAVE NO INTEREST IN ENFORCING THE FAIR USAGE OF SOMETHING YOU VALUE
AT, EFFECTIVELY, ZERO!

Forget the LEO aspect, it's basically a true statement, but it's a
good example because go ahead call 911 and try to get them to respond
because something or someone is causing you "lost productivity", the
usual flimsy complaint about spam.

But put some $$$ value and maybe just maybe...but with money you can
do a lot of things to enforce property values.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Fri, 14 Nov 2008 20:46:21 -0500

You asked, right?

-- 
        -Barry Shein

---

From: David Wall <[email-masked]>
Date: Fri, 14 Nov 2008 19:51:16 -0800

Rather than devise such a new scheme, think about why SenderID, SPF, 
DomainKeys and plain old S/MIME have not taken off.  These are all open 
standards, free to implement and thus should be attractive.

Yet they are not implemented.  Proving who the sender is would be huge 
-- it would allow for prosecution for illegal spamming; it would alert a 
user whose computer is infected and used as a bot, and it will allow for 
blacklisting (reputation loss). 

So, before you create a new parallel mail system that costs money and 
has cross payment systems, etc., why not get these standards implement 
fully?

Methinks it's not technology alone that's the problem.

David

---

From: Steve Atkins <[email-masked]>
Date: Fri, 14 Nov 2008 19:56:22 -0800

On Nov 14, 2008, at 7:51 PM, David Wall wrote:

> DomainKeys and plain old S/MIME have not taken off.  These are all  
> open standards, free to implement and thus should be attractive.
>
> Yet they are not implemented.

I suspect that the majority of email sent has three of those four  
implemented. If not quite a majority it's _definitely_ a large fraction.

(Yes, I'm cheating. Nobody other than the very, very gullible  
implements SenderID as such, but a valid SPF record is also a valid  
SenderID record).

> Proving who the sender is would be huge -- it would allow for  
> prosecution for illegal spamming; it would alert a user whose  
> computer is infected and used as a bot, and it will allow for  
> So, before you create a new parallel mail system that costs money  
> and has cross payment systems, etc., why not get these standards  
> implement fully?
>

Cheers,
   Steve

---

From: David Wall <[email-masked]>
Date: Fri, 14 Nov 2008 20:02:39 -0800

> implements SenderID as such, but a valid SPF record is also a valid 

Since spam is said to be 90%, 95%, 99% of all email, but you say most is 
sent with sender id.  Are you suggesting most spam is sent with valid 
sender id?  Don't think so.

Having an SPF record is not the same as implementing SPF unless you 
block all email that arrives that is not authenticated through SPF.  You 
are just posting a sign saying you'd like to comply, but don't actually 
implement it on the receiving end.  And if you block everything that 
doesn't have SPF configured, you'll lost much of your legit email.

David

---

From: Steve Atkins <[email-masked]>
Date: Fri, 14 Nov 2008 20:20:34 -0800

On Nov 14, 2008, at 8:02 PM, David Wall wrote:

> Since spam is said to be 90%, 95%, 99% of all email, but you say  
> most is sent with sender id.  Are you suggesting most spam is sent  
> with valid sender id?  Don't think so.
>
> block all email that arrives that is not authenticated through SPF.   
> You are just posting a sign saying you'd like to comply, but don't  
> actually implement it on the receiving end.  And if you block  
> everything that doesn't have SPF configured, you'll lost much of  
> your legit email.

Nobody with any experience or knowledge about email would seriously  
suggest blocking mail solely due to lack of an SPF record or a  
SenderID record or a DK or DKIM signature or an S/MIME signature or an  
X-Herring: Red header.

However, most of those data points are widely checked and are used to  
make decisions about mail delivery.

Cheers,
   Steve

---

From: David Wall <[email-masked]>
Date: Fri, 14 Nov 2008 20:29:48 -0800

> SenderID record or a DK or DKIM signature or an S/MIME signature or an 

Why is that?

It's not my contention that it could be done in practice, just that the 
ongoing "discussion" about a "new email paradigm" based on pricing 
email, email postage, etc. as a IETF standard to thwart spam might have 
more than a technical consideration to its implementation (which doesn't 
mean a programming language, but how you'd get millions of server and 
billions of users to cooperate and adopt it worldwide).

David

---

From: Steve Atkins <[email-masked]>
Date: Fri, 14 Nov 2008 20:38:24 -0800

On Nov 14, 2008, at 8:29 PM, David Wall wrote:

>> SenderID record or a DK or DKIM signature or an S/MIME signature or  
>> an X-Herring: Red header.
>
> Why is that?
>
> It's not my contention that it could be done in practice, just that  
> the ongoing "discussion" about a "new email paradigm" based on  
> pricing email, email postage, etc. as a IETF standard to thwart spam  
> might have more than a technical consideration to its implementation  
> (which doesn't mean a programming language, but how you'd get  
> millions of server and billions of users to cooperate and adopt it  
> worldwide).

Because email is, fundamentally, about people.

People want to get email from their friends, their family, their  
colleagues and their acquaintances. The vast majority also want to get  
mail from companies they've bought from or expressed an interest in  
(within reasonable constraints), organizations they're members of and  
so on. And they also want to receive serendipitous mail from strangers.

Naive blocking based on lack of SPF record, lack of DKIM signature or  
lack of X-Herring: Red header breaks that. And breaking that, breaks  
email.

The vast majority (though not quite all) ISPs understand that their  
role is to make their subscribers happy, and breaking email is not a  
good way to do that.

Cheers,
   Steve

---

From: Matthias Leisi <[email-masked]>
Date: Sat, 15 Nov 2008 11:44:20 +0100

> implemented. If not quite a majority it's _definitely_ a large fraction.

Do you have some (circumstantial) evidence or some more-or-less hard
data to back that statement up?

>From my experience, I highly doubt that this statement is true
(especially for mail sent from corporate environments - it's a bit
different when looking at outgoing mail from ISPs and webmail providers).

-- Matthias

---

From: Steve Atkins <[email-masked]>
Date: Sat, 15 Nov 2008 09:38:09 -0800

> different when looking at outgoing mail from ISPs and webmail  

When I said "majority of email" I meant "majority of legitimate  
email", so
excluding botnet originated spam (which doesn't seem to be using DKIM
or SPF much). (I tend to categorize botnet originated spam separately
because dealing with it is so different to dealing with the rest of  
email,
but I really ought to be clearer about that).

If you're sending mail in large volumes then you require SPF or SenderID
records to be able to send email successfully to Hotmail. Until  
recently you
also needed them to comfortably send mail to AOL. They're easy to
put in place and free to do, so everybody sending significant volumes
of bulk mail has SPF in place (even B2B bulk mail, as most anywhere
doing B2B bulk is also doing B2C bulk). One noticeable ISP has dropped
their SPF records to make a political statement, but in general they  
don't
cause any problems so they tend to be left in place even after their
perceived value has dropped to the level of, say, Hotmail.

The same is mostly true of DK or DKIM signing, due mostly to persuasion
from Yahoo and AOL, as well as people with influence who think having
DKIM deployed is better done sooner than later. Good support for signing
in most all of the commercial appliances, enthusiasm from sendmail inc.
for DKIM and so on all helps that number too.

So I'm fairly comfortable saying, from personal experience, that the
majority of commercial bulk email sent (via ESPs or under the
supervision of competent delivery staff) is using SPF and most of
it is signed with one or both of DK and DKIM.

That right there is a large fraction of legitimate email
that's carried over the internet. Throw in the number of major consumer
ISPs who are signing with DK and/or DKIM and which have SPF records
in place and that's probably a majority.

Non-bulk mail sent from corporate environments? Almost lost in the noise
by that point. (And Microsoft, for reasons of saving face, is about  
the only
entity who isn't enthusiastic about DKIM, so Exchange users are likely  
to
be the tail end of the technology curve again). IIRC there's a lot of  
SPF
deployment at large enterprises, though.

Very few entities of any size are checking SPF and placing a lot of
weight on the result (because it's crap). Very few entities are doing
much serious with inbound DKIM yet (because we're still feeling our
way around the operational issues before we decide to do neat stuff
with the data). But there's a lot of signing going on.

Various groups have done surveys of this sort of stuff, but they've
mostly been done by surveying DNS, rather than looking at a real
mail stream, which leads to all sorts of selection bias. The large
consumer ISPs certainly have the data, but I don't know of any that have
released it. The data I've seen tends to match my experience, but
I don't know of any recent surveys that have published this sort of
data recetly.

Cheers,
   Steve

---

From: Matthias Leisi <[email-masked]>
Date: Sat, 15 Nov 2008 20:23:02 +0100

>>> I suspect that the majority of email sent has three of those four
                       ^^^^^^^^^^^^^^^^^
>>> implemented. If not quite a majority it's _definitely_ a large fraction.

vs.

> majority of commercial bulk email sent (via ESPs or under the
              ^^^^^^^^^^^^^^^^^^^^^
> it is signed with one or both of DK and DKIM.

There is a huge difference between the two, and a lot of people do not
care much about the latter.

For the former, given the lack of support for DK/DKIM signing in the two
most pervasive corporate email servers (Exchange and Lotus Notes), it's
reasonable to expect such mail *not* to be signed.

> in place and that's probably a majority.

Maybe it's different for US-based providers, but I do not know of any
significant European provider doing DK/DKIM signing.

-- Matthias

---

From: Franck Martin <[email-masked]>
Date: Sun, 16 Nov 2008 10:33:52 +1200

Have you seen my earlier email about a meet at IETF to test DKIM at  
UNI level?

Toute connaissance est une réponse à une question

On 16/11/2008, at 5:38, Steve Atkins <[email-masked]> wrote:

> entity who isn't enthusiastic about DKIM, so Exchange users are  
> likely to
> be the tail end of the technology curve again). IIRC there's a lot  
> of SPF

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 15 Nov 2008 18:10:34 -0500

> Yet they are not implemented.  Proving who the sender is would be huge  

Ah, but we can already do so *without* these technologies -- in the
sense that matters -- and we cannot do so *with* these technologies --
in the sense that doesn't.

Let me explain that rather cryptic statement.

If 1.2.3.4 connects to my mail server, then 1.2.3.4 *is the sender* --
or perhaps, more precisely, the sending-system.  Whowever does the
care and feeding of the host at 1.2.3.4 is ultimately responsible
for whatever abuse comes across that connection.  That might include
postmasters, system administrators, network engineers, etc. -- obviously
every situation is different.  But clearly that connection occurs
on *somebody's* watch.

And that's the part that we can do today, without any of these
technologies.  We've been doing it for decades, and we've learned
that holding people accountable based on it works very well.
(We've also learned that not holding people accountable is often
seen as tacit assent to further abuse.)

What we can't do is identify the user.  But this doesn't matter
to any of us *out here*: that's an internal matter for 1.2.3.4's
keepers to work out, and if they're at all competent, their own
logs will *possibly* identify the user responsible for whatever-it-is.

And I say *possibly* because with a few hundred million fully-owned
systems out there, we have to give the possibility that it's not
the user the logs make it appear to be who's actually responsible,
but only the user's system.  And note that even *with* any of these
technologies, there's no help distinguishing these two possibilities
from each other: an attacker fully in control of the user's system
can do anything that the user can do.

If we want these technologies to actually be useful, we're going
to have to do something about retaking those few hundred million
systems and keeping them from being re-owned.  Having observed
this over the past half-decade or so, my sense is (a) nothing
in the least bit effective is being done and (b) I see no signs
that this will change any time soon.

---Rsk

---

From: Barry Shein <[email-masked]>
Date: Sat, 15 Nov 2008 18:12:37 -0500

> billions of users to cooperate and adopt it worldwide).

May I point out that it's been at least a decade that people have been
shooting down anti-spam proposals because "that would take a decade to
get adopted!"?

I realize the quote above doesn't quite state a time period, but it's
in the same vein.

If someone has the FUSSP (or progress thereto), except it might take
some wide acceptance or some time to get implemented, I suggest that
we try to quantify that as one among many factors rather than try to
drown out the idea itself by repeating the objection over and over.

That is, I'd think of that as more of a discrete table entry (requires
wide acceptance: [ ] yes [ ] no) or scoring item (relative acceptance
requirement on a scale of 1-100: 90) rather than a "disproof", an
immediate dealbreaker.

We could argue about how to set up that scoring, the weighting
coefficients etc, but to grasp onto one factor like "you'd have to get
millions of servers to comply", or "it would take YEARS!", or "we'd
have to rework smtp" and act like it's the only factor worth
considering seems, well, very unsophisticated, more in the realm of
polemic ("it's crap!") than science or engineering ("it scores low!")

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Sat, 15 Nov 2008 18:22:25 -0500

> role is to make their subscribers happy, and breaking email is not a  

In some ways I ;ike your description a lot.

But as an ISP let me also remind you that people being flooded with
spam also "breaks email".

We get heated complaints about both, false positives and too much spam.

As one example, we still have quite a few dial-up customers.

At V.92 50kbps, a practical limit, that's about 5 kilobytes/second
ideally, or about 17MB/hour.

A call about a 50+MB mailbox which would take almost 3 hours to move,
message by message or the whole thing, same problem, isn't unusual at
all. And I mean with all the various spamassassin, procmail, etc.
mechanics in place.

Most people don't want to spend 3 hours making a single pass on their
mailbox. Or, if they download the whole thing before reading locally,
3 hours before they see the first message. Particularly if there are
only several messages they actually want to see in there.

So, although the sentiment expressed above is appreciated and a
reasonable ideal, in practice we don't live in such an ideal world.

-- 
        -Barry Shein

---

From: Steve Atkins <[email-masked]>
Date: Sat, 15 Nov 2008 15:36:23 -0800

> We get heated complaints about both, false positives and too much  

Absolutely. Delivering everything breaks email. Using broken, stupidly
aggressive spam filters breaks email. Using spam filters that reject  
some
unwanted email, but also reject a lot of wanted email... breaks email.

(It may not break email for one particular recipient, with a particular
email demographic, but it's going to make email unsatisfactory for
a significant fraction of users of pretty much any ISP.)

It's the operational problem to choose the right approach that doesn't
fall foul of any of those issues[2]. Naive blocking based on lack of SPF
record or lack of DKIM signature will block a lot of wanted email.

> only several messages they actually want to see in there.

All true[1].

> reasonable ideal, in practice we don't live in such an ideal world.

No, the original sentiment was explicitly "Blocking email based solely
on lack of SPF record or DKIM signature will break email." You don't
need to live in an ideal word for that to be true, just this one where
they're both deployed at least as much by mainstream, non-botnet
spammers, as they are by sources of wanted email.

Cheers,
   Steve

[1] Though this is why many people on slow connections
tend to prefer interactive mail, where they can manually filter
based on sender and subject line, rather than downloading the
whole thing. Different thread.

[2] Not a hard operational problem. Freely available, off-the-shelf
conservative content-based filters, combined with free blacklists
of compromised machines and a modicum of virus detection does
pretty well, with minimal effort for the user and not too much
system overhead. That's yet another thread, though.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 15 Nov 2008 23:41:21 -0000

>shooting down anti-spam proposals because "that would take a decade to

Actually, the problem with e-postage has nothing to do with standards
and everything to do with the fact that nobody has any idea how to
implement it in a way where the revenue would come within a couple of
orders of magnitude of paying the infrastructure costs.

If you're going to say "don't do it that way", remember to tell us
what way we should do it.  The hand waving is getting a little old.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Sat, 15 Nov 2008 19:35:06 -0500

> Actually, the problem with e-postage has nothing to do with standards

Well, I was really making a general statement, my momentary interest
may be charging bulk emailers somehow but if we can learn this much
from the discussion I think that's of value.

 > orders of magnitude of paying the infrastructure costs.

Yeah, which maybe is why this is the anti-spam RESEARCH group and not
the anti-spam CODING group.

But the objections haven't been so much about how to implement,
they've been objections to the very concept, vastly over-stated
"proofs" that it's impossible, etc.

 > what way we should do it.  The hand waving is getting a little old.

Something's getting a little old. Maybe it's heated meta-discussions
rather than "ok, that's an interesting idea, making spammers pay for
what they use somehow would no doubt slow them down a lot, let's try
to work it out a little and see where it goes".

Or maybe we should just admit that the purpose of this group is to try
to figure out how to control a limited resource (i.e., people's
ability to deal with their email) that does not involve any sort of
resource charges whatsoever as a given.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Sat, 15 Nov 2008 19:35:06 -0500

-- 
        -Barry Shein

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 15 Nov 2008 19:47:44 -0500

> orders of magnitude of paying the infrastructure costs.

I strongly concur with John: nobody has come up with even a remotely
plausible method of solving this problem.

And even if someone did -- that solution, whatever it turned out to be,
would be rendered moot shortly after deployment because the same abusers
who currently control a few hundred million 0wned systems (and are using
them to send spam, among many other things) could just as easily use
them to completely disrupt the economics of that solution.

---Rsk

---

From: John Levine <[email-masked]>
Date: 16 Nov 2008 01:00:34 -0000

>to work it out a little and see where it goes".

Been there, done that, wrote the white paper.  Really, I'm not
sceptical of pay-to-spam because I haven't thought about it, I'm
sceptical because I HAVE thought about it.

>resource charges whatsoever as a given.

That seems like a reasonable idea.  The most interesting charging
systems in recent years are Vanquish, which had refundable payments,
and Goodmail, which is approximately paying for better delivery of
bulk mail that would probably have been delivered anyway.

Both are closed systems.  There was never any spam inside the Vanquish
system, because the kind of people who'd sign up for it aren't the
kind who'd send spam.  (Spammers, after all, are defined by their
desire to avoid paying for stuff.)

Goodmail does what it does perfectly well, but again it's a closed
system with its own channels into the ISPs that it works with, and
it's not much of a model for scaling up to the entire Internet.  They
offer stuff that is of great interest to online marketers, e.g., web
mail systems displaying the graphics in their mail, and pretty
uninteresting to the rest of us.

On the other hand, there's plenty of non-financial incentives that we
could use to beat up on spammers.  Everyone talks about reputation
systems, but there are precious few other than DNSBLs implemented, and
they don't suffer from any of the inherent scaling problems that
postage systems have.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Sat, 15 Nov 2008 20:07:34 -0500

> them to completely disrupt the economics of that solution.

I see. You haven't the slightest idea how such a system might work
(first paragraph), but you're very certain about its flaws (second
paragraph).

-- 
        -Barry Shein

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 15 Nov 2008 21:40:50 -0500

> (first paragraph), but you're very certain about its flaws (second

Yes, I'm quite certain.  I don't *need* to know the details of how such
a system might work in order to recognize that the current security
situation will allow it to be undercut the moment abusers decide
it's worth their time and trouble.

---Rsk

---

From: Barry Shein <[email-masked]>
Date: Sun, 16 Nov 2008 17:14:38 -0500

> it's worth their time and trouble.

Wow, what a globally negative attitude. Maybe this needs addressing?

As far as I know SSL hasn't been cracked directly. There's been quite
a bit of social engineering (e.g., phishing) but that's not quite what
I'd call "cracked" and although some progress can and will be made on
that it's still kinda like letting someone in your house because they
claim they're from the gas company w/o checking credentials carefully.

So anything as hardened as web SSL certs is probably a
counter-example, no?

I suppose it leads to what level of success can be considered
reasonable progress?

For example, a lot of spam is designed to get by spamassassin and its
bayesian filters, but that does that mean spamassassin and bayesian
filters should be abandoned, or should never have happened?

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 16 Nov 2008 22:59:23 -0000

>So anything as hardened as web SSL certs is probably a

No, not really.  The reasons why it's not a useful analogy should
be obvious.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Sun, 16 Nov 2008 20:16:45 -0500

> No, not really.  The reasons why it's not a useful analogy should

Well, it beats me how one does a high-confidence security analysis of
an algorithm which doesn't even exist so I'm all ears and apologies if
it's just so gosh-darned obvious. A link to a paper or similar would
be more than sufficient for me anyhow, no need to spell it out here.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Sun, 16 Nov 2008 20:16:45 -0500

-- 
        -Barry Shein

---

From: Seth <[email-masked]>
Date: Mon, 17 Nov 2008 08:25:21 -0500 (EST)

Barry Shein <[email-masked]> wrote:

> As far as I know SSL hasn't been cracked directly.

If your grandmother can send mail from her PC, what's to stop the
spammer who zombied it from sending mail the same way?

Limits don't matter; the spammer has tens of millions of zombies, so
will send from each the amount of email a real person might.

Seth

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 13:44:56 -0000

>spammer who zombied it from sending mail the same way?

Let's say that Grandma picks an ISP, let's call it World, for its
friendly personal service. Spammer hacks or phishes Grandma and sends
a bunch of spam from her PC, postage of $43.27 is now due.

Who pays the postage?  Grandma?  She calls World (or perhaps her
teenaged granddaughter who set up her PC calls) and tells World to
forget it.  The spammer?  He's in Estonia.  So does World pay?  If so,
how can anyone afford to run an ISP?  If not, it's not really
pay-to-spam, is it?

On the third hand, if we're going to wave our hands and assume that
all the mail we exchange has strong sender authentication, there's
some rather powerful sorting and filtering tools we can use that don't
require inventing payment schemes.

R's,
John

---

From: [email-masked]
Date: Mon, 17 Nov 2008 07:53:44 -0600 (CST)

> Who pays the postage?  Grandma?

  That is the best post about why NOT to invent a financial
  penalty I've seen.

   Now, knowing how many hackable boxen their are on the net, and
  how many bad upstream/registrars there are, how long do you think
  the truly profit oriented folks to figure out how to make money
  off this scheme and grandma?

 another John, another idea

This message is confidential, intended only for the named recipient(s) and
may contain information that is privileged or exempt from disclosure under
applicable law.  If you are not the intended recipient(s), you are
notified that the dissemination, distribution or copying of this message
is strictly prohibited.  If you receive this message in error, or are not
the named recipient(s), please notify the sender at the e-mail address
above and delete this e-mail from your computer.  Thank you.

---

From: der Mouse <[email-masked]>
Date: Mon, 17 Nov 2008 11:45:56 -0500 (EST)

>> friendly personal service. Spammer hacks or phishes Grandma and
>> sends a bunch of spam from her PC, postage of $43.27 is now due.

> That is the best post about why NOT to invent a financial penalty
> I've seen.

And to inject a slightly different perspective, the BOFH in me says
it's one of the best reasons _to_ do so.  Financial penalties for
getting pwned are one of the very few things that might actually get
users to stop being idiots about such things.  As long as running a
grossly insecure machine on the net incurs minor-to-no costs, people
will continue doing it.

The major problem, I think, is the Prisoner's Dilemma that inheres in
implementing it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "David Nicol" <[email-masked]>
Date: Mon, 17 Nov 2008 11:01:02 -0600

>> That is the best post about why NOT to invent a financial penalty

I can now include a link to this bit in the archives in the Advenge
FAQ under "Why are payments made in advance rather than accrued and
billed?"

-- 
"Slingshot delivers all mail shipments to the post office by bicycle!"
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: David Wall <[email-masked]>
Date: Mon, 17 Nov 2008 09:05:26 -0800

> grossly insecure machine on the net incurs minor-to-no costs, people

I agree in principle, though believe such a system is just too unwieldy 
to attempt in a global email world.  What we need first is some sort of 
provable sender id.  This step itself is incredibly hard to get done, 
hard to get cooperation on, yet hard to understand why trying to prove 
who sent an email would be such an issue.

You can't charge someone if you can't prove they sent it.

Yes, if you charge people for allowing their systems to be abused, you 
are liable as long as there are tool easily available to remedy the 
situation.  You can't fine/charge someone for being ill, but you can if 
they are willfully negligent.  I mean, if your phone could be used to 
make long distance calls without your consent, you'd likely be required 
to pay for them anyway.

So, before worrying about paying to send, it makes more sense to me to 
implement proving who the sender is first.  This leads to identifying 
"bad senders" first, which can be used to determine if they are actual 
spammers are victims, and if victims, to get their systems cleaned up, 
and if they persist in not cleaning up, then in getting them booted from 
the ISP (or SMTP provider if a business, etc.), blacklisted and/or 
turned over to authorities as a provable spammer.

David

---

From: "John Johnson" <[email-masked]>
Date: Mon, 17 Nov 2008 11:26:06 -0600

> grossly insecure machine on the net incurs minor-to-no costs, people
    Or, could you pass the costs on to the idiots that are supposed to
   KNOW better about security that left Grandma at risk?  Perhaps
   'Mr. OS vendor"  will pony up and vet all their customers that end up
   zombified.  Probably not.
> The major problem, I think, is the Prisoner's Dilemma that inheres in
   I agree, Mouse.   But you have to consider, in your prisoner's
   dilemma, that a new scenario exists - the bad guys could be
   rewarded based on bad policy.

John

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 17 Nov 2008 12:38:52 -0500 (EST)

On Mon, 17 Nov 2008, David Wall wrote:

> I agree in principle, though believe such a system is just too unwieldy to 
> attempt in a global email world.  What we need first is some sort of provable 
> sender id.  This step itself is incredibly hard to get done, hard to get 
> cooperation on, yet hard to understand why trying to prove who sent an email 
> would be such an issue.
>
> Yes, if you charge people for allowing their systems to be abused, you are 
> liable as long as there are tool easily available to remedy the situation. 
> You can't fine/charge someone for being ill, but you can if they are 
> willfully negligent.  I mean, if your phone could be used to make long 
> distance calls without your consent, you'd likely be required to pay for them 
> anyway.
>
> implement proving who the sender is first.  This leads to identifying "bad 
> senders" first, which can be used to determine if they are actual spammers 
> are victims, and if victims, to get their systems cleaned up, and if they 
> persist in not cleaning up, then in getting them booted from the ISP (or SMTP 
> provider if a business, etc.), blacklisted and/or turned over to authorities 
> as a provable spammer.

In real life, Grandma would refuse to pay the bill, the ISP would block 
her access to their forwarding MTA, and Grandma would get a Hotmail 
account. I don't know what would happen with that, but I doubt if the 
supreme court would be involved at any point.

You might reasonably retort that the telephone company does sue for 
telephone charges, even when there is a question of who made the calls. 
But the telephone company practices were developed when it had a monopoly, 
and didn't have to worry about losing the customer. The ISP still wants 
the $40/month for internet access, so it will just set a credit limit and 
eat the small losses.

Daniel Feenberg

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 13:45:43 -0500

> will send from each the amount of email a real person might.

Well, limits don't make it impossible for the spammer as you point out
but they might slow the spammer down.

I don't think there's any system which will relieve the world of
solving the problem of mega-zombie networks by itself.

As we've seen, such bot-armies can take down rather capable sites and
demand ransoms or just disrupt things for whatever reason including
political.

But right now one problem is that there isn't much financial incentive
for, in particular, big ISPs to get more pro-active about the bot-army
problem. I think everyone agrees that's one reason these bot-armies
persist.

So my proposal is to try to add some of that missing financial
incentive into the system.

Money has a way of focusing the mind.

-- 
        -Barry Shein

---

From: der Mouse <[email-masked]>
Date: Mon, 17 Nov 2008 13:43:45 -0500 (EST)

>> Financial penalties for getting pwned are one of the very few things
>> that might actually get users to stop being idiots about such
>> things.

> I agree in principle, though believe such a system is just too
> unwieldy to attempt in a global email world.

If your focus is restricted to email, perhaps.

> What we need first is some sort of provable sender id.

We mostly have that at the host level, and that's enough for what I was
sketching to work (to the extent that it will work at all, that is).
"Your machine sent it; you're responsible" - much as (as you point out)
it already is for telephones; bad as that analogy is in many respects,
I think it's a good one in that one respect.

> You can't fine/charge someone for being ill,

Sure you can.  Ever hear of employers allowing only limited numbers of
sick days? :-)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Mon, 17 Nov 2008 13:50:01 -0500 (EST)

> In real life, Grandma would refuse to pay the bill, the ISP would
> block her access to their forwarding MTA, and Grandma would get a
> Hotmail account.

And how would she access the Hotmail account?  Through the ISP that's
blocked her service until she pays her bill?  (Why would they block
just her MTA access?)

If she abandons home net access and uses public machines, the problem
(from the point of view of the net-at-large) is solved, since her
machine is no longer an abuse-emitting zombie; if she cleans up
(whether with or without help is irrelevant), likewise.  If she
provider-hops to one who doesn't slap down abuse emitters, her abuse
emitter can be blocked as part of the abuse-haven provider.

The problem is reaching the state where the abuse-haven providers, the
ones who don't act against abuse-emitting zombies on their
connectivity, are thin enough on the ground for a substantial fraction
of the net to be willing to blanket-block them.  And that's where the
Prisoner's Dilemma I mentioned upthread rears its ugly head.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Seth <[email-masked]>
Date: Mon, 17 Nov 2008 14:09:27 -0500 (EST)

David Wall <[email-masked]> wrote:

> So, before worrying about paying to send, it makes more sense to me
> to implement proving who the sender is first.  This leads to
> identifying "bad senders" first,

Identities are infinite and free.

Seth

---

From: David Wall <[email-masked]>
Date: Mon, 17 Nov 2008 11:25:06 -0800

> Identities are infinite and free.
Sadly, this is somewhat true, but SPF and DKIM work on domain names, and 
they typically aren't free.  Assuming a domain name seller acquires 
payment for the domain, there's is a financial trace possible when 
necessary.  And if the payment is fraudulent, the domain name seller has 
an interest to fix that loophole.  While subdomains can be done for 
free, they are tied to a domain that again has a reputation to protect 
or is traceable if used repeatedly.

To be sure, it ain't easy, and getting worldwide adoption of prepaid 
postage is likely harder.

David

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 14:35:46 -0500

> a bunch of spam from her PC, postage of $43.27 is now due.

Well, this is again a straw man. I suppose I'd have to answer "you're
right, that would be a really dumb way to design such a system! So
let's not do it!" (doctor it hurts when I...)

Let's go to the end here...

 > require inventing payment schemes.

I haven't waved any such strong authentication hands, you just made
that up, right?

The way I conceive it there isn't any sender auth required, or not in
that sense.

Amazon buys cryptographic cookies and puts them in the email header.

These can be verified independently by a receiver (MUA, MTA, whatever,
that's policy.)

Crypto can be made pretty hard.

But since Amazon only pays for the postage it uses then, for example,
the only only real downside of a false positive at the receiver end is
you get spammed. But we've made it a lot harder.

But here's a better one: Limits, unless explicitly waived.

Grandma can send, I dunno, pick a number, 1,000 free messages a day
(receiving isn't involved), that'd slow down any spammer. If you
exceed then by default you're shut off. Maybe as an ISP I'd up you to
10,000/day free merely for asking, grandma would never ask, if you're
aware enough to ask you probably aren't that likely to be zombied.

WHATEVER, that's marketing, right?

Every ISP has limits right now so save me any faux hypotheticals.

For example, email boxes are never infinite for these $20/month
accounts. And when you exceed that limit, your mail bounces. But you
can buy more if you like. So make sure the hypothetical you're itching
to type in doesn't also apply just as well to the status quo of
mailbox size limits, or web bandwidth quotas, etc.

See, what's being missed here is what (and color me astonished) most
novices miss when they start thinking about the spam problem.

That is that spammers, in order to be any sort of nuisance at all,
have to send out STAGGERING amounts of email. On the order of a
billion (10^9) per day per each.

If they couldn't you wouldn't see very much of it and it wouldn't be
much of a problem and we could disband and leave it to the methods
already in place (spamassassin, white listing, C/R, etc.)

STAGGERING amounts! Repeat after me...stag-ger-ing...

You should watch my mail logs here. It's an odd day I don't have
SEVERAL simulataneous dictionary attacks ([email-masked], no such
user, [email-masked], no such user), often coming from big ISPs like
earthlink which is kinda frustrating: They shut it down and it pops up
again w/in 24 hrs and they shut it again and again and then they get
sick of shutting it down and we get sick of asking and suggest they
fix their system which raises tension etc...

All day, all night, every day, every night, day in, day out.

And that's just ONE easily log-summarized (I have script which gives
me a frequency chart of sites generating the most user unknowns) spam
form. Most of the traffic isn't that, it's just being pounded from
lists spammers have. All day, all night...

STAGGERING!

Consequently, I claim we could give grandma a free quota of 1,000
messages a day, maybe 10,000 (A DAY!) and it would still royally screw
the spammers.

Isn't that amazing? Don't ask "what if that's false", ask "what if
that's true?"

I have been running this ISP for almost 20 years, and running large
networked systems almost a decade longer (I put boston university on
the internet, I was in charge of most of their network in the 80s),
cut me a little slack that maybe I have some well-developed ideas
about all this.

I realize the mind's eye tends to scale the problem down and only
thinks of it in terms of existentiality, of that ONE message in MY
box...if grandma can send 10,000 messages doesn't that mean she can
put 10,000 messages into MY MAILBOX? What sort of progress is that?

But of course that's nonsense, that's not what goes on, not at all.

I'd probably advise something more like rate-limiting rather than
absolute quota. Not so hard.

BUT EVEN ALL THAT BEGS THE ACTUAL PROPOSAL...

See, perhaps I'm a fool to waste so much energy tearing down straw men
which mostly serve to ignore the actual intent of the idea.

The actual intent is to create an economics around bulk commercial
email...EVEN WHAT WE'D CALL "BONA FIDE" BULK EMAIL.

Because with some sort of economics, as we have seen, nothing happens.

While you (and I) were sitting here the last several years trying to
come up with some FUSSP Verizon built out a multi-billion dollar FiOS
network, Apple developed a huge iTunes content site from nothing,
Google became a powerhouse in the IT industry, etc etc etc.

And, to paraphrase the Wizard of Oz in his last scenes, what's the
difference between this effort and theirs? MONEY! ECONOMICS!

You shouldn't be so resistant and keep proposing straw man problems no
rational person would implement and declaring them disproofs.

I only see most of them as reasonable boundry conditions tho many are
in the realm of marketing.

What really is the concern of this group in terms of economic impact
of their proposals? Except to wave them as red flags crying out for
the poor ISPs et al when an idea just doesn't suit them.

Can someone give me the dollar impact of any proposal which has gone
thru here? Or any attempt to calculate it?

Back in the 1970s I worked in occupational epidemiology at the Harvard
School of Public Wealth, er, Health.

We had a full-time phd faculty-level economist on the staff whose job
it was to calculate the economic impact of various things we were
involved in, many of those reports went to congress because many of
our conclusions became legislation (e.g., to limit exposure to a
particular substance.) We also spent a lot of time with unions,
management, and in particular insurance companies who often would be
holding the long-term bag for health costs from exposures. It was
fascinating...anyhow.

How different is this group from an epidemiology group, really?

Yes, grandma needs to be considered, the typical user needs to be
considered, non-profits, non-commercial mailing lists, etc etc etc.

It's not that complicated.

But my fundamental claim is either we inject economics into the
picture or we're doomed. We're doomed to just sit here another 10
years trying to invent a perpetual motion machine to solve the energy
crisis.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 14:35:46 -0500

STAGGERING!

-- 
        -Barry Shein

---

From: Seth <[email-masked]>
Date: Mon, 17 Nov 2008 15:09:33 -0500 (EST)

> Amazon buys cryptographic cookies and puts them in the email header.

What does Grandma buy?

> These can be verified independently by a receiver (MUA, MTA, whatever,

What stops Amazon from re-using the purchased cookies?  Panix has no
way of knowing if World received email that used the same cookie.

> Grandma can send, I dunno, pick a number, 1,000 free messages a day

Enforced by whom?

> (receiving isn't involved), that'd slow down any spammer.

Like one with 10 million zombies?

>  Maybe as an ISP I'd up you to 10,000/day free merely for asking,
> grandma would never ask, if you're aware enough to ask you probably
> aren't that likely to be zombied.

Are you going to pay real people to answer the phone, or will you
accept requests by computer (from zombies)?

Seth

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 15:57:33 -0500

Ya know, if confirmation from ISPs message queueing systems could just
ripple back to the end-user a message like:

      Message Accepted.

      You have sent 9,731 messages today.

      If that seems wrong your computer may
      be infected, please click here: [HELLLPPP!]

                     [Looks OK]

or the moral equivalent thereof I'd imagine a lot of zombie pc's would
get cleaned up (assuming the help was really of help.)

It's the logical follow-up to blocking port 25. Now that they can't
get out use the submission count for something.

It could also warn that maybe you're about to exceed some quota, do
not ignore this or you won't be able to send email at all, you have
ignored this message N times don't say we didn't warn you, etc.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 16:37:03 -0500

On November 17, 2008 at 11:25 [email-masked] (David Wall) wrote:
 > they typically aren't free.

Hah! The new term you need is: domain-tasting

This has been a big issue in that playground.

Basically, for simplicity's sake, virtually all registrars let you
cancel an order for a domain name in I think it's 5 days.

THIS IS NOT AS SIMPLE AS YOU THINK AND IS RELATED TO...oops, sorry for
shouting just wanted to save you typing back the obvious...related to
settlement charges with ICANN and so on, business models, established
business models which didn't anticipate this kind of abuse, how
unusual for the net (NOT!)

Well, what did that lead to? Orders of 5,000 or 10,000 domain names at
a time which are then cancelled w/in 5 days, no charges, all highly
automated.

A lot of it is done by these folks who park web pages at all those
addresses, see how much traffic they get, and keep the ones which
should be profitable by that measure (personally I don't have a big
problem with that so long as they pay their freight and are otherwise
honest but apparently a lot of people do and see it as inherently
unethical.)

But it's also an open channel to near-infinite, free domain names for
the less than savory (by that I mean spammers, phishers, politicians.)

Why? Go read the ICANN minutes on this, there's probably hundreds of
pages of discussion and let me tell you: Not one of those people
involved in the discussions (well, not many at all) is either dumb or
evil.

Some structural changes have already been made to begin counter-acting
this practice but it could take a coupla-few years to get under
control. Some of it is the business model shock and awe problem, some
is moving software, some is remaining issues and counter-issues with
some future details.

 > Assuming a domain name seller acquires 

Well, all I can say is you're completely wrong on the first part as
I've just described and referenced, so what can we conclude about your
other advice? The world doesn't work as you expect, what a surprise!

Maybe you need to get a little more aware of what's actually going on
before running vast global simulations in your head for us. It's all
online and free but you have to do a little work.

         http://en.wikipedia.org/wiki/Domain_tasting

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 17:03:30 -0500

> > Amazon buys cryptographic cookies and puts them in the email header.

Grandma doesn't have to buy anything in the typical case, as I
envision this.

For most regular users their ISP would stick a stamp on at the MTA,
much like DKIM or whatever, some sort of header.

One would assume that ISPs who do this sort of end-user service would
get all the stamps they need for this for some flat fee which could be
zero but let's be realistic, but think SSL cert charges. There'd have
to be some guidelines to prevent blatant abuses, which in turn would
be some incentive to prevent customers abusing.

 > way of knowing if World received email that used the same cookie.

I guess the same thing which stops amazon from taking your order and
sending you nothing (thanks sucker!)

There are cryptographic techniques to help with avoidance, detection,
recovery, etc.

But the short answer is: If they get caught they presumably have
committed at least damage to their good will (think: like one's credit
rating), possibly tortious for various reasons, and conceivably
criminal, fraudulent, once things get going and courts might recognize
that maliciously counterfeiting these credentials is a problem w/in
their jurisdiction.

Maybe ISPs and others who were relying on this pool of funds would
boycott them until they've certifiably cleaned up their act.

Go ask amazon what they'd think of a day without google mail.

 > > Grandma can send, I dunno, pick a number, 1,000 free messages a day

I guess her ISP, like limits on her inbox size, etc.

 > Like one with 10 million zombies?

Well, the current situation is infinite, or full capacity of the
zombied machine and its connection anyhow.

And little or no motivation to even meter that activity let alone act
on that non-existant metering.

Now we've created some motivation. A system which actually pays the
ISP (as I've said before and maybe even the end-user but that's
marketing.) But only if it's reasonably reliable.

In a way there's a wonder asymmetry involved here.

An ISP might at some point say to (e.g.) Amazon: As of DATE we no
longer will accept email from (e.g.) Amazon unless it's properly
franked. Probably they'd say that at the point that it's already true,
but you go one by one down the list or whatever.

Now, could Amazon say to ISP: Well, then *WE* won't accept email from
YOU unless it's properly franked!

OF COURSE NOT! Amazon (e.g.) WANTS their customers' business!

That's the asymmetry which is being utilized here.

 > accept requests by computer (from zombies)?

Passwords, captchas, etc.

How do I order anything of value from my ISP like web site services,
virtual mail domains, etc etc etc.

C'mon, you're just grasping for straws here, right? You know all this.

You do as much as the security warrants. For something like "I run a
small list, 1,000/day isn't enough, can I have the free 10,000/day?"
that's a pretty small security risk really, a captcha or similar might
do it.

And to anticipate your next response: And if they need 100,000/day?

Then somewhere around there they better get their own "postage meter"
just like at some point someone using a shared SSL cert oughta get
their own SSL cert, or other such services.

Whether that's free or not, or one time flat fee like an SSL cert, is
a different discussion. I'd envision several possibilities depending
on use (commercial vs non, etc.) or maybe it's cheap enough that
there's no need for that at that level, it's only a significant cost
for someone who sends out millions and millions per day.

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 22:35:10 -0000

>identifying "bad senders" first, which can be used to determine if
>they are actual spammers are victims, and if victims, to get their
>systems cleaned up, and if they persist in not cleaning up, then in
>getting them booted from the ISP (or SMTP provider if a business,
>etc.), blacklisted and/or turned over to authorities as a provable
>spammer.

Sounds good to me.

I still think there's some interesting research to be done about what
you'd do with reliable sender identities.  It's easy enough to
whitelist mail from people you already know, but is there anything
clever one might do with an identity that you can trust to be stable
but you know nothing else about?

R's,
John

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 22:37:49 -0000

>cancel an order for a domain name in I think it's 5 days.

Not any more.  Gotta pay attention, dude.  

To my astonishment, the .org registry has already made refunds
financially unattractive and ICANN's in the process of fixing the rest
of them by making part of the fee non-refundable.  The number of
refunds is already down something like 87% from what it was earlier
this year.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Tue, 18 Nov 2008 10:39:42 +1200 (ANAT)

Without forgetting what unclever things someone could do with sender identities. But I guess we are here to provide tools and leave each country the choice of using these tools for the pursuit of freedom or totalitarianism. 

----- Original Message ----- 
From: "John Levine" <[email-masked]> 
To: [email-masked] 
Sent: Tuesday, 18 November, 2008 10:35:10 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] actual possible improvements, was Email Postage 

Sounds good to me. 

R's, 
John

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 22:40:10 -0000

>let's not do it!" (doctor it hurts when I...)

Right.  But since I don't know how one would design a system that
doesn't have hijacking problems, and neither does anyone else,
evidently including you, I guess we're done chasing our tail for this
week.

Asserting that it would be nice if such a system existed is not
helpful.  I hear you get one free with your pony.

R's,
John

---

From: "David Nicol" <[email-masked]>
Date: Mon, 17 Nov 2008 16:47:46 -0600

> lists spammers have. All day, all night...

I'm wondering why World doesn't script a little log watcher that
identifies the source of dictionary attacks and drop all their packets
at the perimter for a few hours when they occur.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 22:50:44 -0000

>These can be verified independently by a receiver (MUA, MTA, whatever,

You know that double spending problem I keep whining about?  It kills
this model dead at any interesting message volume.  Nice try, though.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 17:53:16 -0500

> refunds is already down something like 87% from what it was earlier

I was actually sitting in the room in Paris when the ICANN BoD passed
this in June. I just wasn't certain if the changes had taken effect
yet, hence my allusion later in the note that changes were afoot.

And as I said there are more issues to be taken up.

Plus ca change, plus c'est la meme chose?

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 17:53:16 -0500

-- 
        -Barry Shein

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 17 Nov 2008 17:49:51 -0500

>       be infected, please click here: [HELLLPPP!]

Were this done -- say, with a standard bit of code that could be
attached to sendmail and postfix and exim and the like -- then I
think it's fairly likely that the same attackers who control all
those zombied systems and use them to send spam might take the time
to craft the code to throw those messages away.  Or perhaps to divert
them to their own C&C networks in order to help them keep better
track of how their spam-sending nodes are doing.

A zombied system is enemy territory: nothing it does can be trusted,
nor can it be trusted to do anything it's told to do.

---Rsk

---

From: Franck Martin <[email-masked]>
Date: Tue, 18 Nov 2008 10:39:42 +1200 (ANAT)

----- Original Message ----- 
From: "John Levine" <[email-masked]> 
To: [email-masked] 
Sent: Tuesday, 18 November, 2008 10:35:10 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] actual possible improvements, was Email Postage 

Sounds good to me. 

R's, 
John

---

From: "Gerald Klaas" <[email-masked]>
Date: Mon, 17 Nov 2008 15:13:23 -0800

>>  It kills this model dead at any interesting message volume.

True for central authority of crypto cookies, or highly complex algorithms
that require significant CPU resources, but what if recipients issued and
tracked their own "crypto cookies" (stamps) that senders could obtain in a
standard automated method?

There are any number of ways that a cookie generator could make a verifiable
crypto cookie that's less than trivial but doesn't create huge tracking
overhead.  The recipient would need to balance their risk of accepting
duplicate cookies with the amount of resource they wanted to dedicate to
generating unbreakable cookies.   There would be no difference to the sender
between a weak crypto cookie or a strong crypto cookie as long as they
obtained one that the recipient accepts.

---

From: "David Nicol" <[email-masked]>
Date: Mon, 17 Nov 2008 17:17:38 -0600

>> ripple back to the end-user a message like:

time-warner does this currently.  Outbound to :25 is blocked on
residential service, and their smarthost will only accept so many
messages from one IP before 4xxing them with an informative message
stating the policy.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 18:39:19 -0500

> nor can it be trusted to do anything it's told to do.

Then I guess there's no hope. It's possible the response above was
generated by a zombied computer and not Rich Kulawiec.

But it does support one good principle of system administration which
is you really need to know what your system does normally in order to
recognize when it's acting abnormally.

You personally may have a really clear notion of how many messages
your machine should be sending normally per day or whatever, but a lot
of people probably have never really thought about it.

Now, as you suggest, we may run into some sort of Heisenberg
uncertainty principle where we can't trust any measurement.

But at least when one is shut off because their machine was sending
over 1,000 messages a day (a not crazy policy) they maybe won't sit
there drooling on your shoes wondering if that's too much or too
little.

Awareness of what's normal is useful.

And any large discrepancy with what the above box reports and what the
ISP claims (perhaps it's printed on your bill?) would indeed be cause
for further alarm (but it only says...hmm.)

But, yeah, I've dealt with rootkits.

Anyhow, WHAT'S THE HARM?

I mean what's your standard here, that there cannot exist a single
case in the universe where this information might be unreliable?

My suggestion is only that if a problem is volume (from zombied
end-user computers) perhaps it would be sensible to try to tell them
what their volume is, normally and otherwise.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 18:47:52 -0500

> this model dead at any interesting message volume.  Nice try, though.

Anyhow, again, based on that logic Amazon oughta start offering free
shipping for all orders and just print their own US postage stamps!

Whaddya think? Is it the trouble to do that which stops them? Or the
fear of getting caught?

And I do mean Amazon and other bulk email senders.

Spammers? Sure, they can try. They can try to forge DKIM headers, they
can try to forge SSL certificates...are there any boundaries here
other than striking keys?

I'm having trouble imagining any scheme I've ever seen or likely will
see which could possibly stand up to these sort of objections of
bottomless rootkitting, trivial cracking of all cryptographic
techniques, unbridled willful crime and fraud by multi-billion dollar
corporations...

And let me add that spam remains about the same problem as it was on
the day this group was created.

So what could trying to think of a new approach possibly distract
from?

Oh yeah, some confuse paper with results...

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 18:47:52 -0500

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 18:58:35 -0500

> at the perimter for a few hours when they occur.

Of course we do that sort of thing, almost exactly that.

But one gets a little frustrated when it's all of earthlink's (e.g.)
servers which are being blocked most of the time.

Occasionally we've had to put in exceptions allowing them thru so mail
customers want gets through.

Think about that: We have to put exceptions in to let their stuff
through when they are behaving at their worst and tripping these log
analyzers so much that customers are comlaining.

Here is a summary right this moment on one mail server, a few seconds
sample:

  Unknown Users By Host:
     20 webmail-srv1.servage.net
     15 bay0-omc3-s18.bay0.hotmail.com
     11 host.southwestecommerce.net.au
     10 mail4.ipbolaget.com
     10 hpsmtp-eml16.KPNXCHANGE.COM
     10 elasmtp-banded.atl.sa.earthlink.net
     10 blu0-omc1-s22.blu0.hotmail.com
      5 relay.esu9.k12.ne.us

I'm not sure who southwestcommerce.net.au is but it doesn't strike me
as a spam outfit, hard to say. No idea about ipbolaget, may well be
criminals. the k12.ne.us site is probably hijacked or just an open
relay. Servage??? Probably a hijacked host on their provider network.

The others are hotmail and earthlink.

lessee what hotmail is up to...well it looks like some kind of mailing
list looping and some of the addresses closed accounts so let's save
their privacy.

Earthlink, OH YEAH, direct hit, CUT+PASTE, as always:

Nov 17 18:33:35 pcls5 sendmail[13516]: NOUSER: tracer3 relay=elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]
Nov 17 18:33:38 pcls5 sendmail[13516]: NOUSER: tracer4 relay=elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]
Nov 17 18:33:41 pcls5 sendmail[13516]: NOUSER: tracer5 relay=elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]
Nov 17 18:33:44 pcls5 sendmail[13516]: NOUSER: tracer6 relay=elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]
Nov 17 18:36:49 pcls5 sendmail[19082]: NOUSER: trans1 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:36:52 pcls5 sendmail[19082]: NOUSER: trans10 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:36:55 pcls5 sendmail[19082]: NOUSER: trans2 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:36:58 pcls5 sendmail[19082]: NOUSER: trans3 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:37:01 pcls5 sendmail[19082]: NOUSER: trans4 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:49:58 pcls5 sendmail[12900]: NOUSER: trav2 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:50:01 pcls5 sendmail[12900]: NOUSER: trav3 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:50:04 pcls5 sendmail[12900]: NOUSER: trav4 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:50:07 pcls5 sendmail[12900]: NOUSER: trav5 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:50:10 pcls5 sendmail[12900]: NOUSER: trav6 relay=elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]
Nov 17 18:54:54 pcls5 sendmail[22047]: NOUSER: trader3 relay=elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]
Nov 17 18:54:57 pcls5 sendmail[22047]: NOUSER: trader4 relay=elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]
Nov 17 18:55:00 pcls5 sendmail[22047]: NOUSER: trader5 relay=elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]
Nov 17 18:55:03 pcls5 sendmail[22047]: NOUSER: trader6 relay=elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]
Nov 17 18:55:06 pcls5 sendmail[22047]: NOUSER: trader7 relay=elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 19:21:16 -0500

> obtained one that the recipient accepts.

But this would seem to converge onto a whitelisting or C/R scheme, no?

I guess it has the added advantage of some confidence that the sender
is who they say they are since they're presenting your stamp.

 (and no, I'm not so quick to try to smash an idea by positing
 wide-open cryptographic permeability.)

If you tracked your own cookies you could spot duplicates and take
whatever action you saw fit.

I still lean towards trying to create some sort of economic incentive,
it's been difficult to get sites to buy into schemes unless they had
some other clear advantage other than possibly stopping someone else
from spamming.

Here's a question which is almost isomorphic:

  How many big commercial sites will do challenge/response with
  customers? Any?

I really don't know, I've never thought to ask before just now.

But there is some parallel in acceptance threshold between
user-generated cookies and a C/R system, no?

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 18 Nov 2008 00:27:54 -0000

>Whaddya think? Is it the trouble to do that which stops them? Or the

Both, I expect.  Oh, and Amazon does print its own postage stamps.

On the other hand, I would think it was painfully obvious to anyone
who thought about it for a few minutes that if spam were all sent by
large easily identifiable organizations such as Amazon, it would be a
lot easier to deal with.

>So what could trying to think of a new approach possibly distract

New approaches would be great.  Recycling old ideas that are known not
to work and telling people to do something different when they point
that out, yet never having anything different to suggest is not so
great.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 20:02:16 -0500

> Both, I expect.  Oh, and Amazon does print its own postage stamps.

You know what I meant, we were talking about counterfeiting.

We (World) print our own postage stamps too! On a legal meter.

 > large easily identifiable organizations such as Amazon, it would be a

Ya know, the "painfully obvious" rhetorical ploy is starting to sound
like teens who say "ya know".

What should be painfully obvious is that I've said about a dozen times
now that the goal here is to treat all bulk emailers alike in an
attempt to create an economic incentive.

That is, dissolve the very notion of spam. You can only really have
"spammers" as we commonly see them in a system which is fundamentally
broken.

That is, give stuff away for free and don't be surprised that you have
to institute rationing.

But, of course, the problem then is how do we pay for the ration
system and its enforcement if it's all free?

Most free (on a per-use basis) things require govt enforcement to
prevent abuse. For example, national parks or highways. Which means
taxation. But no one is offering to tax the internet and return those
taxes to an enforcement agency analogous to state highway patrols or
park rangers.

One analogy I gave earlier was how the music biz was very economically
incentivized to stop all kinds of piracy and threw a lot of firepower
(i.e., $$$) at it. And most of that well within the timeframe of the
spam problem.

But email abuse, email being free, remains mostly in the realm of
volunteers. And not many at that.

Here's a dichotomy:

How much money is spent by legitimate companies blocking incoming spam
versus getting their own email through the spam-laden cloud?

My guess would be "huh? through the spam-laden...um, nothing really,
we fire and forget mostly other than a quick scan to try to avoid
really common filtering triggers."

Take this group as another example. How much effort in the mechanics
of distributing this group is spent on avoiding incoming abuse, versus
evading outgoing (delivery) problems?

Well, I realize it's not zero due to the smallish size of the group,
there's some stuff about N bounces and you're nomail and mailman might
attract someone's attention.

But do you see the asymmetry I'm getting at?

Most of the effort is avoiding unwanted incoming.

Now take the music industry. They have both. They pursue piracy, but
they also pursue online vending like iTunes. They have an economy, one
supports the other.

   AGAIN: I am REALLY not inviting a flamefest regarding RIAA et al
   and their tactics. As I said earlier a lot of what they were after
   was egregious and justified if you believe anyone has a right to
   any money at all, "offshore" sites offering entire tens of
   thousands of albums for a dollar each because they were simply
   pirated. Some of their stuff was over the top. But at least they
   were trying and making some unmistakeable progress even if you're
   uncomfortable with it. Now compare and contrast with spam...

 > that out, yet never having anything different to suggest is not so

I guess I don't accept the "known not to work" part.

I think we've somehow gone from a period when most people weren't very
aware of spam so XYZ won't work to a period where the things which
wouldn't work are now just old-hat.

Let's be honest, thus far, NOTHING works.

Maybe we should have a "spam appreciation" day and urge everyone to
shut off all the filters for 24 hours and see how much difference it
makes really.

To the end-users? I'd guess their spam load would go up some but
they're pretty much deluged already.

ISPs and other centralized resource managers would probably suffer
more because a lot of what they block isn't going into anyone's mail
box ever, for example all those dictionary attacks and "no such user
floods". That'd strain bandwidth etc but ultimately have little effect
on end-users.

Anyhow, as far as I can tell the tone hasn't really changed from my
very first posting on the subject...it can't work...here's my straw
man reason why...etc etc etc. Then it sort of strayed to "ok, maybe
that's not why it won't work, but I know it won't work anyhow!"

And now we're heading straight to: I am losing patience making up
straw men as to why it won't work...IT WON'T WORK SO STFU OK?

Well, actually it has changed a little, I think some got tired enough
of the instaneous rejections and mob mentality that they began to
think about the possibility in a more positive way.

As the song goes, money makes the world go 'round.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 20:02:16 -0500

Here's a dichotomy:

-- 
        -Barry Shein

---

From: David Wall <[email-masked]>
Date: Mon, 17 Nov 2008 17:45:07 -0800

The post office can do postage because it alone offers the service and 
can verify the postage, whether you print it or not.

In email, how will this work?  Who does the verification?  If it's the 
recipient system, this is NOTHING LIKE postage, which is verified by the 
sending transport.   If it's the sending system in email, then as a 
spammer, I'd just not do that check.  The post office provides a 
centralized service, whereas email goes about its business without any 
such centralization or agreements between POs of different countries.  
Same goes for telephone service that was used before as a poor analogy.

You keep saying they are all arguments against postage are "strawmen," 
which itself is tiring of you, but why don't you do a bit more research 
on it and propose something substantially thought out and then we can 
discuss it. 

Clearly these pointless emails we're sending are not moving the idea 
forward in your opinion, and certainly they are not in mine, so more 
details need to be worked out before you bring it up for discussion.  
Nobody builds consensus or a new standard through point/counterpoint 
email exchanges with zero details and no blueprint spec.  Some real work 
should be done first, making a reasoned proposal that others can then 
review and consider its merits.  The best standards are ones that are 
shown to work in practice first, not in advance.  There are many good 
ideas, especially standards created before being built, that turn out 
less than stellar in practice or worldwide acceptance (WEP, much OSI, 
CORBA....).

And like my company does, there are lots of messaging platforms that 
work well and have no spam/virus/bot issues and are in the marketplace 
now.  These are not international standards (yet?) and certainly are not 
replacements for today's email.  But work progresses....

David

---

From: David Wall <[email-masked]>
Date: Mon, 17 Nov 2008 17:45:07 -0800

David

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 21:49:08 -0500

> can verify the postage, whether you print it or not.

You'd better tell that to fedex, UPS, DHL, etc.

But what are you saying, that it's impossible to generate a key which,
to a high degree of probability, can be verified as authentic to some
purpose? That's all a stamp is.

 > sending transport.

Well, if you look back I didn't originally use the term "postage" but
others did and the analogy was comfortable enough in terms of someone
pays to get a message delivered so I ran with it.

So it's SOMETHING LIKE postage.

 >  If it's the sending system in email, then as a 

Well, if I bought the right to generate keys in a certain range and
affix those keys to email and you had an interest in only accepting
email (say, outside of your private whitelist) which had verifiably
authentic keys, to a reasonable degree of authenticity, that's
similar.

The "post office" as you're describing it is in this case a mixture of
the issuer of the keys (kinda like SSL CAs) and the software the
end-user or receiving system can run to verify those keys (kinda like
browsers checking SSL certs.)

Yes, it's much more highly automated than physical post offices. But
that would seem to be a requirement and a feature, not a bug.

 > You keep saying they are all arguments against postage are "strawmen," 

No, I said the strawmen were strawmen.

Like that this wouldn't fly because grandma wouldn't pay for it and I
pointed out (again) that in my scheme I wouldn't charge grandma, only
large bulk users, so that's a (dare I say it again) straw man. That
is, an objection based on a mode of operation I never proposed, and
specifically disavowed several times.

 > on it and propose something substantially thought out and then we can 

I am sorry if you're getting tired.

But you know what gets really tiring? Meta-discussions about whether
or not something should be discussed. I daresay that's what way more
than half of the volume on this topic is about.

It's common because talking about whether or not to talk about
something is so much easier than actually adding anything useful to a
discussion.

There's just something in some people that when they sense the topic
has turned to whether or not to discuss something they get energized
and begin posting and posting on that.

It's so much easier and less personally risky than substantive
discussion.

I mean, who can tell you you're factually wrong and ignorant for
saying STFU? Not much risk in that!

And the beauty is the original topic starts to actually feel tiring
because of all the wading thru the meta-discussion.

 > forward in your opinion,

Au contraire, I think a lot has been discussed and kicked around.

What's mostly been challenging is some simple meeting of the minds on
whether or not charging bulk senders based on usage would be effective
in combatting spam, as a concept, rather than laying out questionable
algorithms and then showing that they're questionable or debating the
moral risk.

 > and certainly they are not in mine, so more 

Is that a consistent standard of discussion or is that only for ideas
you personally don't like?

Maybe what you need is a mail filter of some sort rather than a bully
pulpit. Or would not seeing the email on this topic be insufficient,
it is only changing my behavior which satisfies?

 > less than stellar in practice or worldwide acceptance (WEP, much OSI, 

Yeah but this is a research group not a standards group.

I think I now understand your objection. Maybe you need to unsub and
wait until a STANDARDS group arises?

See, this research group exists because spam and related is a
vexatious problem and good ideas are, well, few and far between.

A *standards* group like WEP or OSI (OSI? Did you really offer OSI as
a positive example???) et al is mostly a general agreement on what is
to be accomplished, such as "we need to encrypt wireless packets", and
then a process of agreeing on things like header formats, bit and
integer flags, state diagrams, those sorts of things.

It can be challenging, but it's a far different beast, it's
engineering not research.

Engineers mostly tinker together well-understood pieces to solve
well-understood problems to meet various cost, time, functional, and
performance metrics. Researchers tackle problems with hard unknowns.

To continue with your example, at the outset pretty much no one doubts
that encrypting wireless packets is possible, they just have to agree
on formats and some details. Brainstorm a little on future
expandability, etc.

Now, compare and contrast to stopping spam at least to a degree that
we no longer feel any urge to talk about it.

No one here knows if it's possible in general. We know we can stop one
spam, two spams, ..., N spams. But enough spams that it ceases to be a
problem? No. And no obvious path to how to do that.

That's a far cry from how many bits for addressing or length and what
sort of flag values we define.

Anyhow, this isn't a standards group. If you want to be involved with
a standards group you should by all means find one and jump in.

I suppose the other alternative is to try to limit discussion to
things we can fully understand like what should be the format of a
DNSBL return message, but that wouldn't be research, it'd be a
standards effort and there ought to be a standards group that sort of
thing is quickly moved off to and maybe that's where you'd be more
comfortable. Don't get me wrong, it's honest work.

 > replacements for today's email.  But work progresses....

So, you have some vested interest in all this. Good. So do I. But
perhaps from different ends of the spectrum, no?

So, tell me, if we could magically create and enforce a usage charge
for bulk sending how would that affect your company's products and
markets?

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 21:49:08 -0500

-- 
        -Barry Shein

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 17 Nov 2008 22:05:59 -0500

> case in the universe where this information might be unreliable?

There's no real harm, but there's no real benefit either.  The same
people who have ignored warnings not to click on everything that's 
shiny will ignore this warning too.

And spammers, well, spammers have long since demonstrated that they'll
innovate when something becomes sufficiently widely adopted to make it
worth their trouble.  So if this tactic was tried by only one ISP --
maybe not.  But if it was picked up a dozen major ones and included
in several significant MTAs or something like that, then it'd probably
be on their radar as worth dealing with.

---Rsk

---

From: Seth <[email-masked]>
Date: Mon, 17 Nov 2008 22:14:44 -0500 (EST)

> Whaddya think? Is it the trouble to do that which stops them? Or the

You do realize that it's a felony to counterfeit postage stamps.  It's
at most a violation of contract to re-use e-postage, and Amazon
probably has bigger lawyers.

> Spammers? Sure, they can try.

They can buy a stamp and keep on re-using it.

> I'm having trouble imagining any scheme I've ever seen or likely
> will see which could possibly stand up to these sort of objections
> of bottomless rootkitting,

Real estimates are in the tens of millions of zombies.

> trivial cracking of all cryptographic techniques, unbridled willful
> crime and fraud by multi-billion dollar corporations...

You're the one who introduced Amazon.  The rest of us are talking
about Joe Spammer from Estonia.

Seth

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 22:41:46 -0500

> shiny will ignore this warning too.

I just don't know. If your email access gets cut off at 1,000 msgs/day
and you see you're at 971 and you only remember sending 4 and you got
cut off before for this and it was a virus....

Anyhow, we can't really even ponder limits w/o feedback to the end
user, but it's really just an implementation feature and out of our
purview. I suppose it wouldn't hurt to remind implementers that
compromised machines are hard to...whatever.

 > be on their radar as worth dealing with.

Ok, we agree the problem is hard. That's why we're here, nicht wahr?

But as I said earlier, as one example, hard cryptography is hard to
crack, other than via social engineering perhaps.

And other mechanisms in the realm of spam and email abuse (e.g., DKIM)
rely on cryptographic methods for at least part of their effect.

So just positing that whatever it is spammers will get around it as a
given isn't adding much, and may not even be true.

But recognize that this is one reason I am interested in adding an
economic component. Spammers might be able hijack NSA's mail server,
but there's not a lot they can do when jack-booted SWAT members kick
in the door and yell "KISS DIRT OR KISS THIS!"

And it seems to me that economic incentives are more likely to lead to
the latter where (ahem) warranted.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 23:06:54 -0500

> probably has bigger lawyers.

At this point in time, but violation of contract (and maybe criminal
fraud) are a LOT more than we have now.

And why do you imagine Amazon (e.g.) would want to counterfeit email
postage and challenge it in court?

I thought the whole point is that it's in their interest.

It's kinda like Amazon counterfeiting SSL certs, they rely on SSL
certs heavily right? And inserting a CA when they have no permission
to do so???

I guess they could do it and even win in court and kick the stuffing
out of the CA who challenged them but...why? Why would they do that?

Isn't it in their interest to play the game? Isn't it in their
interest to participate in something of minimal cost which might do
damage to spammers?

Isn't spamming to Amazon et al kinda like people being able to fill
your mailbox with tons of unpaid for junk and their stuff which they
paid for gets lost in the mess? Wouldn't they prefer to pay for
postage and that everyone else had to also? Isn't it the postage which
pays for enforcement of the postal rules like (US) it's illegal to put
anything into a mailbox, other than outgoing mail where permitted,
unless it's gone through the post office?

Do we all agree that an accepted characteristic of virtually all spam
is their inability to pay for legitimate advertising channels?

I don't think selling herbal viagra will pay for a billion honest
email messages a day. Even if it was only, I dunno, $1,000/day.

But what Amazon does could probably pay for $1M/day easily, and be
well worth it if it sharply increases their response rate.

Of course that's the hard part.

 > They can buy a stamp and keep on re-using it.

Well, that would be an inferior scheme wouldn't it?

If DKIM was designed so the sender key was always 16 ones then there'd
be real problems there also...phishers could probably tag their
headers with 16 ones also.

BUT that wouldn't be a very good design would it?

Anyhow, there are ecurrency methods which claim to attack this
problem.

And I could imagine social engineering methods, rewards, blacklists,
LEOs, etc.

I hate proposing specific designs at this point but maybe a more
concrete f'rinstance would help:

MTA's can check DNSBLs and similar now. They could, by a similar
mechanism, check a "stamp". Like credit card numbers the stamp could
indicate which authority to check with (the first four digits of a
credit card is the bank identifier.)

Something like that would be enough to detect most duplication, and
we'd even know who handed it off. If it's a crook, unknown, ok, it
just gets discarded, yay, spam defeated!  If it's Amazon, it gets
noted and could be the basis for objection and enforcement.

 > Real estimates are in the tens of millions of zombies.

I tell people this all the time. They never believe me either.

But I also claim that some of that zombie problem has to be attacked
by other means tho it's good whenever it can be frustrated at this
level.

Economic incentives could accelerate that.

 > about Joe Spammer from Estonia.

Yeah, but if you're trying to create an economic incentive for
enforcement etc you start with the Amazons of the world, not the Joe
Spammers.

As I said before: Why have RIAA et al been so effective where
anti-spam measures haven't?

Money.

Isn't that why DKIM is aimed at the banks etc of the world and not Joe
Spammer per se? The banks have an economic incentive to have their
email authenticated. The hope is that the Joe Spammers then drop off
the face of the earth, at least in that realm.

Thus far, however, we don't know if DKIM will work Not
technologically, on paper, but to solve any actual problems. As I said
there's all that sticky stuff about reputation systems etc.

-- 
        -Barry Shein

---

From: Seth <[email-masked]>
Date: Mon, 17 Nov 2008 23:15:29 -0500 (EST)

Barry Shein <[email-masked]> wrote:

> But what are you saying, that it's impossible to generate a key
> which, to a high degree of probability, can be verified as authentic
> to some purpose?

Verified by whom, and why should they bother?

The Post Office verifies the stamps, because it sells them, and uses
them to ensure that you paid for its service.

> Like that this wouldn't fly because grandma wouldn't pay for it and
> I pointed out (again) that in my scheme I wouldn't charge grandma,
> only large bulk users, so that's a (dare I say it again) straw man.

I receive one message at a time.  How do I know if it's from grandma
(so I don't need to look for a stamp), or a bulk sender?

> What should be painfully obvious is that I've said about a dozen
> times now that the goal here is to treat all bulk emailers alike in
> an attempt to create an economic incentive.

I do _not_ want to treat all bulk emailers alike.  When American
Express sends me email, I want to receive it.  When Joe 419 sends me
email, I want not to receive it.

If I charge American Express, I'm not going to get the email I want
(or they'll charge me more, also undesirable).

If I charge Joe 419 but not grandma, he'll use grandma's infected
computer to send me email.

Seth

---

From: der Mouse <[email-masked]>
Date: Mon, 17 Nov 2008 23:32:44 -0500 (EST)

> large easily identifiable organizations such as Amazon, it would be a

Indeed, the subset of spam that, once upon a time, was sent by large
easily identifiable organizations _was_ a lot easier to deal with.

That is, in large part, why such a small fraction of spam today is sent
by large easily identifiable organizations.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Barry Shein <[email-masked]>
Date: Tue, 18 Nov 2008 02:11:07 -0500

> Verified by whom, and why should they bother?

By the recipient, or maybe an upstream MTA. If I were a corporate site
and believed in the method I might toss bad email at the front lines.

Why bother? So you, or someone upstream from you, can reject mail
which doesn't have valid postage.

 > them to ensure that you paid for its service.

Ok. And you've never looked at a letter which seemed to be personal,
not obviously junk, and then glanced at the postage and noticed it was
17c bulk rate or whatever and just tossed it? Or maybe turned it over,
companies which do that often put the return address on the back flap
so it looks like personal mail on the front? I do that all the time,
toss bulk rate junk mail w/o opening tho the other day I did find a $1
bill in one. Skinnerian intermittant reinforcement...the bastards!

But paper email is often more obviously junk, it usually screams junk,
glossy, pictures of starving little children or fancy wine bottle
openers, odd-sized, your name misspelled, mysterious phrases like
"Enjoy The Rewards of a Lifetime Right From Your Own Home!" whatever
*that* means, etc.

Email is more subtle. Knowing something about what the sender was
willing to pay to send it to you could be useful.

 > (so I don't need to look for a stamp), or a bulk sender?

Whitelisting?

I see a "stamp" as mostly a way to reject email for lack of
one. Beyond that you would use your usual methods.

 > email, I want not to receive it.

Well, and I say if this were adopted AMEX will put legitimate postage
on their email, Joe 419 won't. That's useful.

 > computer to send me email.

You're not the one doing the charging in the scheme I'm describing but
maybe you meant that generically, if ONE charges AMEX (any One)...

As to charges to Amex I doubt it'd be any more of any issue than Amex
having an SSL cert on their web site.

Does their paying for an SSL cert bug you?

As to grandma's infected computer we assume Joe 419 needs to send a
lot of email to be a problem, this sort of scheme puts some small
value on email which grandma can live with (e.g., 1,000 msgs/day free)
but Joe 419 cannot live with.

I'm just curious if anyone knows: Has Vista made *any* dent in the
zombie infection rate? Is it significantly harder to infect a Vista
system? It seems like all the "Are you sure?" pop-ups would at least
slow down the infected mail script stuff but I don't know if anyone
has an estimate yet, and I realize that day zero bugs keep popping up.

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 18 Nov 2008 11:32:36 -0000

>standard automated method?

You're suggesting that each sender has to negotiate with each recipient
before it can send mail?  Man, if there's a faster way to kill e-mail,
I don't know what it is.

>generating unbreakable cookies.

The issue isn't counterfeit stamps, it's real stamps being used more
than once.  The only way we know to prevent double spending is to have
a bank that remembers which ones have been spent and cancels them in
real time as requests come in.  That turns out to be an extremely
difficult database problem, high speed consistent updates.  We have to
assume that spammers will be as hostile as possible, so they'd buy a
hundred stamps, than mailbomb you with a hundred thousand messages,
each of which had one of the hundred genuine stamps.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 Nov 2008 12:23:41 +0000

> but you know nothing else about?

Well, there's a bunch of top level domains that I'd be happy to whitelist 
when I see a dkim or spf pass, like ".gov", ".gov.uk", .ac.uk, .coop. All 
on the basis that registration of domains is not cheap and easy, and that 
it should be relatively easy to find a sysadmin to speak to if I see abuse.

Of course, I'd still subject their traffic to virus testing.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 Nov 2008 12:23:41 +0000

---

From: "David Nicol" <[email-masked]>
Date: Tue, 18 Nov 2008 08:30:55 -0600

On Mon, Nov 17, 2008 at 9:14 PM, Seth <[email-masked]> wrote:
>
> You do realize that it's a felony to counterfeit postage stamps.

http://www.illegal-art.org/print/popups/deluna.html

-- 
"I am still floating in the clouds. Obama is our first human services
worker in the White House! I have lots of hope now for the future for
my children and yours." -- Dr. Iris Wilkinson
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: John Leslie <[email-masked]>
Date: Tue, 18 Nov 2008 11:55:12 -0500

> Of course we do that sort of thing, almost exactly that.

   This is a tactic _many_ ISPs have considered, and a good number have
implemented. It, of course, cannot fully protect against dictionary
attacks, because a dictionary attack can be distributed...

> customers want gets through.

   Indeed, Earthlink is one of the ISPs (by no means the worst) that
sends significant amounts of both abusive traffic and wanted traffic.
IMHO, Earthlink _does_ make efforts to limit abusive traffic.

   Earthlink _cannot_ avoid sending some abusive traffic. The question
is, what balance of good traffic to abusive traffic will receiving
SMTP servers tolerate? That, IMHO, is a balancing act where no two
receiving domains will have exactly the same parameters.

> analyzers so much that customers are comlaining.

   My point, exactly!

>...
>...

   All very familiar to ISPs... :^(

   But perhaps not familiar to other readers of this list.

   I'd like to suggest a few principles:

1) ISPs like Barry have _really_ helpful information they could share;

2) neither Earthlink nor World can afford to have humans in the loop;

3) it is not helpful to argue which of them to blame;

4) there _could_ be value in an automated way to tell Earthlink about abuse;

5) any use of <[email-masked]> cannot serve that purpose;

   Now, a question for ASRG:

- can we design a _useful_ reporting scheme for, e.g., dictionary attacks?

--
John Leslie <[email-masked]>
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Tue, 18 Nov 2008 12:37:00 -0500 (EST)

> 5) any use of <[email-masked]> cannot serve that purpose;

Why not?  I can't think why an "automated way" such as (4) mentions
couldn't be carried on top of email to [email-masked].

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: John Leslie <[email-masked]>
Date: Tue, 18 Nov 2008 13:05:19 -0500

der Mouse <[email-masked]> wrote:
> [John Leslie wrote:]

1) <abuse@anywhere> is spammed too heavily

2) <abuse@earthlink> necessarily has earthlink-specific processing

   For a reporting procedure to be practical, we need to avoid the
N * M problem.

---

From: der Mouse <[email-masked]>
Date: Tue, 18 Nov 2008 13:46:18 -0500 (EST)

> 2) <abuse@earthlink> necessarily has earthlink-specific processing

Neither is relevant, I believe.

(1) is irrelevant because random spam will not fit the format of these
automated reports; if spamming fake reports becomes attractive enough
for it to be a problem, whatever other mechanism carries them will have
exactly the same problem.  (If the reports are crypto-signed to deal
with report forgery, this can be done over email just as much as it can
over some other channel.)

(2) is necessarily true, since any abuse-report-recipient must
necessarily be doing some kind of recipient-specific processing.  But
it's also irrelevant; there's no reason emailed automated reports can't
be shipped off to whatever processing the putative other transport
performs, rather than going into the main abuse@ queue.

> For a reporting procedure to be practical, we need to avoid the

I don't see why carrying them over email produces an N*M problem in any
way that any other transport doesn't - that is, I don't think this
(regardless of how true or false it is) has anything to do with using
mail to abuse@ as the transport.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 18 Nov 2008 11:59:18 -0700

> but you know nothing else about?

Probably not much.  But if you know only a /little/ about them -- and can be
certain that the "who" you know about is the "who" who sent the message (as
measured by a particular authenticatable identifier), there's a lot you can
do.

For example, I suspect everyone here is familiar with the forwarding
problem: forwarders or mailing lists may inadvertently forward spam, and ISP
reputation systems assume the forwarding IP is a spammer.  But if the
forwarder signed the message, and the ISP could do a VBR (or similar) check
to confirm that the forwarder really is a member of the "forwarder" class
(as determined by some sufficiently trustworthy external process), then the
ISP may choose to apply a different reputation algorithm.

This is one of those revolutionary ideas that a lot of people have thought
up over the years, and failed to implement because the identifier wasn't
sufficiently trustworthy.

Now, to be sure, the key could be stolen or the forwarder could get hacked
or all sorts of other things could happen which are outside of the scope of
DKIM or anything similar.  But that's not a problem for modern reputation
systems (or even SpamAssassin), where it's possible to give a positive
weight without giving a free pass forever.  If the behavior changes, the
reputation changes -- and the alternate algorithm or positive weight will be
overridden.

---

From: "David Nicol" <[email-masked]>
Date: Tue, 18 Nov 2008 13:22:59 -0600

> mail to abuse@ as the transport.

Statistical methods can identify a "normal" level of bad addresses and
issue infrequent (no more than daily) reports pointing out spikes.  I
imagine that were World to set that up, earthlink would find it
helpful.  I may be naive.  For aggregation, a standard reporting
format would obviously be cool, but attempting to define that by
anyone other than the parties engaged in the sharing of said
statistics would undoubtedly do something wrong, and why doesn't
earthlink cook out the information from their own logs if they care?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: John Leslie <[email-masked]>
Date: Tue, 18 Nov 2008 18:05:48 -0500

der Mouse <[email-masked]> wrote:
> automated reports;

   Only true for _some_ formats...

> if spamming fake reports becomes attractive enough for it to be a
> problem,

   That's not the point, really: even without _any_ email intending
to fool the report parser, the <abuse@> account would have to parse an
arbitrarily large amount of junk looking for things which _intend_
to be a report. I don't know what Earthlink's daily load of <abuse>
email is, but I wouldn't be surprised if it exceeded 1,000,000.

> whatever other mechanism carries them will have exactly the same
> problem.

   Not "exactly", unless the design is foolish. It could, for example,
include a registration mechanism allowing packet filtering to regulate
the load...

> (If the reports are crypto-signed to deal with report forgery, this
> can be done over email just as much as it can over some other channel.)

   There are other methods to deal with forgery; and crypto-signing
to validate email is a heavier load even than crypto-signing of most
other protocols.

> necessarily be doing some kind of recipient-specific processing.
> But it's also irrelevant; there's no reason emailed automated
> reports can't be shipped off to whatever processing the putative
> other transport performs, rather than going into the main abuse@
> queue.

   If we were only ever implementing _one_ pairing of ISPs, this
is true enough. But for this to be useful to Earthlink, they must
be able to receive reports from more than one ISP.

   OTOH, for this to be useful to World, they need to be able to
report to more than one origin ISP. Does Earthlink define the format,
or does World?

> I don't see why carrying them over email produces an N*M problem
> in any way that any other transport doesn't - that is, I don't
> think this (regardless of how true or false it is) has anything
> to do with using mail to abuse@ as the transport.

   The N * M problem is much the same with or without email being
the transport, true; but there are rather too many ISPs that decline
all <abort@domain> email. I see no reason to add "solving" that
issue to the task...

   But there's another issue entirely that makes <abuse@domain>
the wrong tool -- the Dictionary Attack comes from IP addresses,
not domains.

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 18 Nov 2008 19:00:38 -0500

On Tue, Nov 18, 2008 at 06:05:48PM -0500, John Leslie wrote:
> I don't know what Earthlink's daily load of <abuse>

The best way to avoid needing to deal with a million abuse reports a
day is not to permit one's operation to engage in actions that will
trigger a million abuse reports a day.

(Considering low abuse reporting rates, 10e6 a day implies a LOT of abuse.)

Which is my way of saying that the wrong question is in play here.
It's not "how do you deal with all those abuse reports?", it's "what
can you do to remove the need for anyone to file those?"

---Rsk

---

From: der Mouse <[email-masked]>
Date: Tue, 18 Nov 2008 19:54:40 -0500 (EST)

>> (1) is irrelevant because random spam will not fit the format of
>> these automated reports;

True.  I was implicitly assuming that email-carried reports would
deliberately use a specific format designed for the purpose; if it is
non-idiotically designed, the chance of an accidental false positive
will be so low as to be ignorable.

> That's not the point, really: even without _any_ email intending to
> fool the report parser, the <abuse@> account would have to parse an
> arbitrarily large amount of junk looking for things which _intend_ to
> be a report.

Yes, but almost all of the non-reports will fail the first, cheapest,
check - if the format is well-designed for the purpose, the cost of
that first check will be down in the noise compared to the cost of
handling the mail at all.

> I don't know what Earthlink's daily load of <abuse> email is, but I
> wouldn't be surprised if it exceeded 1,000,000.

So?  I'm with rsk on this one.  Either they need to get more active
against abuse, or they have such a huge user base that supporting that
kind of abuse@ load is just a part of being that big.  (At 1e6 a day,
given typical abuse-to-report ratios, I'd say the latter would require
something approaching a majority of the planet's population as a user
base.)

> include a registration mechanism allowing packet filtering to
> regulate the load...

And?  The same list of registered sending IPs (or whatever) can be
applied to email, as that very cheap first check I mentioned above.

> [...] crypto-signing to validate email is a heavier load even than
> crypto-signing of most other protocols.

Only if you're stupid enough to compute a signature for a substantial
fraction of the unsigned mail.  You shouldn't even be considering doing
any serious crypto until the message has passed all the cheap tests.
(Furthermore, in the presence of prearrangement, crypto signing can be
made quite cheap, by choosing different crypto.)

>> [T]here's no reason emailed automated reports can't be shipped off
>> to whatever processing the putative other transport performs, rather
>> than going into the main abuse@ queue.
> If we were only ever implementing _one_ pairing of ISPs, this is true
> enough.  But for this to be useful to Earthlink, they must be able to
> receive reports from more than one ISP.

That's what standardized formats are good for.  Mail can be sidetracked
when a known format is recognized even when others use the same format.

> OTOH, for this to be useful to World, they need to be able to report
> to more than one origin ISP.  Does Earthlink define the format, or
> does World?

Doesn't matter, as long as everyone involved agrees on it.  I suspect
the first implementation out the gate will more or less set the
standard, if the idea proves to be worth doing at all.

> The N * M problem is much the same with or without email being the
> transport, true; but there are rather too many ISPs that decline all
> <abort@domain> email.

I see no reason to care about them (well, assuming s/abort/abuse/).  If
they can't be arsed to handle abuse reports at the closest thing to a
standardized abuse-reporting address there is, I see no reason why
they'd suddenly get an attack of caring just because _these_ abuse
reports come in over a non-email transport.

> But there's another issue entirely that makes <abuse@domain> the
> wrong tool -- the Dictionary Attack comes from IP addresses, not
> domains.

That doesn't make abuse@ a wrong path; it just makes selection of the
domain you put after "abuse@" less than totally trivial.  But you have
_that_ problem with an idiosyncratic transport too.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Steve Atkins <[email-masked]>
Date: Tue, 18 Nov 2008 17:16:52 -0800

> something approaching a majority of the planet's population as a user

That number is likely a drastic overestimate.

Most of the abuse desks I'm familiar with, at big providers, are dealing
with <10k inbound messages a day, excluding feedback loops, before
removing any spam.

Cheers,
   Steve

---

From: "Richard Golodner" <[email-masked]>
Date: Wed, 19 Nov 2008 00:06:16 -0600

Rich K is asking the correct question that all op's should be asking
every day, what can be done to remove the need for all of the abuse reports?
Run a tight net and conform to the bcp's. We all know what works and what
does not. It is time that we look at our nets and identify the problematic
parts of the overall design and re-engineer them so they are under a greater
degree of control. We design and build out the topology, we should all have
had enough experience to address what we know will be problematic in the
network and do all that is possible to keep these problems to a minimum.
Having a system in place to help facilitate handling an inordinate amount of
complaints so that when things do start to break, we can explain how we will
fix it so that it does not remain a problem. Just a few late night thoughts.
	Most sincerely, Richard Golodner

---

From: "Richard Golodner" <[email-masked]>
Date: Wed, 19 Nov 2008 00:13:43 -0600

Hi Steve, could you help me to understand what a "feedback loop" is
and what it does as far as squashing spam is concerned. I am a Cisco
engineer, but work mostly on firewalls and switches. I have just started
working with mail admin and see what they deal with everyday. You could not
pay me enough to do the job of email admin. 
	If you have a second I would appreciate it. I tried searching on my
own and had a difficult time sifting through all that was presented during
my search.
				Most sincerely, Richard Golodner

---

From: SM <[email-masked]>
Date: Tue, 18 Nov 2008 23:04:19 -0800

>and what it does as far as squashing spam is concerned. I am a Cisco

http://mipassoc.org/arf/specs/draft-shafranovich-feedback-report-05.txt

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Nov 2008 10:10:36 +0100

> ISP may choose to apply a different reputation algorithm.

How would you compare such signing solution to an actual login? A 
forwarder may get a password for authenticating at your server going 
through an automated or semi-automated process much similar to the one 
implied to enroll in the forwarder class (or to signing up for 
feedback loops, for that matter.) SMTP AUTH can handle all SMTP cases, 
e.g. multiple recipients. This would enable working "live", thus 
encompassing, say, DNSBL and SPF, that would otherwise require their 
own arrangements.

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 19 Nov 2008 08:38:24 -0500

One of my responses hasn't shown up, but subsequent ones have, leading
me to hypothesize that perhaps there is context-sensitive spam filtering
in place on this list.  The message in question has message-id
[email-masked], and listed about a dozen fake antivirus
domains as part of one of its points.  if there's context-sensitive
filtering on this list, it should probably be turned off, as discussions
about spam tend to trip such filters.

---Rsk

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Nov 2008 15:35:18 +0100

SM wrote:
>> Hi Steve, could you help me to understand what a "feedback loop"
>> is and what it does as far as squashing spam is concerned. I am a
>> Cisco
> 

I've tried and summarized that in 
http://en.wikipedia.org/wiki/Feedback_Loop_(email)

Amendments are welcome

---

From: John Leslie <[email-masked]>
Date: Wed, 19 Nov 2008 10:29:58 -0500

> every day, what can be done to remove the need for all of the abuse

   Indeed, that is the question operators should ask themselves on any
day they deal with more than a handful of valid abuse reports. But that
is not what this list is for. This list is for research topics in spam
abatement.

> Run a tight net and conform to the bcp's. We all know what works and
> what does not.

   Well, I don't know _anything_ that works against spam _to_ <abuse>
resulting (I guess) from dictionary attacks on domains I manage by
clueless spammers. I myself receive few enough of these that I sort
all <abuse> email (for any domain) into yet-another-identified-spam
mailbox. I am not looking for advice on how to "improve" on this,
because it's well beyond 100:1 spam and I _want_ to empty my spam
mailboxes daily.

> It is time that we look at our nets and identify the problematic
> parts of the overall design and re-engineer them so they are under
> a greater degree of control.

   Myself, I don't feel that need -- I can't remember the last time
I had to deal with more than one arguably-legitimate abuse report
per day. But if anyone here wants to discuss _research_ into how to
do this better, I'm happy to discuss it.

> We design and build out the topology, we should all have had enough
> experience to address what we know will be problematic in the

   This is true of many smaller ISPs and IS managers; I'm not sure
if it's true of larger ISPs. Unfortunately, the failings of larger
ISPs create pressure on smaller ISPs and IS managers to "route
around" these failings. I like to believe there are things we could
do to make it easier for large ISPs to deal with these problems
themselves.

---

From: "Richard Golodner" <[email-masked]>
Date: Wed, 19 Nov 2008 10:03:11 -0600

Alessandro wrote on 11/19/2008:
"I've tried and summarized that in 
http://en.wikipedia.org/wiki/Feedback_Loop_(email)"

Allessandro, thank you for pointing that out to me and it does make things
much clearer for me to understand. Good job and well done!
				Most sincerely, Richard Golodner

---

From: Steve Atkins <[email-masked]>
Date: Wed, 19 Nov 2008 08:04:55 -0800

> http://mipassoc.org/arf/specs/draft-shafranovich-feedback- 

Not really.

That explains the ARF format, which is a (trivial) format for  
encapsulating
a copy of an email, along with a small amount of metadata, via mime in
another email. It's well-suited for feedback loops, and was designed for
use with them, but it's not one and the same.

In email circles a feedback loop is a service offered by an ISP that
allows people who send email to that ISP to receive (immediately
or on a regular basis) feedback from users of that ISP.

A simple example is AOL. AOL allows other network users to sign
up with AOL to receive feedback reports about email from a particular
IP address. If an AOL user receives email from that IP address and
clicks on the "This is Spam" button then AOL will, amongst other
things, send an email to the feedback loop subscriber telling
them "Someone clicked this-is-spam in response to this email"
and include a copy of the email.

That's how many of the current feedback loops - though there are
only maybe less than ten worth speaking of running right now. They
don't all work exactly that way, though. Some are based on domain
or cryptographic signature in the email, rather than IP address. Some
send a list of email recipients who have hit the TiS button, with no
sample email, rather than one report per recipient.

A de-facto standard for the reports that include a sample of the
email is ARF, which in turn is based on the format AOL originally
used, but it's not a requirement for being a feedback loop, just
a good idea.

SpamCop isn't generally considered to be a feedback loop, for
several reasons (not opt-in, reports not sent by the receiving ISP)
but it's often handled with the same software as "real" FBLs and
treated in just the same way. I tend to call it a pseudo-FBL.

You can imagine FBLs that are not based on user reports, but
are instead based on, maybe volume or automated virus detection
and so on. (You don't need to imagine, they do actually exist on
a small scale). These are useful things, sure, but I consider
them outside the field of FBLs.

There's also aggregate feedback from ISPs - the AOL report
card, SNDS from Hotmail and so on - sent to the same people
that are signed up to the appropriate feedback loops. These
are useful parts of the FBL ecosystem, but not usuallt what people
are referring to when they talk about the feedback loop.

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Wed, 19 Nov 2008 08:09:13 -0800

On Nov 19, 2008, at 6:35 AM, Alessandro Vesely wrote:

> I've tried and summarized that in http://en.wikipedia.org/wiki/Feedback_Loop_(email)
>
> Amendments are welcome

Mmm. ARF != Feedback loop.

The ARF content should be pulled out and put on the Abuse Reporting  
Format
page (which is linked to, but doesn't exist yet) and the Feedback loop  
page
should reference it.

Then the remaining content should talk about feedback loops in more  
general
terms, without referencing ARF.

Cheers,
   Steve

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 19 Nov 2008 08:09:19 -0800

> before it can send mail?  Man, if there's a faster way to kill e-mail,

Yes, that is what I'm suggesting.  But since it's up to the recipient to
determine if they want to enforce it, I don't see how it would "kill
e-mail".  Nobody would force a sender to apply a "stamp", and recipients get
to choose whether or not they require one before allowing an otherwise
unknown sender into their Inbox.    ( Although this should be an
implementation detail, I would expect that most implementations would
whitelist the user's contact list, so a large number of "wanted" messages
probably wouldn't require stamps anyway. )

What I'm really suggesting is that there should be a standard for
the exchange of "stamps", but that standard should not specify the
algorithms required to frank or verify stamps.
 Such a standard method would allow senders to determine if a recipient
requires a stamp, and if so, define how to obtain one, and would include a
standard method for packaging a stamp into an e-mail message.

In practice, it would be totally up to a recipient whether they insist on a
"stamp".  It would also be totally up to the recipient to determine how
their stamps are generated and verified.

> each of which had one of the hundred genuine stamps.

Yes, preventing "double spending" or "duplicate cookies" is a difficult
problem, but I don't see that it is necessarily a giant database problem, or
that a single solution is required for all recipients. Certainly, if the
algorithms for franking and verifying "stamps" are left to the
implementation, there will be some that are formulaic and do not require a
database at all.

I believe we should talk about a very limited standard method for how stamps
might be exchanged, i.e., how does a sender know that a recipient requires
one?  How is one acquired?  How is one attached to a message?  Then let the
franking and verification routines and algorithms evolve within specific
implementations.  If a sender knows that a recipient requires a stamp and
knows how to get one and how to attach it to a message, there's no reason
they need to know how the recipient generated the stamp or is planning to
validate it.  The recipient can choose any generation/verification algorithm
that works for them, complete with all the risks and rewards of balancing
their level of effort against the algorithm's effectiveness.

True, a giant database might be the approach most effective at preventing
duplicate spending, but it is certainly not the only approach to generating
and verifying "stamps".  Some recipients might decide to use time-dependent
stamps, or sequence dependent stamps, or stamps based on an elliptic
formula, etc.  If the standard is only about the *exchange* of stamps, then
recipients get to evaluate the cost and benefits of whatever
generation/verification implementation they choose and change it over time
to find the cost/benefit balance that works for them.

 Gerald

---

From: mathew <[email-masked]>
Date: Wed, 19 Nov 2008 10:22:00 -0600

> They can buy a stamp and keep on re-using it.

Just like people can buy an Amazon gift voucher (which is simply a code they
enter on Amazon's web site) and keep re-using it?

Come on, be serious. One-time-use tokens are a commonplace tool used all
over the Internet. Don't pretend they don't exist or couldn't be used for
e-postage.

mathew

---

From: Steve Atkins <[email-masked]>
Date: Wed, 19 Nov 2008 10:33:58 -0800

On Nov 19, 2008, at 8:22 AM, mathew wrote:

> Just like people can buy an Amazon gift voucher (which is simply a  
> code they enter on Amazon's web site) and keep re-using it?
>
> Come on, be serious. One-time-use tokens are a commonplace tool used  
> all over the Internet. Don't pretend they don't exist or couldn't be  
> used for e-postage.

You need to explain how a global epostage system scales, and scales  
reliably, before making that assertion.

Avoiding both a single point of failure and an N x M problem, while  
still having acceptable performance, using infrastructure and staffing  
that can be funded by stamps that are a "reasonable" cost is a minimum  
there.

Cheers,
   Steve

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 19 Nov 2008 18:50:15 +0000

> and include a copy of the email.

Most feedback loops are IP address based, but I've just read that AOL are 
intending to implement a dkim/domain based feedback loop.

<http://www.returnpath.net/blog/2008/11/aols-plans-for-domain-reputati.php>

---

From: "David Nicol" <[email-masked]>
Date: Wed, 19 Nov 2008 12:51:20 -0600

> are referring to when they talk about the feedback loop.

Thanks for the summary!  Does the draft standard include formatting of
the aggregate reports?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 19 Nov 2008 10:55:44 -0800

> reliably, before making that assertion.

Why?  One need not verify that the Pitney-Bowes postage meter is working, or
the Post Office has paper stamps in stock to know that their letter needs a
stamp and that if you had one it goes on the upper right hand corner of the
envelope.

>
> Avoiding both a single point of failure and an N x M problem, while still
> having acceptable performance, using infrastructure and staffing that can be
> funded by stamps that are a "reasonable" cost is a minimum there.
>

These questions do need to be answered for a particular implementation,
although there's no reason that all implementation details must be globally
identical.  That would only be necessary if all recipients were forced to
accept the same "type" of stamp.   Only the framework of how to recognize
the need for stamps and the method of affixing them to a message needs to be
global.  The rest of the questions related to required infrastructure and
risk of failure and staffing concerns should be answered by the
implementor, i.e., the recipient, by their choice of stamps they choose to
accept.

 Certainly, not every recipient places the same value on assured delivery of
messages, or would require the same level of effort for an unknown sender's
message to be delivered successfully, so how would we ever come to a
consensus of "acceptable performance"?  I suggest we separate the
discussion of how to "use" a stamp from the discussion of how
reliable/affordable/scaleable/secure stamp franking/verifying routines are.

Gerald

---

From: Steve Atkins <[email-masked]>
Date: Wed, 19 Nov 2008 11:00:32 -0800

> Thanks for the summary!  Does the draft standard include formatting of

No, they're human readable rather than being intended for automatic
consumption, and not always sent via email. SNDS, at least, allows
export of the raw data to CSV for further processing (and that seems
like exactly the right thing to do, to me).

Cheers,
   Steve

---

From: David Wall <[email-masked]>
Date: Wed, 19 Nov 2008 11:04:36 -0800

>  
> Why?  One need not verify that the Pitney-Bowes postage meter is 
> working, or the Post Office has paper stamps in stock to know that 
> their letter needs a stamp and that if you had one it goes on the 
> upper right hand corner of the envelope.
Yes, but the post office does. Otherwise we'd all print our own 
postage.  Again, postage is not a great example because you buy stamps 
to pay for the services of the post office.  Email doesn't have such a 
clear "service provider" as many companies run their own email servers 
and thus an ISP does not provide them email.
>  
>
>
>     Avoiding both a single point of failure and an N x M problem,
>     while still having acceptable performance, using infrastructure
>     and staffing that can be funded by stamps that are a "reasonable"
>     cost is a minimum there.
>
>  
> These questions do need to be answered for a 
> particular implementation, although there's no reason that all 
> implementation details must be globally identical.  That would only be 
> necessary if all recipients were forced to accept the same "type" of 
> stamp.   Only the framework of how to recognize the need for stamps 
> and the method of affixing them to a message needs to be global.  The 
> rest of the questions related to required infrastructure and risk of 
> failure and staffing concerns should be answered by the 
> implementor, i.e., the recipient, by their choice of stamps they 
> choose to accept. 
If you can't validate the stamps, then who would care that they have 
stamps on them?  Affixing stamps is easy if there's no way for "someone" 
to tell me if the stamp is valid or just something any old party affixed 
like EVERY PHISHING SCAM out there does today.  There's no advantage of 
having a stamp if it's not reliable and meaningful and trusted.

>  
>  Certainly, not every recipient places the same value on assured 
> delivery of messages, or would require the same level of effort for an 
> unknown sender's message to be delivered successfully, so how would we 
> ever come to a consensus of "acceptable performance"?  I suggest we 
> separate the discussion of how to "use" a stamp from the discussion of 
> how reliable/affordable/scaleable/secure stamp franking/verifying 
> routines are.
If there's no value of having the stamp, then this will not reduce 
spam.  It will be like DKIM, SPF and other attempts to reduce spam, but 
will only be able to do so if email systems stop accepting email that 
doesn't have the more trusted characteristic.  DKIM and SPF are free to 
implement, yet they are not used in this manner, and S/MIME would 
support trusted digital certificates for email, all standards-based for 
years, yet it's not used. 

So why build a new "stamps system" that would cost somebody money 
(right?) and would require somebody to check them to make them useful if 
it has no more value than the existing solutions out there today?

David

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 19 Nov 2008 11:30:00 -0800

On Wed, Nov 19, 2008 at 11:04 AM, David Wall <[email-masked]> wrote:

>
>
> Why?  One need not verify that the Pitney-Bowes postage meter is working,
> or the Post Office has paper stamps in stock to know that their letter needs
> a stamp and that if you had one it goes on the upper right hand corner of
> the envelope.
>
> Yes, but the post office does. Otherwise we'd all print our own postage.
> Again, postage is not a great example because you buy stamps to pay for the
> services of the post office.  Email doesn't have such a clear "service
> provider" as many companies run their own email servers and thus an ISP does
> not provide them email.
>

You should print your own postage.  Not as a sender, but as the recipient.
It's up to you to the recipient to decide what the sender has to pay for the
postage, and how they require the sender to "pay".

> If you can't validate the stamps, then who would care that they have stamps
> on them?  Affixing stamps is easy if there's no way for "someone" to tell me
> if the stamp is valid or just something any old party affixed like EVERY
> PHISHING SCAM out there does today.  There's no advantage of having a stamp
> if it's not reliable and meaningful and trusted.
>

 If I printed and distributed my own "stamps", I know what's valid, but I
think that's beside the point.  What I'm saying is that the
conversation about franking and validation of "stamps" is premature to the
conversation of how stamps might be used.

There are a multitude of ways that stamps might be created and verified, as
the sender of a message, you shouldn't care whether I can accurately
validate the stamp, only that you know how to get one and affix it to a
message because you believe that I'll do something with it.

>     I suggest we separate the discussion of how to "use" a stamp from the
> discussion of how reliable/affordable/scaleable/secure stamp
> franking/verifying routines are.
>
> If there's no value of having the stamp, then this will not reduce spam.
>

I didn't say there is no value to having a stamp.  I'm saying that the
sender doesn't need to know how I, the recipient, generated a stamp or plan
to validate it.  Only that a sender needs to know that I require a stamp,
and how to obtain one.

>
> So why build a new "stamps system" that would cost somebody money (right?)
> and would require somebody to check them to make them useful if it has no
> more value than the existing solutions out there today?
>

That depends on your definition of a "stamps system".  The only thing I'm
suggesting is a standard format for stamps and how they are affixed to
messages.  No one would require senders to provide stamps, except possibly
the recipient.

True, to be useful, details need to be worked out on how recipients generate
and distribute "stamps", but those details aren't necessary to define a
format for using stamps, nor would I expect those details to remain static
over time.

I envisage a distributed "stamps system" where recipients (or their ISP's)
print and verify their own postage.

Gerald

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 19 Nov 2008 13:29:32 -0700

> encompassing, say, DNSBL and SPF, that would otherwise require their

The SMTP AUTH idea is an interesting idea, but seems to me as if it'd
require much more effort on the part of the receiving/authorizing entity.

I really do like the idea, though, and I think it'd be an interesting
research project for the ASRG to tackle.

(I'm not volunteering to manage it, though.)

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 19 Nov 2008 13:51:07 -0700

> <http://www.returnpath.net/blog/2008/11/aols-plans-for-domain-reputati.php>

I'm glad you found the article interesting.

Yahoo! has had an FBL based on DomainKeys for some years.  They were the
first and (until AOL's announcement) only ISP to do so.  (I worked there at
the time, and designed it.)

There are four really cool (in my mind) things about DK or DKIM domain-based
feedback:

1. feedback can be routed correctly even if the message was forwarded or
otherwise resent

2. feedback can be routed to different domain owners (or different report
recipient addresses) who send different domains through the same IP or set
of IPs

3. when a domain owner starts sending through new/different IPs, the
feedback follows

4. it encourages use of authentication (always a nice side benefit)

I'll be writing more about this stuff for the returnpath.net blog in the
near future.

---

From: Seth <[email-masked]>
Date: Wed, 19 Nov 2008 17:18:32 -0500 (EST)

> You should print your own postage.  Not as a sender, but as the

That will do outblaze, AOL, gmail, and msn some good.  Not so much for
the rest of us; how many senders will care about our relatively tiny
domains?

Seth

---

From: "David Nicol" <[email-masked]>
Date: Wed, 19 Nov 2008 16:21:45 -0600

> the rest of us; how many senders will care about our relatively tiny

Organize!  The senders will care when all the relatively tiny domains
require an ounce of Advengeium to deliver to their users.  Long tail.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Seth <[email-masked]>
Date: Wed, 19 Nov 2008 17:23:59 -0500 (EST)

> code they enter on Amazon's web site) and keep re-using it?

You'll note they buy it _from_ Amazon and use it _for_ Amazon.

That's fine for Amazon.  But other websites can't take Amazon gift
certificates, unless they have a deal with Amazon (in which case
Amazon does the validation for them).  This is a single point of
failure; but since they're Amazon certificates, it's acceptable for
Amazon to be a single point of failure.

Seth

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 19 Nov 2008 14:50:45 -0800

> the rest of us; how many senders will care about our relatively tiny

Exactly why we need a standard framework for the use of stamps.

Indeed, AOL, gmail and MSN could set-up such a system for use just between
themselves and benefit greatly from it.  But with a standard "stamp"
framework, you could choose to put up your own "stamp" generator.

So how does a sender know you require a stamp?  Where do they obtain one?
Once they've gotten one, how do they affix it to your e-mail (so that you
can filter on it)?   Those are the questions a standard should answer.

Personally, I believe that there should be a standard method for deriving a
URL from e-mail addresses.  That stamp generators should be placed at the
derived URL, and that affixing a stamp (retrieved from the URL) should be in
an "X-header".    That's clearly not the only possible approach, but the
beginning of the discussion I'd like to see.

Gerald

---

From: der Mouse <[email-masked]>
Date: Wed, 19 Nov 2008 18:30:50 -0500 (EST)

> That will do outblaze, AOL, gmail, and msn some good.  Not so much
> for the rest of us; how many senders will care about our relatively
> tiny domains?

Those to whom getting mail to us has value, of course.

There is a point of view from which we're already doing this to some
extent, only the postage takes a myriad of different forms, most of
them non-monetary (for example, one of the prices I impose is that the
sending host have fcrDNS).

I think the biggest problem is the perennial micropayment problem: if
every recipient site becomes a postage vendor, they must all be
handling something very much like money in some form....

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 19 Nov 2008 15:57:13 -0800

> sending host have fcrDNS).
That is my view, we already impose requirements on senders.  Why would
"epostage" be so much different?

I would estimate that the majority of stamp-generators would
be non-monetary.   I don't dare to guess what creative things people would
learn to check before kicking out a stamp.  Maybe it would check for fcrDNS,

maybe for a reciprocal ratio of incoming/outgoing from the domain, maybe
it's some DNSBL,
......  or maybe people would come up with creative ways to leverage
existing
payment systems.

In any case, you still need the basic framework for how a sender determines
a recipient's requirements, how to locate their stamp-generator, and how
to attach the stamp in a message.

Gerald

---

From: "Gerald Klaas" <[email-masked]>
Date: Mon, 17 Nov 2008 14:25:46 -0800

>> their own SSL cert, or other such services.

Why not create a standard framework for retrieving and sending "stamps"
(such as the format of a message header line or MIME type) and let recipient
ISP's run their own "postage meters" ?  The recipient ISP could decide under
what circumstances they would frank stamps, and only accept stamps that they
generated.

Gerald

On Mon, Nov 17, 2008 at 2:03 PM, Barry Shein <[email-masked]> wrote:

> The World              | [email-masked]           |
> http://www.TheWorld.com <http://www.theworld.com/>

---

From: "Gerald Klaas" <[email-masked]>
Date: Mon, 17 Nov 2008 18:15:35 -0800

> But this would seem to converge onto a whitelisting or C/R scheme, no?

It would, although the "whitelisting" is as defined by the recipient's
process of verification of cookie/stamp, and the C/R scheme is the defined
standard method of obtaining a cookie/stamp.  Note that obtaining a
stamp might or might not be out-of-band from SMTP.

> is who they say they are since they're presenting your stamp.

The stamp issuer also has the ability to know how that stamp was
generated.   If you suppose that a mail recipient runs a dynamic stamp
generator program out-of-SMTP-band over an HTTPS connection, the
generator program may do any number of things before franking a stamp; such
as log the IP address of the stamp requestor, or limit the number of stamps
allowed to certain IP's or domains within a certain time period, or pause a
certain number of milliseconds.  Again it's up to the stamp generator (i.e.,
the mail recipient) to determine the level of effort they want to put into
generating and verifying stamps.

> whatever action you saw fit.

Exactly.  It leaves control of the Level of Effort requirement with the
recipient.  They may choose to make their stamp generator trivial, or they
may choose to make it somehow 'expensive' for the sender.

> some other clear advantage other than possibly stopping someone else

If there were a standard framework for the "purchase" of stamps and their
"placement" in messages, it would certainly be a possiblity that some
recipients would choose to only accept mail that contained a stamp they
could verify had cost the sender whatever they desired, whether that be
financial, time, or CPU cycles.   It would depend on how they implement
their issuing and verification routines in a stamp generator. Such a system
could create an economy for third party stamp generator/verifier services
for persons/domains that didn't wish to run their own.

>  How many big commercial sites will do challenge/response with

And what if you designed the framework so that it could be performed by an
ISP on behalf of their customers, a business enterprise on behalf of their
employees, or an individual user with a reluctant ISP but a smart MUA?

>>user-generated cookies and a C/R system, no?
I would think so.  You're quickly at a chicken and egg scenario.   Who's
going to invest effort without immediate clear benefit?  Although the
barrier to entry might be so low that small groups of business associates
may choose to deploy amongst themselves regardless of whether the whole
world plays along.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Gerald Klaas" <[email-masked]>
Date: Tue, 18 Nov 2008 09:56:14 -0800

Yes, that is what I'm suggesting.  But since it's up to the recipient to
determine if they want to enforce it, I don't see how it would "kill
e-mail".  So what I'm really suggesting is that there should be a standard
for the exchange of "stamps", but not the algorithms required to frank or
verify stamps.

Such a standard method would allow senders to determine if a recipient
requires a stamp, and if so, how to obtain one, and would include a standard
method for packaging a stamp into a message.

In practice, it would be totally up to a recipient whether they insist on a
"stamp".  It would also be totally up to the recipient to determine how they
will verify stamps.

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 20 Nov 2008 01:51:01 -0800

On Nov 19,  2:50pm, Gerald Klaas wrote:
}
} Personally, I believe that there should be a standard method for
} deriving a URL from e-mail addresses. That stamp generators should
} be placed at the derived URL

We've come at this from the point of view of creating an economy.
It doesn't have to be a cash economy, although I think that would
be best if the goal is to translate it into meatspace gains and
losses that might grab the attention of the losers or of law
enforcement, but it has to be something measureable.  What's the
economic incentive for the recipients to expend the resources
necessary to generate a stamp for anyone who asks for one?

If the recipient makes some kind of decision as to who is allowed
to ask for stamps, he might as well simply apply those same rules
to SMTP connections and not worry about the stamps.  I suppose one
could be a little more magnanimous in allowing connections to the
stamp generator because of an expected payment, but the recipient
still has to recoup his costs.

If the incentive is that recipient is to be paid before generating
the stamp, then there has to be a standard way of paying, or you're
back to the N*M problem.  If this is a cash micropayment, then why
not have the known standard payment vendors issue the stamps?  Each
recipient who wants to participate is already going to need to have
a relationship with a vendor (or a proxy for such a relationship), so
the stamp can still be tailored to be single-use for that recipient.
A stamp is nothing more than proof of payment, after all.

That's the Goodmail model, isn't it?  With the substitution of some
known and advertised set of vendors so that recipients and senders
can negotiate on who handles the transaction and whether to require
a payment transaction in the first place.  I'm sure Goodmail has
some attorneys who'd love to have discussions with other potential
vendors about licensing the patents.

Regardless, is whether Goodmail is successful a valid test of this
theoretical economy?  (Except nobody uses lack of Goodmail as a full
delivery block, and everyone has sworn that they won't do so.)

OK, suppose it's not a cash payment.  "Payment" in the form of the
sender's computing resources has already been tried ("hashcash") and
not worked out so well.  Suggest something else?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Gerald Klaas" <[email-masked]>
Date: Thu, 20 Nov 2008 06:59:32 -0800

On Thu, Nov 20, 2008 at 1:51 AM, Bart Schaefer <[email-masked]>wrote:

> enforcement, but it has to be something measureable.

Correct.

> What's the

Better control of their incoming mail stream.

> to SMTP connections and not worry about the stamps.

Except that SMTP is a store and forward system.  An out-of-SMTP-band
stamp negotiation can make decisions based on the originator rather than
what a header claims is the originator.

>  I suppose one

The recoup of costs is a savings from the cost of the current way of
dealing with SPAM.  There may be a micropayment revenue stream
created within such a framework, but as you pointed out above,
it's not necessary .

> not have the known standard payment vendors issue the stamps?

Promise of payment is probably not the motivator, promise of keeping
interlopers out of your inbox is.  Indeed, I would expect that existing
payment vendors would find some creative way to use such a
framework (if one existed) to allow their customers to leverage their
"new" ePostage system.   (And abate the N*M problem.)

>  Each

Yes, a stamp is proof of payment, but that "payment" isn't necessarily
cash.  It may be proof of passing through various checks, such as
having established a connection to a stamp-generator (and leaving your
real IP address behind in the logs).

> vendors about licensing the patents.

It's similar to the Goodmail process in the way that "stamped" or in
Goodmail's terms "certified" mail bypasses other filters.  It's not like
Goodmail in the sense that it doesn't require anyone to use a particular
stamp generator.   I could envision small ISP's running their own
generator as a PHP script on their website.  Since it's their stamp,
no one else should care how "strong" the stamp is.

> delivery block, and everyone has sworn that they won't do so.)

I don't believe that Goodmail is a valid test.  It is, after all, a closed
system.
What I'm suggesting is discussion of a standard way of requesting and
applying a "stamp".

> not worked out so well.  Suggest something else?

Hashcash was never widely adopted and didn't require real-time TCP
connection to a receiver's host (that could be tested and logged).

Gerald

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 20 Nov 2008 08:24:46 -0800

On Nov 20,  6:59am, Gerald Klaas wrote:
}
} > What's the economic incentive for the recipients to expend the
} > resources necessary to generate a stamp for anyone who asks for one?
} 
} Better control of their incoming mail stream.

That's not an incentive.  It's just exchanging one cost (applying spam
filters) for another (generating cryptographic postage tokens plus
the added cost of maintaining the postage generator).  If anyone can
request a stamp, then someone who wants to send a million messages (or
someone who wants to DoS the recipient's stamp generator) can ask for
a million stamps (or ten each from 100k different places).

There has to be an exchange of value between the sender and recipient,
and the value exchanged has to (1) be high enough to dissuade abuse,
(2) be low enough for senders (the ones you "want" to hear from, as
opposed to the spammers) to consider their messages more valuable than
the stamps, and (3) at least pay for the stamp generator plus any
transaction costs of passing around the stamps.

Don't get too worked up over (2).  Of course you can recognize Grandma
and give her free stamps.  The postage doesn't have to be the same for
everyone -- although with "net neutrality" an ISP who acts as a postage
vendor might be forced to have uniform pricing.

Note that unless the ultimate arbiters of stamps are the end users (a
scaling problem), I don't see what prevents this economy from becoming
a pay-to-spam scheme, which is effectively what bulk snail mail is.  In
the physical world bulk postage subsidizes first-class delivery.  Here,
it's hard to imagine that "first class" is costly enough to need any
subsidy, so anything beyond the cost of running the stamp generator is
pure profit; which is quite an incentive to sell more stamps, or to
charge the "owner" of the target mailbox to offset the lost income if
the mailbox owner doesn't want the junk.

Like "free" web hosts put their ads on your pages, but paid hosts don't.

} Yes, a stamp is proof of payment, but that "payment" isn't necessarily
} cash.  It may be proof of passing through various checks, such as
} having established a connection to a stamp-generator (and leaving your
} real IP address behind in the logs).

That *might* succeed in reducing abuse of the SMTP stream, but it
doesn't dissuade abuse of the stamp generator.  Only something with a
real and up-front cost to the sender will accomplish that.  I agree
that it doesn't have to be money, but I have yet to imagine the
alternative.

In case you can't tell, the questions I want someone (perhaps Barry) to
answer are:  What have I got wrong about this economic model?  And if
I've imagined it correctly, can you argue convincingly that it's enough
better than the current situation to be worth the costs of bringing it
into existence?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Gerald Klaas" <[email-masked]>
Date: Thu, 20 Nov 2008 08:57:35 -0800

On Thu, Nov 20, 2008 at 8:24 AM, Bart Schaefer <[email-masked]>wrote:

> This is exactly the kind of discussion I think we need, and why I believe
the "stamp exchange framework" discussion needs to be separate from the
"stamp franking and verification" discussion.   If there were a standard
method for exchanging stamps, that would encourage innovation and
experimentation in what constitutes the "appropriate value" of a stamp.

Every recipient (or ISP) could choose their own stamp generator.  Maybe
it would be one that run for themselves only, or maybe they would redirect
stamp requests to a "stamp vendor".  In my view, having a standard framework
would allow a "stamp" economy to emerge.  It may be that it starts with
large
ISP's running their own, but I expect that if micropayments turned out
to be the "appropriate value" of stamps, that stamp generating service would
converge onto existing online payment systems that are already well
practiced
in handling small financial transactions.

I agree, such a system would largely reflect the current "pay-to-play" bulk
mail system of the USPS, however, I like the idea of being able to set my
own rates.  I can envision that in a leveraged stamp generation service
model
based on micropayments, that individual profiles would exist that set
different stamp "value" based on recipient preference.  Personally, I don't
think I'd mind carrying the Pennysaver from the mailbox to the trash can so
much if I knew they paid 5 bucks to get it there.

In my view, I believe that if a framework existed for the exchange of
"stamps"
that we could then move the SPAM arms race from the MTA to the stamp
generator, which would then allow experimentation, innovation and evolution
within a black box.  Senders and receivers would know how to engage the
"stamp generator" black box, and then we could continue the discussion
about what goes on inside of it.

Gerald

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 20 Nov 2008 10:37:09 -0500

>   real IP address behind in the logs).

Why not have a stamp be a proof of a relationship instead of "payment"?

-- 
Jeff Macdonald
[email-masked]

---

From: Steve Atkins <[email-masked]>
Date: Thu, 20 Nov 2008 12:23:34 -0800

> Why not have a stamp be a proof of a relationship instead of  

Like, say, DKIM-based whitelisting?

If there isn't some additional cost, direct or indirect, to the sender  
for each
email sent, I don't think it's something I'd call postage or stamps or  
any other
snailmail sort of metaphor. (Which doesn't mean it may not be a good  
approach,
just that calling it epostage might be a bit of a stretch).

Cheers,
   Steve

---

From: mathew <[email-masked]>
Date: Thu, 20 Nov 2008 17:56:05 -0600

> Ooh, there's a bad idea I haven't seen for a while.

[citation needed]

mathew

---

From: Barry Shein <[email-masked]>
Date: Thu, 20 Nov 2008 19:12:17 -0500

> better than the current situation to be worth the costs of bringing it

Well, spammers right now send on the order of a billion messages per
day, that might even be per-each-spammer for the worst offenders.

Their return on that O(billion) messages is presumed to be pretty
small. Maybe thousands of dollars per day in the most lucrative
schemes, and even that only for short spurts. Probably hundreds of
dollars per day average, maybe even less.

But with practically zero costs and zero entry cost currently that's a
pretty good living for some, particularly in some countries.

THEREFORE, the assumptions go, you wouldn't have to raise the cost
very much, either entry cost or per message, to make what they do
unprofitable.

And, since practically nobody else sends anything like O(billion)
messages per day such costs wouldn't bother maybe 99%+ legitimate
senders.

OTOH, I believe that if we could magically set a cost it should also
impose a cost on even quite legitimate senders if for no other reason
than to pay for enforcement of those costs on spammers (perhaps
through something like certificate authorities which sell SSL certs
now, as one structure.)

That aside let's try an example.

Say we could effectively impose a 1c/million messages cost (I'm using
US dollars because I might need to buy raw petroleum with the income
stream :-)

And, further, call any charge in a 24 hour period of less than 1c
equal to zero.

So, the O(billion) spammer would be in for $1,000/day.

Assuming we could impose that with some reliability, let's not go
running there yet, how many of the spammers that we actually worry
about could stay in business if they had to pay $1,000/day?

Maybe a few. That's probably too low.

One hazard here is that we're also potentially removing some of their
costs, or at least making their campaigns potentially more effective
if we say pay the postage and you're ok. Individuals might still
choose to block you as much as people throw out paper junk mail unread
today, but you'd be out of the blacklists etc if you're playing
fairly.

So make it 1c/100,000, that's $10K/day to the spammer, and still less
than 1c for most normal users, even large public mailing lists. A huge
public list might be 1M msgs/day, still only $.10/day, $36.50/year,
and there could be a way to waive even that.

Someone like Amazon maybe sends out a few million messages per day, I
have no idea, let's call it 20M/day. That would be $2/day. That still
seems too low but you get the idea. Maybe Amazon et al should pay
O($1,000)/day, the spammer should face O($100,000/day), and the
average user 1c approaching zero.

Ok, a huge list at that point might be a few hundred dollars per year,
not that unthinkable, maybe the list should pay a few hundred dollars
per year much like anyone has to pay for an SSL cert. Anyhow, it's
well within the range for a waiver or special rate for non-commercial
use or whatever, it wouldn't take much of a discount to make $300/year
palatable.

Anyhow, that's what I'm thinking as a goal framework.

Why would someone like Amazon agree to be charged say $300K/year?

They would if they believed it drastically lowered the spam, suddenly
their email might get read instead of drowned out in the deluge.

Obviously how to get there is non-trivial. But if it *were* trivial
why are we all still here?!

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Thu, 20 Nov 2008 19:13:42 -0500

> about what goes on inside of it.

I like that way of putting it.

-- 
        -Barry Shein

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 20 Nov 2008 20:38:50 -0800

On Nov 20,  7:12pm, Barry Shein wrote:
}
} Well, spammers right now send on the order of a billion messages per
} day, that might even be per-each-spammer for the worst offenders.
} 
} THEREFORE, the assumptions go, you wouldn't have to raise the cost
} very much, either entry cost or per message, to make what they do
} unprofitable.

Unfortunately, this is only half (maybe less than half) of the case
I think you need to make.  It's not enough to point out that imposing
some kind of delivery cost would stick it to the nasty spammers.

You also have to demonstrate that it makes good financial sense for
those who will be issuing and verifying the stamps (or whatever the
means of inflicting the delivery cost may be) to re-engineer their
email system (and maybe other out-of-band technology) to support the
payment scheme.

Without that, you're left with something that can only be imposed by
fiat, like the digital TV broadcast conversion in the US.

} Why would someone like Amazon agree to be charged say $300K/year?
} 
} They would if they believed it drastically lowered the spam, suddenly
} their email might get read instead of drowned out in the deluge.

That about sums up Goodmail's business proposition, except that they
leave lowering the spam to others and instead drastically raise the
visibility of Amazon's mail (in theory).  Either way it's about not
getting drowned.  Amazon has no reason to care whether the water goes
from neck-deep to ankle-deep, or they have a boat to float in, as long
as they're mostly above the water.

It's not the senders you need to convince.  Recipients have to feel
that a sump pump is going to be more effective than a fleet of rubber
rafts.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Gerald Klaas" <[email-masked]>
Date: Thu, 20 Nov 2008 23:20:07 -0800

> email system (and maybe other out-of-band technology) to support the
Yes, it is the recipient that decides to enforce a "stamp" framework
and has to decide if it makes financial sense to re-engineer their
mail system.  So how do you suggest that such a standard would
require the minimal effort to implement?  Might there be a way to
leverage existing technology to locate a recipient's stamp generator,
interact with the stamp generator, and affix a stamp to a message?
I envisage that such a system could leverage existing web servers
for stamp generators with stamp verification performed within filter
rules of existing MTA's or MUA's.   Maybe that's workable, but
maybe there's a better way.

I don't see that other details, like the value of the stamp, or the way of
collecting that value, or the way of verifying the "stamp" need to be
defined
within such a standard, just how a sender gets a stamp and then affixes it.

BTW:  I personally prefer the term "token" instead of "stamp" since
I believe that within such a framework, many recipients would not require
the "cost" of a stamp to be monetary.  I also happen to believe that such a
system would, over time, converge to use a micropayment system like what
Barry described.

Goodmail CertifiedMail(TM) is not based on an open standard,
requires a central authority, and requires a sender's ISP to implement it
in their MTA.  I believe a "stamp" framework could be defined such that it
is open, distributed, and able to be implemented in either MTA's or MUA's.

Gerald

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 21 Nov 2008 11:24:48 +0000

> average user 1c approaching zero.

Facebook send about 10,000 messages a day to my site - it's about 10% of 
our non-spam email, so it's about 1% of our total email. My guess is that 
facebook don't monetize email like amazon do, so we ought to consider what 
the cost to them will be.

But, we can't do accounting before we can do accountability. With 
accountability, we have the opportunity to impose costs through the courts, 
or simply to build better spam filters. If that fails, at least we'll be 
half way to implementing direct charging.

---

From: Bart Schaefer <[email-masked]>
Date: Fri, 21 Nov 2008 09:16:53 -0800

On Nov 20, 11:20pm, Gerald Klaas wrote:
}
} Yes, it is the recipient that decides to enforce a "stamp" framework
} and has to decide if it makes financial sense to re-engineer their
} mail system.  So how do you suggest that such a standard would
} require the minimal effort to implement?

I was suggesting that it's up to the more vociferous proponents of
the idea to come up with that answer ... but since you asked:

Simplest would probably be to model the base mechanism after the DSN
standard (RFC3461).  Client sends EHLO, server responds that it will
accept postage.  Client appends a parameter to the MAIL command with
the identity of its payment service(s).  Server accepts or declines,
attaching an extended status code for details.  Client then appends
to the RCPT command a parameter indicating how much the sender is
willing to pay for this message, and server accepts or declines,
again with an extended status indicating the charge the server wants
to deliver the message, regardless of whether it was declined.  If it
was declined for insufficient postage, the client can re-issue the
RCPT with the offered postage increased.  If the client deems the
charge too high even though it was within the original offer, it can
end the transaction without issuing DATA.

In all of this I assume that 2xy continues to mean "go ahead", 4xy
"try again", and 5xy "no further negotiation possible".  If the client
does not offer postage, the server can wait for the DATA command and
look for a postage token in the message header (see below).

Otherwise, on 350 response to DATA, server has taken responsibility
for making a best effort to deliver the message without charging the
original sender's payment service more than the agreed postage.  For
a relay, that may mean that it has to negotiate its own payment for
the next delivery hop, but it could also pass along the original
parameters, possibly with the offered postage decreased by a routing
fee.  This would need some tokens along the lines of the DSN ENVID
to validate the transactions back to the original sender to avoid
fradulent charging.

At final delivery, or in the event of relay to a hop that doesn't
support the postage standard, the MTA can insert a cryptographic
token computed in a DKIM-like way over some excerpt of the message
and headers, containing the original postage parameters and the
amount of postage deducted by the relay.  (It could even be a DKIM
parameter, I suppose.)  This can be checked by an MUA or used by
another relay to reconstruct the MAIL and RCPT parameters for the
next hop.  A separate trace, probably in the Received: header,
might be needed whenever such a transition from in-message to
in-protocol postage occurred.

An MUA could also slap on one of these headers to start off the
process in the event that the submission server doesn't support it.

} Goodmail CertifiedMail(TM) is not based on an open standard, requires
} a central authority, and requires a sender's ISP to implement it in
} their MTA.

Yes, and Goodmail is patented, which means that any open scheme that
has a similar effect would have to pass a patent challenge.  I have
no idea whether what I described above would infringe that, or
whether it might infringe on claims made by brandmailsolutions.com
(who already has a scheme for overloading DKIM with a cert token).

Note also that I haven't made any claims about the likelyhood of that
implementation being accepted (I haven't, for example, been following
how widely the DSN standard is implemented) and I'm quite sure I've
overlooked all sorts of security concerns.  But if you need a strawman
implementation to argue financial feasibility, there you go.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Fri, 21 Nov 2008 12:53:03 -0500 (EST)

>> Goodmail CertifiedMail(TM) is [...]
> has a similar effect would have to pass a patent challenge.

Or, if - as seems likely - it is patented in only some jurisdictions,
it can be used by the rest of the world freely, with jursidctions
allowing it to be patented just having to live with the consequences of
their antisocial intellecual property actions.  (Yes, I believe that
such patents are antisocial.  I'll be happy to blather about my various
intellectual property stances offlist if anyone wants.)

Why does everyone seem to think "patented" is a
jurisdiction-independent state?  People just say "patented" - and on a
fairly specifically cross-jurisdictional list! - as if it were
something that were the same everywhere.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: David Wall <[email-masked]>
Date: Fri, 21 Nov 2008 10:08:15 -0800

> something that were the same everywhere.

Because no standards organization would build an Internet spec that 
cannot be used worldwide.  And since the patent is most likely in the 
US, that would be a rather significant jurisdiction to leave out in an 
anti-spam effort. 

David

---

From: Steve Atkins <[email-masked]>
Date: Fri, 21 Nov 2008 10:10:06 -0800

> something that were the same everywhere.

We're designing for the Internet. That goes everywhere. Therefore,
any suggested protocol needs to be able to go everywhere, or it's
just a local implementation and outside the scope of a group that's
doing research for Internet protocols.

Cheers,
   Steve

---

From: mathew <[email-masked]>
Date: Fri, 21 Nov 2008 12:40:14 -0600

On Fri, Nov 21, 2008 at 12:08, David Wall <[email-masked]> wrote:

> Because no standards organization would build an Internet spec that cannot
> be used worldwide.  And since the patent is most likely in the US, that
> would be a rather significant jurisdiction to leave out in an anti-spam
> effort.
>

Especially since the US is the source of most of the spam...

mathew

---

From: der Mouse <[email-masked]>
Date: Fri, 21 Nov 2008 15:17:52 -0500 (EST)

> doing research for Internet protocols.

So all we need is to find a country where something is illegal and
you'll support throwing out any attempt to standardize it, or design
protocols based on it?

I think there are still places where strong crypto is illegal.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Barry Shein <[email-masked]>
Date: Fri, 21 Nov 2008 17:05:41 -0500

Whoa. We're going from ``goodmail has a patented scheme'' to ``that
patent scheme would apply to e-postage'' (???) to ``therefore the idea
is a loser'' rather glibly.

I wouldn't be so quick to play patent lawyer and assume that said
patent applies. I'd prefer to hear from a patent expert. I haven't
heard anyone cite the patent number so it just sounds like a WAG.

More importantly, plenty of stuff which comes out of IETF involves
patented technologies. It just generally requires that the patent
holder basically make their patent available or other concessions.

Often they have an interest in doing that so their technology becomes
a standard, usually in the belief that they have a head start in
implementation and corporate infrastructure, sales, reputation, etc,
letting it be an open standard would vastly increase the marketplace,
so all is good.

I'm not an expert on that (IETF policies and history regarding
patented technology) but perhaps someone else knows.

So, besides the fact that any applicability of said patent may be a
stretch, it's not a death-sentence, the phrase "it's patented!"  is
not automatically, by itself, a deal breaker.

-- 
        -Barry Shein

---

From: der Mouse <[email-masked]>
Date: Fri, 21 Nov 2008 17:20:47 -0500 (EST)

>> jurisdiction-independent state?  People just say "patented" - and on
>> a fairly specifically cross-jurisdictional list! - as if it were
> cannot be used worldwide.

Oh, nonsense.  There were specs based on strong crypto back when strong
crypto was illegal in places as popular as France.  (Still is illegal
in some places, I believe.)

> And since the patent is most likely in the US, that would be a rather
> significant jurisdiction to leave out in an anti-spam effort.

Perhaps to those in the US.  As someone outside it, I'd much rather
effective measures usable by the free world not be held up by
US-specific idiocies.  (Much as, I imagine, US residents felt about
strong crypto and France.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: SM <[email-masked]>
Date: Fri, 21 Nov 2008 14:32:39 -0800

>holder basically make their patent available or other concessions.

It's covered in RFC 3979.

Regards,
-sm

---

From: "Bart Schaefer" <[email-masked]>
Date: Fri, 21 Nov 2008 18:51:47 -0800

> is a loser'' rather glibly.

I'm sorry I even brought it up, as it seems to have completely
derailed the conversation.  I certainly didn't *mean* "WOULD apply,"
just *might* apply.

I don't think anyone's gotten to "the idea is a loser," though, unless
"the idea" means patents.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 22 Nov 2008 14:38:35 +0100

> require much more effort on the part of the receiving/authorizing entity.

Yes, it is more difficult to set up, specially if we want manual 
interventions to be required in some specific circumstances only. 
However, once set, it would be very cheap to run.

> (I'm not volunteering to manage it, though.)

That idea originated from a discussion on the SPF mailing list. Some 
time after, I begun to lazily collect its pieces, writing pages like 
http://fixforwarding.org/wiki/forwarding_agreement

(I'm somewhere between "programmer" and "netizen" according to 
Vernon's list http://www.rhyolite.com/anti-spam/you-might-be.html and 
currently not a member of the ASRG, so I cannot volunteer either ;-) )

Thank you for your interest.
Ale

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 22 Nov 2008 20:38:55 +0100

> So, the O(billion) spammer would be in for $1,000/day.

1000 cents per day, or 10 Dollars per day.

But let's assume we charge 1c/10k messages/day. A spammer who sends out
1 billion messages per day probably has access to a botnet of at least
100k nodes. Which means that each zombie has to send out less than 10k
messages per day. Which it can do without incurring any cost to owner of
the 0wned machine. And even if a bot occassionally exceeds that limit,
how many users will even notice if their ISP charges them a few cents
more per month, much less clean up their PC? 

> their email might get read instead of drowned out in the deluge.

Amazon's mail is simple to recognize and frequent enough to configure a
filter for it. If people want to read it, they will. If people want to
ignore it, they will even if it's the only thing in their inbox on that
day.

> Obviously how to get there is non-trivial.

Indeed. It's a chicken and egg problem. Amazon won't pay for postage
until they see an advantage in doing so. And receivers won't reject
mails without poststamps (not even score them down) until a significant
proportion of (legitimate) senders stamps their emails. 

You either need a marketing genius who can persuade everyone to convert
to the new system at once, or you need to offer an advantage to the
early adopters, so that the new system can grow incrementally. I won't
speculate about the former, but I don't see the latter. It won't
decrease spam unless widely adopted, so there is no gain, only cost. 

	hp

-- 
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | [email-masked]         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Barry Shein <[email-masked]>
Date: Sat, 22 Nov 2008 17:30:15 -0500

> It's covered in RFC 3979.

Thank you. Also, RFC 3978 is worth looking at in this context, "IETF
Rights in Contributions".

-- 
        -Barry Shein

---

From: "David Nicol" <[email-masked]>
Date: Sun, 23 Nov 2008 14:32:40 -0600

> decrease spam unless widely adopted, so there is no gain, only cost.

Advenge is a scheme of the second type of those two types.

The advantages for the early adopters include:
  * control over what is allowed into the in-box, meaning easier of
     unsubscription from mailing lists
  * no more false positives caught in spam folder
  * no spam folder at all
  * income stream

It immediately decreases spam for those who are using it; and does not
decrease spam for everybody.  I believe we have been over many times
that insisting that a solution apply to everyone instantaneously is
like trying to teach a pig to sing.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: David Wall <[email-masked]>
Date: Sun, 23 Nov 2008 16:04:37 -0800

> like trying to teach a pig to sing.
If 99% of the others are not using it, then you can only eliminate by 
not accepting email from those 99% who are not participating.  And if 
you accept from those 99%, you have the same problems as before.

Adoption of standards is just plain hard unless it's easy to adopt and 
can be widely done, usually because big players want to take part.  Many 
are even adopted by a lot of folks, but never really catch on, such as 
OSI/ITU communications, ASN.1 data encoding, CORBA interprocess 
communications, ADA programming, SGML markup, PKI security (beyond HTTPS 
which was enforced by the popularity of browsers even though self-signed 
certs keep Internet communications as secure -- and with EVI, apparently 
even the claim earlier that we could trust having certs issued by CAs 
turned out not to be true)....

I don't see how early adopters get this benefit in any meaningful 
way....like SPF/SenderID, DKIM, S/MIME didn't do much to reduce spam 
because few will reject emails that don't comply, even if they may use 
them "some."

David

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 24 Nov 2008 12:23:02 +0100

Peter J. Holzer wrote:
> But let's assume we charge 1c/10k messages/day. [...] And even if a
> bot occassionally exceeds that limit, how many users will even
> notice if their ISP charges them a few cents more per month, much
> less clean up their PC?

Hm... that assumes that ESPs will buy tokens (or stamps) on behalf of 
the message authors. Postage systems, with the exception of some 
hotels and similarly managed residential arrangements, require that 
authors go to the post office to buy stamps. Deciding _who_ affixes 
the tokens is required for a protocol that is agnostic about what the 
tokens contain; e.g., on-the-fly negotiation does not suit the stamp 
metaphor if acquiring tokens involves interacting with the authors.

If tokens are affixed by the transport system, a submission agent is 
implied. That prevents authors from sending via occasional servers 
(much like SPF and DKIM.) It is this fully automatic acquisition and 
affix that calls for a venial content of the tokens.

If tokens are affixed by authors, they must be able to acquire them 
through firewalls, hence via http[s]. Is it possible to send a token 
for the reply as an attachment? How do I know what tokens I've already 
used? Then I should also ask what difference does it make if an 
incoming message has a token affixed. Possibly, affixing a token as an 
attachment rather than a header would make it more visible to the 
recipients, while machine readable parts can live both in the 
attachment's headers and in exif-like encoded data. (And yes, IMHO 
S/MIME signatures are not used because they are rendered so poorly.)

---

From: Bart Schaefer <[email-masked]>
Date: Mon, 24 Nov 2008 13:05:54 -0800

This'll be my last reply on the topic of postage mechanics unless someone
asks me a direct question.  I can hear you all sighing with relief.

On Nov 24, 12:23pm, Alessandro Vesely wrote:
}
} Hm... that assumes that ESPs will buy tokens (or stamps) on behalf of 
} the message authors.
} [...]
} If tokens are affixed by the transport system, a submission agent is 
} implied.
} [...]
} If tokens are affixed by authors, they must be able to acquire them 
} through firewalls, hence via http[s].

My suggestion was to make the delivery agent responsible for attaching
the token.  The sender simply tells the delivery agent how to charge
the cost of the token back to the sender; the token itself never leaves
the recipient's [provider's] control.  So ESPs don't buy tokens, they
provide payment accounts against which recipients make charges.

} Is it possible to send a token for the reply as an attachment?

Not literally, but it would probably be possible to recognize a reply
and skip charging the reply-er for his message.

} How do I know what tokens I've already used?

You don't need to, because you never give them to someone who might try.

} Then I should also ask what difference does it make if an incoming
} message has a token affixed.

If implemented as I suggested, you throw away incoming tokens and create
a new one at delivery, like the Return-Path line is handled today.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: mathew <[email-masked]>
Date: Tue, 25 Nov 2008 09:19:44 -0600

On Sun, Nov 23, 2008 at 18:04, David Wall <[email-masked]> wrote:

> If 99% of the others are not using it, then you can only eliminate by not
> accepting email from those 99% who are not participating.  And if you accept
> from those 99%, you have the same problems as before.

Currently, I occasionally miss messages from friends because they get
spam-filtered.

If a proposed system can eliminate that problem, that alone is enough of a
win to get me on board until such time as I can turn off receipt of
non-participants' e-mail altogether.

mathew

---

From: "Richi Jennings [RJA]" <[email-masked]>
Date: Mon, 24 Nov 2008 01:04:35 +0000

>  * no more false positives caught in spam folder

Do I, perchance, smell challenge/response?

Please, let's not get sucked into another rathole in this fantastic
maze of twisty threads.

r.

// Richi Jennings Associates - http://richi.co.uk
// mailto:[email-masked] - tel:+44.7789.200701
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg