Subject: Re: [Asrg] POSTAGE, was The fundamental misconception about paying for mail

From: Barry Shein <[email-masked]>
Date: Mon, 1 Dec 2008 17:52:45 -0500

On November 30, 2008 at 12:06 [email-masked] (Gerald Klaas) wrote:
 > On Sat, Nov 29, 2008 at 12:12 PM, Barry Shein <[email-masked]> wrote:
 > >
 > > Can they cheat? Of course they can cheat. But the real question is
 > > what are the chances they would get caught and what is the penalty?
 > >
 > Do we dare open the legislation topic?  It's pretty clear that CAN-SPAM
 > is not effective.   If one is using "stamps", is there any legal benefit (in
 > the USA) ?   Might a recipient be able to legally pursue a spammer for
 > abusing their "stamp generator" (under fraud laws) as opposed to
 > CAN-SPAM?  With an out-of-SMTP-band stamp "purchase", the recipient
 > is able to define the process senders need to follow to obtain their
 > "stamps", we would hope leaving an audit trail in the process.  Clearly
 > fraud laws would apply if the stamps involved micropayment, maybe
 > not if you couldn't assign a cash value to the "stamps".

I don't think we have to go there so quickly.

A public "cheaters" list might be sufficient if it encouraged shunning
or rate limiting etc offenders.

-- 
        -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: Barry Shein <[email-masked]>
Date: Mon, 1 Dec 2008 19:56:21 -0500

On December 1, 2008 at 02:33 [email-masked] (John Levine) wrote:
 > > > How do you plan to identify and charge bulk senders without counting
 > > > the mail?  Spammers already go to considerable effort to disguise
 > > > their bulk mail as a lot of different non-bulk mail.  How do you
 > > > expect to keep bulk senders from sneaking under the radar by
 > > > masquerading as a lot of non-bulk senders?
 > >
 > >Does this mean we've moved beyond the "moral" issue?
 > 
 > Beats me.  Nobody has mentioned a "moral" issue but you.

Well, I was referring to the idea that it's somehow (morally) wrong to
charge for email, or further it's wrong to charge for worthy mailing
lists (this one often cited), etc.

Those to me are "moral" issues.

Compare and contrast to "moral risk" in financial markets.

 > >meters, it's up to the bulk sender to purchase the "postage", likely a
 > >cryptographic scheme which identifies the purchaser uniquely
 > >(analogous to DKIM) and allows the sending of however many "stamps"
 > >were purchased, a countdown system.
 > 
 > Right, that brings us to the double spending problem ...

Not in any terribly unique way.

Why can't I buy one SSL cert and put it onto as many sites as I like?

Ok, that's only one dimension of the problem.

But the point is if I can distinguish between a legitimate stamp and a
non-legitimate stamp, and like an SSL cert, can know with some
reasonable certainty who must own that "postage meter", then I know
who the offender is.

Now, if, like SSL certs, it's very difficult to counterfeit a "stamp"
it must have been bought somewhere and by the culprit.

Then we go to sampling techniques, rewards, etc.

If someone is caught double-spending one presumes the postage meter
sales company (a la SSL cert sales co) is interested, at least.

It's possible it was all a big mistake, server went crazy, db out of
synch, never happened before, won't happen again. Fine, you're
forgiven or pay the clean up fee and you're forgiven, whatever, that's
marketing.

But if not then maybe you can't buy any more postage until you somehow
prove your contrition. etc. Or you'll end up on blacklists and no one
will accept your postage.

 > >There are many working systems, business models, on this planet which
 > >do not require or even attempt perfection.
 > 
 >   ... because none of them are attempting to work in an environment
 > where 98% of the attempted transactions are bogus.

You need to speak with ASCAP, RIAA, et al.

You don't think illegal muslc downloading etc faced similar stats?

And what would postal systems or phone systems face if there were no
enforcement, no economy, hence no economy for enforcement?

Who would pay their phone bill if they won't even shut your phone
service off for non-payment? Yet, that's practically the situation
we've created with email.

Send a billion messages, free! If we don't like them then...send a
billion more, free!

Hard to compare.

 > Say you've dropped into the local Dunkin Donuts for a donut and
 > coffee.  But 98% of the cash that customers offer is counterfeit.  How
 > would this affect the way that cashiers work?  Would they just accept
 > all the cash and figure they'll call the cops when they find bogus
 > stuff?

But that's the point, the cashiers can (usually/often) spot
counterfeit and won't accept it in the first place. And efforts are
continually made to help that (e.g., holographic elements on bills.)

If an SSL cert is bogus your browser tells you, right? Similar.

What good is a bad postage stamp which isn't accepted? That means the
msg didn't get thru which presumably was the point. May as well put
"X-Worthless-Spam: YES" in the header.

But for example if I were an ISP (scratch that, I am an ISP) and
dropping email which contained bogus postage I might keep stats on it
and do something with interesting bits and pieces of those stats.

I think a lot of this discussion gets derailed because who we're
talking about is fast fluxed between end users, senders, ISPs or
company gateways, etc. and some action which might be perfectly
reasonable at an ISP's aggregate and technically sophisticated vantage
point suddenly sounds ridiculous when re-positioned onto dumbcluck
end-user or whatever. "What? You expect my 90 year old grandmother to
manage full BGP??? This internet thing will never work!"

 > If you design a system that is designed to leak a little spam, the bad
 > guys will aim their firehose through the leaks.  Remember, they have
 > millions of zombies, so if your wonderful system rejects their fake
 > stamps with 99% accuracy, they try 100 times as often and get the same
 > amount of spam through.

Yeah but you've closed one eye and you're squinting with the other.

They still have to start with cryptographically legitimate "stamps"
they got somewhere, a la SSL certs.

Otherwise the postage will instantly test invalid, much like a browser
can spot a bad SSL cert, and be rejected.

Now if they buy a legitimate "cert" and proceed to double-spend we'll
know who they are. It will be invalidated (presumably any rational
scheme would have these expire at regular intervals) and no one would
sell them one again at least until they've cleared their name.

 > None of this should come as any surprise to anyone who's thought
 > seriously about e-postage.  I was certainly aware of it when I wrote
 > my white paper five years ago.

Well, if it takes three facts to make it work and you keep dropping
one and arguing against the other two as if the third didn't exist...

1. Cryptographically verifiable "stamp".

2. At least: Identifies the purchaser uniquely (including the
permitted sending hosts), similar to "real" SSL cert requires positive
id for purchase (we had to supply our D&B id for example), and an
expiration beyond which it should not be accepted. Organizations (ISPs
etc) can and are expected to purchase on behalf of client systems and
affix to outgoing email.

  2a. Yes this raises the forwarding issue but let's not jump right
      there I think it's tenable. A stamp is a stamp is a stamp.

3. Can be rejected algorithmically for authenticity or source by a
receiving MTA or anyone else interested and able to read the
credentials and run a check.

4. Blacklists of abusers, particularly preventing identified abusers
from purchasing further postage until issues cleared up but in serious
cases can be made publicly available. Postage is only good for so many
sends, expires, etc. so must be purchased at regular intervals.

5. Anyone who controls their pipe can choose not to check any of this
or do whatever they want with the info. For example some ISP might
choose to pass failed email to the end-user anyhow, perhaps marked
with a warning, put into a special folder, translate to esperanto,
etc.

Therefore, if you double spend a lot you will almost certainly get
caught.

If you don't do it much you might get away with it but who cares,
really?

It's the folks who send a billion msgs a day we care about, not some
cheapskate who steams stamps off envelopes to reuse.

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 3 Dec 2008 00:56:34 -0000

We still seem to have some problems with weak analogies.

>Why can't I buy one SSL cert and put it onto as many sites as I like?

Because each site has a unique DNS entry.  I don't think a system that
requires a DNS entry for every message you send would work very well.

>But the point is if I can distinguish between a legitimate stamp and
>a non-legitimate stamp, and like an SSL cert, can know with some

That all makes sense, but I still don't see a reasonable process for
monitoring the mail.  Bad guy gets a meter, prints himself 100 stamps,
puts each of them on 100,000 pieces of mail and blasts out 10 million
spams to random recipients.  Are you assuming that each stamp would be
keyed to a particular message and envelope?  That's sort of what
Goodmail does, although it's rather hard to make it tamper-resistant.

>You don't think illegal muslc downloading etc faced similar stats?

The issues are utterly different.  If ASCAP managed to collect 90% of
the royalties people owe them and miss the other 10%, they're doing
great.  If 10% of the spam with reused stamps leaks through, we're
still drowning.

>know who they are.

Unless both of the recipients present it back to the issuer, how?  And
if they do, we're back at the horrible micropayment database problem.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Tue, 2 Dec 2008 21:06:06 -0500

> We still seem to have some problems with weak analogies.

Something like that...

 > requires a DNS entry for every message you send would work very well.

I am straining to imagine why you would say this. Seriously. I'm
mildly boggled. So forgive me if my response misses your point:

A system creates a stamp for a message.

That system, the one with the "postage meter", has to have something
akin to an SSL cert to generate that "stamp" so the stamp would pass
basic authentication by the receiving host, much like any browser can
spot a phony SSL certificate.

In the case of a consumer ISP, port 25 blocked and all that (tho
that's not necessary but it simplifies the imagery), one would expect
the consumer ISP's MTAs generate the stamp and affix it to the
outgoing message.

I don't see where "a DNS entry per message" enters into something like
this at all any more than a "DNS entry per web page" would in a web
server SSL cert context.

 > monitoring the mail.  Bad guy gets a meter, prints himself 100 stamps,

Stop.

How does he get a "meter"?

Again, let's go back to the SSL cert example.

Bad guy gets an SSL cert...Stop! Not so easy.

For example, you certainly can't just stick an SSL cert (which others
would accept) onto a zombied system. The DNS won't match.

You can't forge one, too difficult.

And if you stick an SSL cert on your authorized system and generate
crap, why, we just won't accept anything from that IP! Just like
today, which is exactly why spammers have to use zombie'd machines, IP
mobility so they don't get blocked. But IP mobility doesn't work very
well if you also need something like an SSL cert to work.

 > Goodmail does, although it's rather hard to make it tamper-resistant.

It wouldn't be valid, it wouldn't pass superficial checks by the
receiving MTA, any more than a bad SSL cert would pass superficial
checks by a browser.

Anyhow, you're drifting back into the "closed solution" requirement
which I thought we were slowly agreeing may not be necessary.

I don't have to catch every single cheat, I only have to catch enough
to justify shutting the offender down. That is, to put him on a
blacklist so he doesn't get any more "certs", or whatever ajudication
is acceptable.

Just like the CAs might refuse to sell you an SSL cert because you use
them to defraud people. They don't need every single example, only
enough to prove the case that you're a crook and cut you off.

And, since the "cert" uniquely identifies the offender it's not too
hard to pass that blacklist info out so interested parties put that
cert-id into their own blacklists. That's their choice of course, but
it should be fairly easy to BL. And if they expire regularly they
don't get another -- they're out of business!

 > great.  If 10% of the spam with reused stamps leaks through, we're

Well, I'd love to hear the reaction from an RIAA or ASCAP spokesperson
regarding "90% of the royalties". I suspect in the world they live in
they're pretty happy with small single digit percentages. Ya know,
your neighborhood bar slips a CD into the player, or even turns up the
radio or TV so customers can enjoy the show, they owe a royalty! They
never pay it, but the internet is similar, probably better because
ASCAP et al can actually sit in an office searching for offenders on
the internet. Checking every bar is a more difficult task.

THAT SAID...

I think I dealt with the issue of reused stamps above.

 > if they do, we're back at the horrible micropayment database problem.

We don't care about someone who reuses a stamp once in a blue moon any
more than in the US postal system.

We're worried about the guy who reuses a million times.

Put out some rewards.

Provide an easy way for an end-user to check. E.g., forward a msg
(maybe something SPAMMY!) to this address and if we get a dupe we
didn't know about we'll send you a free itunes coupon. Whatever, but
having created an economy around this you can consider solutions like
this.

Do some sampling!

If someone is a flagrant violator and sending a million dupes out then
how many are likely to pass thru some single, cooperative ISP? And if
that ISP is getting a cut of the action they have a monied interest in
stopping fraud. So stick snoopers on their MTAs.

Remember, you only have to catch the crook once (more or less) in this
scheme, and he's out of business. You'll then invalidate his postage
meter (e.g., put it onto a blacklist) and not sell him another.

But even that's stretching a point.

Spammers won't buy postage unless it costs like one dollar a year for
a 100 billion messages.

And they can't forge it.

So where does that leave them?

But ok I'll play along because in my vision of the scheme I want all
bulk emailers to pay, not just hardened criminal spammers, and no
doubt occasionally even the initially honest will think to go rogue.

So, if they get caught, they're outta that business, done, just like
screwing up your credit, you can't have any more credit cards, etc.

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 3 Dec 2008 12:08:27 -0000

>mildly boggled. So forgive me if my response misses your point:

Uh, Barry, that's how SSL certs on web sites work.  Every web site has
a DNS entry, the name in the cert has to match the name in the DNS
that a www client uses to find the site.  That's what prevents "double
spending" certs to keep you from putting them on as many sites as you
like.  If you have a dozen servers with the same name, you can indeed
put the same cert on them, but unless they are load sharing mirrors
with the same content, the results would be too strange to be useful.
If you have a thousand different certs, you need a thousand DNS
entries to match them.

>spot a phony SSL certificate.

I think we all get this part, the bank that issues the postage meter
signs the meter's cert, which signs the stamp which is bound to a
particular message, presumably with a hash of the contents, sender,
and recipient, or something like that.  Mail recipients would have a
list of credible banks, along the lines of the list of SSL signers
that web browsers have now.  No question, we know how to do that.

If you include the envelope in the stamp, you have all of the path
problems that SPF has.  If you don't, you have no protection against
sending the message to multiple recipients.  But let's just wave our
hands and ignore that problem for now.

>this at all any more than a "DNS entry per web page" would in a web

There's a key difference here: once you have an SSL cert for a web
site nobody cares whether there's one page or a million pages on the
site.  But if you're doing postage, the whole point is to limit the
number of messages, so you need some way to tell them apart so you can
count them.

>Stop. How does he get a "meter"?

He buys one from the cheapest sloppiest bank around, of course.  There
will be the inevitable race to the bottom, with the banks doing the
absolute minimum necessary to avoid annoying recipients so much that
they manually take them out of the recipients' list of issuers.
Experience suggests that you'll have to be really horrible to have
that happen, and even if half of the recipients blackball you, the
other half will still be delivering a lot of spam.

>Bad guy gets an SSL cert...Stop! Not so easy.

You're kidding, right?  When's the last time you got an SSL cert?  I
happened to get one for my sister yesterday.  I looked around to find
out who's the cheapest, found someone selling them for $12.95
(servertastic.com), paid with a credit card which, since I am honest,
was actually mine, clicked through on a URL in an email message sent
to postmaster@<cert domain>, and got the signed cert, in a total of
about five minutes.  If I did it very often, I could easily have
scripted it.  This is the reality of Internet security today.

In the cert biz, they now have "high security" green bar certs which
roll the clock back to the price and somewhat more stringent
investigation that all certs required a decade ago, but it's just a
matter of time before those race to the bottom, too.

> receiving MTA, any more than a bad SSL cert would pass superficial

I think it's reasonable to assume that bad guys will be able to crack
any software based meter.  (An obvious attack is to snapshot the newly
installed meter and restore the snapshot whenever it runs out of
money.) Are you expecting meters to include tamper resistant hardware?
That's not out of the question, but it raises the price, and it's hard
to think of a situation where widely deployed tamper resistant
hardware in hostile environments has resisted attack.

I'm not saying that it's hopeless so give up, but I'm definitely
saying that any proposal that depends on large numbers of people
acting against their very short term interests is unlikely to work.

R's,
John

---

From: Paul Russell <[email-masked]>
Date: Wed, 03 Dec 2008 08:55:59 -0500

On 12/3/2008 7:08 AM, John Levine wrote:
> that a www client uses to find the site.  

You need one cert for each web host, not one cert for each page on the web host. 
  If a single box answers to multiple hostnames, it needs a cert for each name to
which it responds; it does not need a seperate cert for each page on each
virtual host.  You can buy multiple copies of a single SSL cert so that you can
legally put the same cert on multiple boxes.

Go back to the analogy of the postage meter.  When you buy/rent a postage meter,
the meter is assigned a unique ID number which is printed on each envelope
processed through the meter.  The ID number is unique to the meter, not to each
envelope; the epostage signature would be unique to the epostage cert purchased
by the sending domain, not to each message sent from the domain.  Presumably, a
site could purchase multiple copies of a single epostage cert, so that messages
from multiple MTA's would carry the same espostage signature.

I see some conceptual similarities between this epostage proposal and DKIM.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Paul Russell <[email-masked]>
Date: Wed, 03 Dec 2008 09:30:14 -0500

> matter of time before those race to the bottom, too.

In every industry, there are vendors who compete solely on price, often at the
expense of the quality of their products or services.  Some CA's may issue certs
to anyone with an apparently valid credit card number and a working email
address; some require additional proof that the buyer is who he claims to be.
In the long run, certs from CA's in the first group are likely to have less
credibility than certs from CA's in the second group.  At some point, some
enterprising individual will build a CA reputation database and someone else
will write a browser extension that will check the database whenever the browser
encounters a cert.  It will not be ubiquitous, just as the use of email sender
reputation services is not ubiquitous, but it will provide useful information to
those who choose to use it.

The anarchical nature of the 'Net virtually guarantees that nothing will ever
be deployed universally and simultaneously.  Human nature guarantees that
someone somewhere will attempt to thwart any technology that might make a
significant dent in the spam problem.  If universal simultaneous deployment and
total infallibility are non-negotiable requirements for any proposal, then
nothing will ever be done.

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 03 Dec 2008 08:33:51 -0800

On Dec 3, 12:08pm, John Levine wrote:
}
} >Stop. How does he get a "meter"?
} 
} He buys one from the cheapest sloppiest bank around, of course.  There
} will be the inevitable race to the bottom, with the banks doing the
} absolute minimum necessary to avoid annoying recipients so much that
} they manually take them out of the recipients' list of issuers.

[...]

} I think it's reasonable to assume that bad guys will be able to crack
} any software based meter.  (An obvious attack is to snapshot the newly
} installed meter and restore the snapshot whenever it runs out of
} money.) Are you expecting meters to include tamper resistant hardware?

What Gerald and I are expecting is that meters are sold not to senders,
but to recipients.

All the sender does is present his identity.  The recipient's postage
meter issues a stamp which is only good for sending one message to that
recipient.  The sender's "coin" has to come from a bank trusted by the
recipient to have reasonable (not perfect) double-spending prevention
and only the recipient and the bank are involved in the transaction once
the sender's identity is presented.

Substitute "recipient's agent" (e.g., ISP) where appropriate.

The sender's identity doesn't even have to be authenticated, because the
bank has a trusted relationship with the recipient and the recipient can
be authenticated.  To reduce the impact of identity theft, the bank can
(for example, and in cooperation with other banks) check the recipient's
identity against a list provided by the sender of "people who are allowed
to charge me for email."  (Note the mail can still be allowed to go ahead
if the recipient is willing to issue a stamp without payment.)  There can
be controls on the size of the list and how rapidly it's allowed to change
without out-of-band communication, like a watch list on a credit card, to
limit scripted manipulation by an pwn3d computer.

Yes, all of this takes a lot of setup that doesn't happen now.  There are
still a whole variety of questions about whether it's viable to create
such a system.  But can we please stop arguing from the assumption that
senders can arbitrarily print and re-use one stamp for many recipients?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Michael Thomas <[email-masked]>
Date: Wed, 03 Dec 2008 08:47:03 -0800

> I see some conceptual similarities between this epostage proposal and DKIM.

Well, I don't. At least at this level: there was a huge amount of
noise about the so-called "replay" problem that DKIM didn't prevent
when we were developing the spec. The problem is that "replay" is
a feature of 821/822, not a bug. Preventing it is to make it something
other than the email we all use and love. Which is fine: well known
port numbers are still plentiful, and a global system that isn't
SMTP that prevents "replay" is available for anybody to code,
deploy, and evangelize. But it necessarily won't have the same
characteristics as email as we know it.

Really, I don't know why people who think that some postage
scheme would be a better alternative to email as we use it today
don't just do it. If it's good, people will start using it, and
there's plenty of precedent that you don't need the ossified
IETF's blessing to make something popular. Indeed, the opposite
is likely true. But for goodness sake, stop trying to graft it
onto 821/822; it just annoys the pig.

		Mike

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 3 Dec 2008 11:29:52 -0800

On Wed, Dec 3, 2008 at 8:33 AM, Bart Schaefer <[email-masked]>wrote:

> recipient   [...]

> be authenticated.

Very nicely stated.  The risk and reward of how well the recipient's meter
works belongs solely to the recipient.  The "cost" of "coin" is implicitly
determined by the recipient in his choice of trusted "banks".

> senders can arbitrarily print and re-use one stamp for many recipients?

Thank you.  And can we accept that the technical aspects of coin/stamp
exchange
as part of SMTP are segregable from the technical aspects of secure coinage?

ePostage coin doesn't "have" to be based on micropayments, there might
be "banks" that issue coin based on corporate identity, TLD registration,
DNSBL status, transfer of iTunes credits or sender bonding.  The recipient
chooses which banks to trust, and the system of payment between sender and
recipient is thus independent of whether or not an electronic proof of
intent ("coin")
can be exchanged between two unknown parties over an unsecure medium.

I think the question boils down to whether a recipient and sender can
"handshake" on a trusted 3rd party ("bank").   Not a central bank, but one
out of all such banks where they both have accounts.  The transaction
within the bank is separate from the transaction in SMTP that exchanged
the "coin".

Personally, I believe that the "stamp" exchange that Bart described
can be done via HTTPS prior to an SMTP connection and the retrieved
"stamp" is used to verify a "coin" exchange from any sender.
The sender is "verified" by the redeeming "bank" according to their
standards.

I really don't care to argue whether "coin" should cost 1 cent or
5 cents or whether "wanted" mail should be free, or some quota should
be "free".   I think it's analogous to how individual DNSBL's choose to
list and unlist IP's (versus the DNS software that they run on).  The
question of what rules I want applied for my inbox are implicit in which
DNSBL's I configure in my MTA/MUA.   Similarly, I think all of the questions

related to value and reliability of "coin" should be determined by a
recipient's choice to accept "coin" issued by various "banks".

For all of the discussion about ePostage, I only see arguments against
security of banks and coins and what is viewed as acceptable value.
I haven't seen anything that makes me conclude that a single "coin"
transaction between unknown recipient and sender is impossible.

Gerald

---

From: John Levine <[email-masked]>
Date: 3 Dec 2008 21:26:56 -0000

>> But can we please stop arguing from the assumption that senders can
>> arbitrarily print and re-use one stamp for many recipients?

In the scenario above, what happens when a sender buys one coin and
simultaneously presents it to 1000 recipients?

R's,
John

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 3 Dec 2008 14:05:26 -0800

On Wed, Dec 3, 2008 at 1:26 PM, John Levine <[email-masked]> wrote:

> On a practical level, his bank receives complaints from a small percentage
of the 999 potential fraud victims and revokes his account.

On a technical level, those 999 recipients immediately recognize, without
any
3rd party verification to the bank, that the "coin" was not wrapped in their
"stamp",
and they reject it.  Only the one recipient who recieved the initial
presentation
of identity step ("request for stamp") accepts the message, opens the coin,
and presents it to the bank for redemption.

To take your question a step further.  Assume that the perpetrator
buys one valid coin and presents identity to 1000 recipients asking
each for a "stamp".  He then wraps a copy of the coin in each of
the 1000 recipient stamps.  Each of the 1000 recipients recognize
a coin wrapped in their own stamp and opens the coin and attempts
to redeem it with the bank, which only redeems the first such coin,
but is alerted to attempted fraud and revokes the sender's account.

Recipients would automate feedback of coin rejection into their
stamp generator by monitoring their bank's account rejection watchlist,
which might be an RSS feed or a specialized type of DNSBL. In any
case, there is crypto identity in the coin, and timing built into
the recipient's stamp generator.  The vulnerability timeframe for recipients

is how long it takes for two of the same coins to show up at the bank
and for the bank to get an alert into the feedback loop so that other stamp
generators start refusing the requesting identity back at Step 1.

Gerald

---

From: Barry Shein <[email-masked]>
Date: Wed, 3 Dec 2008 17:15:56 -0500

> If you have a thousand different certs, you need a thousand DNS

One would only need a "cert" to create a stamp for a message. You
don't need a cert for every stamp or whatever it is you're saying.

 > that web browsers have now.  No question, we know how to do that.

Ok.

 > hands and ignore that problem for now.

Ok.

 > number of messages, so you need some way to tell them apart so you can

Well, there are two things here:

a) How can the issuer count them.

b) How can someone else detect a duplicate later if they were so
interested.

The issuer, for a consumer isp that'd be the ISP's MTAs, could just
keep a simple count by sender and do what they like policy-wise with
that info.

It's "b" which makes it interesting; how do we let everyone
(interested) participate.

So a "stamp" should be designed to have a signature from the MTA
identifying the "postage meter" and a serial number or equivalent,
both in a format difficult to forge or tamper with.

But the postage meter part only needs one "cert" for a realm, in
theory. It could have more but one is enough, much like SSL certs.

 > they manually take them out of the recipients' list of issuers.

That's fine. If the spam isn't bothering them then by all means accept
all those "Dewey, Cheathem, & Howe" signed certs.

I've said before you should be free to accept totally unstamped email
if you like so that's just a special case. There's also accepting only
stamped email but not checking if the stamp is valid. It's your
system.

But if I'm BIGISP and first I say: we only accept email with valid
stamps and then I say "forthwith stamps signed by Dewey, Cheatem, &
Howe are not valid and will be rejected" then oh well, I guess Mr
Spammer who uses Dewey, Cheatem & Howe is out of business.

The key to all this spam nonsense is not that you could choose to
accept the spam, of course you can, the key is creating a way that you
can (reliably) choose NOT to accept it.

Of course, add in the economic motivation and the game gets a little
more serious.

If the ISP et al is being paid a cut of the postage they accept,
perhaps in the simplest case even as just debray of their own postage
costs, then they're motivated not to accept from cheaters.

Not because they're cheaters only, but because a cheater WON'T BE ABLE
TO PAY!

You'd be like a bank issuing credit cards to really bad
customers. Good luck! How ya gonna pay the merchants if you keep that
up?

So to some extent, and at some point, it's self correcting.

You just left out the money part. The money part is really, really
important, just as it is with paper mail postage.

If Pitney & Bowes could sell you postage meters which didn't really
check how much you used sure they'd get popular! But I suspect their
business model would fail soon enough. Among other things the post
office would refuse to let them continue doing that, but therein it's
a slightly different situation. But suffice it to say the economics
couldn't work.

 > other half will still be delivering a lot of spam.

Again, toss the economics back in and see if you still believe that.

Spamco isn't paying postage just to make Dewey, Cheatem & Howe
(heretofore DCH) epostage meter company rich. They're paying it so DCH
can pass part of that postage towards the recipients. We're creating
an ecosystem here.

If DCH is allowing customers to fraud how do they pay their
settlements?

 > out who's the cheapest, found someone selling them for $12.95

Ok, see again there are N facts and you base your argument on N-1 or
N-2.

Since spammers need zombie bot armies to achieve IP mobility,
otherwise we'd just block their servers and be done with them, they'd
have to have a valid "cert" for each of the million zombies.

Even at $12.95 per each a million gets pretty expensive!

I think part of what we keep putting out of our minds is:

   How MUCH of an economic disincentive would it take to put the
   zombie bot army spammers (I am so glad to live in a world where I
   can use that phrase!) out of business?

I say: If it were even superficially enforceable? Not much!

But it's hard to say what that number is exactly.

My instincts say add $100K or so per year to their costs and they'd go
back to kidnapping people's pets for vivisection experiments or
whatever they used to do for a living.

Maybe it's more. Maybe it's less.

I'm pretty sure $1M/year is way beyond their means.

  I know, you want to talk about enforcement right here.

  But let's try to focus on what a goal might be?

I suspect, how could we measure this?, that there'd be some
exponential drop-off of spammers probably starting at a pretty small
number: Force them to pay (this is all additional to their current
costs) $10K/year and maybe 50% are gone, $100K/year, 90% are gone,
$1M/year, 99.9%, maybe even so close to 100% it's not worth debating.

Anyhow, that's something like a goal with numbers even if only
estimates, it's a mathematical model I don't think I've seen before.

 > matter of time before those race to the bottom, too.

Well, I think I answered this.

 > hardware in hostile environments has resisted attack.

No, no special hardware, I take that as a given. I can't say that at
some advanced point that, just like crypto chips, something might be
sunk in hardware but that oughtn't be a pre-requisite.

But their opportunity to crack these software meters should be roughly
the same as their opportunity to crack SSL certificates. That would be
a reasonable first goal.

 > acting against their very short term interests is unlikely to work.

Even if those interests include money?

A lot of the motivation here is to create an economy around email
which works against spammers, both explicitly (difficult to forge
postage) and implicitly (motivates and pays for enforcement.)

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Wed, 3 Dec 2008 17:17:49 -0500

FWIW, Paul Russell "gets it".

Or at least "gets" what I'm trying to say here.

Which either means y'all now have two crazy people here or...:-)

-- 
        -Barry Shein

---

From: "David Nicol" <[email-masked]>
Date: Wed, 3 Dec 2008 17:28:32 -0600

> simultaneously presents it to 1000 recipients?

Opposed to Gerald's bearer token scenario, in my book-entry scenario,
the first recipient to apply for the transaction lock on the sender's
account would get the coin, and the other 999 would get NSF errors.

-- 
"Refusing to move when ordered, he was tragically mulched." -- The Onion
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 4 Dec 2008 01:06:45 -0000

>but is alerted to attempted fraud and revokes the sender's account.

OK, that sounds like the usual micropayment token cancelling
bottleneck that nobody knows how to scale.

Nonetheless, if people think they have a viable design for e-postage
or anything else, I really wish you would write it up as a draft.
Even if it has fatal flaws and turns out to be a dead end, at the very
least you'll document where you end up if you go down that road so we
don't have to have the same fripping argument every year.

The IRTF has a new RFC process that is quite unlike the IETF's.  Some
drafts (like my DNSBL one) have the consensus of the whole RG, but
it's quite OK to advance a draft that only a few people like, so long
as there's a group of people who agree that that it's interesting, and
it satisfies a few administrative rules that won't be an issue here.

So get to work.

R's,
John

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 03 Dec 2008 18:24:20 -0800

On Dec 3,  9:26pm, John Levine wrote:
} Subject: Re: [Asrg] The fundamental misconception about POSTAGE METERS
}
} >> All the sender does is present his identity.  The recipient's postage
} >> meter issues a stamp which is only good for sending one message to that
} >> recipient.  The sender's "coin" has to come from a bank trusted by the
} >> recipient   [...]
} 
} >> But can we please stop arguing from the assumption that senders can
} >> arbitrarily print and re-use one stamp for many recipients?
} 
} In the scenario above, what happens when a sender buys one coin and
} simultaneously presents it to 1000 recipients?

Whether this question makes sense depends on which scheme you're asking
about.

In Gerald's HTTP/URL based out-of-band exchange, the sender has to get
a token from the recipient before he even begins the SMTP transaction,
so purchasing from multiple recipients with the same coin is a danger.
The paper to which I previously sent a pointer makes the claim that
it's possible to control the degree of duplicate spending in this kind
of situation.

I don't think I grasp Don's Advenge idea well enough to say whether it
poses the same problem.

In my proposed in-band SMTP extension approach, the sender never buys
a coin and never has control of a recipient-generated token.  The coin
exchange is carried out between the bank and the recipient, and the
recipient has to agree about which bank to trust.  All the sender can
do is describe a bank where he has pre-deposited funds from which the
recipient can obtain a coin, and the maximum denomination of coin he's
willing to spend.  Think of it as postage ETRN.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 3 Dec 2008 21:42:33 -0500

On Wed, Dec 03, 2008 at 09:30:14AM -0500, Paul Russell wrote:
> Human nature guarantees that someone somewhere will attempt to thwart
> any technology that might make a significant dent in the spam problem.
> If universal simultaneous deployment and total infallibility are
> non-negotiable requirements for any proposal, then nothing will ever
> be done.

I concur, but I do think one non-negotiable requirement for any proposal
is that it must not be one that spammers have already defeated.
That rules out *anything* that depends on the presumed integrity of
end-user systems.

I think there are other design principles that can be applied as well,
e.g., "anything that generates still more SMTP traffic is probably headed
the wrong direction" and "anything that presumes spammers will passively
(or actively) cooperate won't work", and so on.

---Rsk

---

From: Barry Shein <[email-masked]>
Date: Wed, 3 Dec 2008 22:24:05 -0500

> simultaneously presents it to 1000 recipients?

Although possibly a moral risk (i.e., it offends one's sense of
fairness), presenting it to 1,000 recipients isn't really the problem.

It's when they present it a million times that they can actually be a
noticeable problem.

At which point they'll probably get caught, someone like World would
have an incentive to watch them go by for example, and then won't be
able to buy a cert again or whatever punishment is in store for them.

We have to keep saying to ourselves: Spammers need to send on the
order of billions of messages per day, by and large for free, to be
the problem they are.

Any time one scales it down to try to draw an example they're throwing
the baby out with the bathwater. Use numbers like "millions" and see
if it still seems so intractable.

-- 
        -Barry Shein

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 3 Dec 2008 21:58:45 -0800

> bottleneck that nobody knows how to scale.
Actually, micropayment cancelling isn't the part of the story I'm
advocating, I'm advocating for a standard for transmission of coins.

I really don't care how they're franked, what their value is, or how
they are verified.  What  I provided above is only a single "bank"
example as an extension to your question,  please don't
forget there is the trivial example where the coin is NULL, i.e.,
the recipient chooses to accept stamped mail without coins.
Thus there is only the initial sender presentation of identity and
the recipient "stamp-generator" issues a stamp (or not) based
solely on the identity and properties of the TCP session.
The NULL coin example may not be very interesting, but it's
pretty close to what Barry's talking about with SSL-type
issue of identities.  Where is that scaling problem when
no "bank" is involved in individual mail transactions,
only the initial set-up of identities?

Gerald

---

From: John Levine <[email-masked]>
Date: 5 Dec 2008 00:16:17 -0000

>advocating, I'm advocating for a standard for transmission of coins.

If you've figured out a way to deter double spending without
cancelling the spent coins, I know a lot of people who'd like to hear
about it.

So anyway, whatever it is you propose to do, please write it up.

R's,
John

---

From: "David Nicol" <[email-masked]>
Date: Fri, 5 Dec 2008 13:47:32 -0600

> it satisfies a few administrative rules that won't be an issue here.

So what would be required to put GPTP back on the gameboard?

---

From: John Leslie <[email-masked]>
Date: Sun, 14 Dec 2008 06:59:27 -0500

There is an Internet Draft at

https://datatracker.ietf.org/drafts/draft-irtf-asrg-postage/

   (I don't think there's any automated posting to an IRTF WG.)

   I attach a HTML version.

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