Subject: Re: [Asrg] Email Postage (was Re: FeedBack loops)

From: John R Levine <[email-masked]>
Date: Sat, 22 Nov 2008 15:00:22 -0500 (EST)

>> 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.

So go ahead, create one.  At worst, you'll confirm everything we've
been saying about the impossible cost and scaling problems.

Or as an older colleague said to a physicist I knew when he was
embarking on a large project, "You're young.  You'll live to see it
fail."

R's,
John
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Gerald Klaas" <[email-masked]>
Date: Sun, 23 Nov 2008 08:58:55 -0800

> embarking on a large project, "You're young.  You'll live to see it

I have done some preliminary work, but hoped to get feedback from this
group on requirements, scope and preliminary design before going further.
My primary goal has been to remain open and extensible.

My preliminary design recommends a standard for locating and using "stamps"
or "tokens":

1. Adopt an algorithm for creating a URI from an e-mail address (TGURI)
2. Adopt a like hostname, similar to "WPAD" in the draft for web proxy
auto-discovery protocol, where a token-generator is expected to reside
(TGHOST)
3. Adopt a syntax for queries to and responses from a token-generator (TGRC)
4. Adopt a standard name for an SMTP "X-header"

Note that there is nothing about how a token-generator works, just how to
locate one and what inputs and outputs to expect.   Decisions about
risk/reward/value related to the token generator are managed by the owner of
the generator (i.e., the mail recipient)

My preliminary design suggests that the URI algorithm (1) create a URL based
on
an e-mail address [email-masked] that looks like:

http://TGHOST.domain.tld/upper(decode(LHS<http://tghost.domain.tld/upper(decode(LHS>))
where decode(X) replaces URL special characters with underscores

( I understand that this limits input syntax to the TG to the HTTP syntax,
so I ask the group if it makes sense to define the URI as a totally new
protocal and assign a port? )

If the URI is as suggested, then the query is "GET /upper(decode(LHTS))"
which means all the TG has to work with is the originating IP address and
the intended recipient (and possibly any standard environmental variables
and cookies).  Is that enough to make a reasonable decision, or might it be
beneficial to append query_string variables?
What might those variables be?  Personally, I could see a trivial TG that
does nothing more
than encode the requesting IP with the intended recipient address and
datestamp.  The
"strength" of this approach comes not from the "strength" of an individual
stamp, but from
the infinite permutations of such an implementation, such that a spammer
would have to
expend effort (above their value threshold) to attempt to counterfeit for
individual recipients.

I suggest that the response codes (TGRC) include:

DNS NXDOMAIN (TGHOST not found, send mail without a token)
HTTP TGURI 404  (TGURL not found, send mail without a token)
HTTP TGURI 302 (URL redirect. Likely to a leveraged token service.)

TGRC LIST (TG responds to requestor with a list of all methods the
recipient uses to validate e-mails.  This might include a method that
filters on the recipient's Contact list, or indicate to the sendor that
a prior Message-ID sent by the recipient can be used as a token,
or that the recipient accepts hashcash, or some TBD new method,
for example, the recipient requires a certain micropayment from a
leveraged TG service.)

TGRC:TokenType[extenstion,string-data] (sender uses "string-data" to perform
the
actions defined by the "extenstion" method.  In the trivial example above,
the suggested method would require the token retrieved from the recipient's
web server to be placed in an SMTP X-header that the recipient
subsequently uses to filter (either at the MTA or MUA).  In the
TBD micropayment example, a method might be defined where the
recipient only accepts 1 cent stamps from PayPal or some other
clearinghouse.

Again, it's totally up to the recipient what methods they choose
to accept, but with the TGURI definition, they have the ability to
pre-notify senders what those methods are, whether those methods
are "not applied" (i.e., SMTP today) or some pointer to a defined
method, some of which will wind up being open, low cost or no
cost, and some of which are likely to point to proprietary micropayment
systems.

Gerald

---

From: Bart Schaefer <[email-masked]>
Date: Sun, 23 Nov 2008 12:11:42 -0800

On Nov 23,  8:58am, Gerald Klaas wrote:
}
} My preliminary design recommends a standard for locating and using
} "stamps" or "tokens":

I think you've gone wrong right there.  In the SMTP-based approach
that I outlined, there is no prepaid token that can be copied and
attached to multiple messages.  Instead there's first an agreement
on a payment provider, and then an agreement on an amount, and it's
up to the receiver to collect.  No race condition on multiple checks
for uniqueness of the token, and no need for the recipient to provide
anything except acceptance of the terms.

Also no transaction at all outside the SMTP stream if the recipient
chooses not to collect.  Email negotiating a suspect payment service
could be quarantined until payment clears.  Blacklists of known-bad
payment services could be created and used to stop the conversation
at MAIL FROM.  Collections from well-trusted payment services could
be batched and infrequently resolved, to reduce transaction volume.
 
} 1. Adopt an algorithm for creating a URI from an e-mail address (TGURI)
} 2. Adopt a like hostname, similar to "WPAD" in the draft for web proxy
} auto-discovery protocol, where a token-generator is expected to reside
} (TGHOST)

This strikes me as too simple.  It requires every domain to support at
least a listener to redirect to the payment service.  Identifying the
payment service as a parameter to the SMTP MAIL command avoids this,
including avoiding the extra round-trips for redirects.

An SMTP extension does NOT solve the problem of determining whether the
client is authorized to negotiate a particular combination of sender
and payment service.  You'd need at least something SPF-like for that,
but maybe that can just be ignored, because:

It also doesn't solve the problem of pwned hardware negotiating under
the identity of its real owner, but it would permit the payment service
to enumerate (say, on the monthly bill) every email address to which a
paid delivery was made.  So if you pay attention you can find out that
your email identity has been stolen, just as now you review the list of
calls on your phone bill to see if you've been charged for a call that
you didn't make.

The payment service could also put a contractual limit on the number of
different recipient addresses for which it will authorize payment for a
given sender.  That's better than a cash value limit, for most senders.

} 3. Adopt a syntax for queries to and responses from a token-generator (TGRC)
} 4. Adopt a standard name for an SMTP "X-header"

The SMTP extension approach doesn't need the X-header except in cases
where the message must pass through a relay that doesn't support the
extension.  The equivalent of "cancelling the stamp" happens at final
delivery and can be proprietary to the recipient's mailbox provider,
so that an outside entity can't slip in a forged cancellation mark.

} Note that there is nothing about how a token-generator works, just how
} to locate one and what inputs and outputs to expect. Decisions about
} risk/reward/value related to the token generator are managed by the
} owner of the generator (i.e., the mail recipient)

Same for an SMTP extension, except there's no generator involved.

} Again, it's totally up to the recipient what methods they choose
} to accept, but with the TGURI definition, they have the ability to
} pre-notify senders what those methods are, whether those methods are
} "not applied" (i.e., SMTP today) or some pointer to a defined method,
} some of which will wind up being open, low cost or no cost, and some
} of which are likely to point to proprietary micropayment systems.

Replace "TGURI" with "SMTP MAIL parameter" and this all remains true.

I still have doubts about scalability and about the willingness of ISP
mailbox providers to take responsibility for handling the transactions.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Al Iverson" <[email-masked]>
Date: Sun, 23 Nov 2008 16:46:59 -0600

BTW, is Goodmail patented? They seem to already have the whole
per-message authenticated token thing worked out.. You buy the tokens,
and once per message, a token is obtained from the token pool and
applied to the message. That message gets special treatment at an ISP.

Seems to be already built, though it took them a hell of a long time
to get some adoption -- and they have a great gap in that Hotmail does
not participate. Hope you've got a rather large amount of venture
capital behind you to make this happen.

Also, I don't see how any sort of "Pay for email system" as (yet
again) described on an anti-spam mailing list solves the issue that we
all have to buy into your system before it'll work. Brings me back to
the point above -- even after spending tens (hundreds?) of millions of
dollars to get ISPs interested in Goodmail, they will have, at best,
about a 60% adoption rate.

And their system requires fewer fundamental changes to an ISP's
backend than yours does.

Regards,
Al Iverson

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

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

>BTW, is Goodmail patented?

Why guess, since you can visit the USPTO web site and find out the
facts in about 30 seconds?

A search for Goodmail as patent assignee turns up nothing, which tells
us fairly definitively that they have no patents in the US.  I suppose
they might have filed in other places first, but that seems very
unlikely.

A search of published applications turns up one by Daniel Dreyman,
whom we all know.  But it's an application, which is a long way from
being a granted patent, and it's about authorization, not postage, so
it's irrelevant to this argument.

R's,
John

---

From: Bart Schaefer <[email-masked]>
Date: Sun, 23 Nov 2008 21:35:24 -0800

On Nov 23,  4:46pm, Al Iverson wrote:
}
} [Goodmail seems] to already have the whole per-message authenticated
} token thing worked out.. You buy the tokens, and once per message, a
} token is obtained from the token pool and applied to the message. That
} message gets special treatment at an ISP.

Yep.  Hence my earlier analogy of sump pumps versus rubber rafts.
Messages in Goodmail's raft float above the flood, but it doesn't
reduce the amount of water.  The same goes for SenderScoreCertified
and brandmailsolutions.com and all the other whitelisting schemes.
As long as it's cheaper to add rafts, no one will start pumping.

} Also, I don't see how any sort of "Pay for email system" as (yet
} again) described on an anti-spam mailing list solves the issue that
} we all have to buy into your system before it'll work.

I'm *almost* entirely with you on that.  Describing the payment
framework came about because of this bit of the thread:
http://www.irtf.org/pipermail/asrg/2008-November/003963.html
http://www.irtf.org/pipermail/asrg/2008-November/003969.html
http://www.irtf.org/pipermail/asrg/2008-November/003971.html

(Gerald's "objections" to Goodmail are at the end of that last one.)

I say "almost" because as soon as any two cooperating entities get
on board, they've gotten at least as far as Goodmail has: email
between those two entities can float above the flood.  A whole lot
more entities must be involved before the water starts to go down.

} And their system requires fewer fundamental changes to an ISP's
} backend than yours does.

Agreed again.  On the other hand, that whole thing falls apart if
Goodmail doesn't succeed, and either way -- unless Goodmail manages
to convince everyone to pay them and becomes the universal solution,
so anything not processed by Goodmail can be outright rejected --
at the end there's still just as much spam as ever.

The suggestion was to chop up the technical problem.  Assume how the
money (or whatever) moves around is a black box, and instead describe
how to attach to an email the information about who moves it and how
much.  OK, so I've described one way, and Gerald another.  Gerald
suggests a token pool like Goodmail's, but distributed among all the
recipients; everyone becomes their own little Goodmail, with an
auto-generated URL to contact the "imprinter" (to steal Goodmail's
name for it).  I like my suggestion because it doesn't need any
"token pool" at all.  End of that discussion unless somebody else is
interested.

Now somebody needs to explain how the economics work.  Pick whichever
framework you think is less burdensome and describe why you think an
ISP could extract enough value from it to actually bother building it.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "Al Iverson" <[email-masked]>
Date: Sun, 23 Nov 2008 23:57:32 -0600

> ISP could extract enough value from it to actually bother building it.

Not me -- I personally don't think the value proposition is sound.

Best,
Al Iverson

---

From: "Gerald Klaas" <[email-masked]>
Date: Mon, 24 Nov 2008 16:24:12 -0800

On Sun, Nov 23, 2008 at 9:35 PM, Bart Schaefer <[email-masked]>wrote:

> reduce the amount of water.

In a closed, proprietary system, where the senders pay a fee to
Goodmail, which I assume is at least partially paid to the participating
ISP's.  So essentially, the ISP's get paid for delivering what the
USPS calls "Bulk Business Mail"(BBM).

>>ISP could extract enough value from it to actually bother building it.

Goodmail has already shown that tokens can work, and that the
economics can work.  I think the question becomes, is the Goodmail
profit margin big enough that large ISP's would be interested in
transitioning
to an open, non-proprietary system where they can sell tokens to large
BBM senders directly (and keep Goodmail's cut of the action) ?

>>"token pool" at all.

Excellent paraphrase of my idea.  Adoption of an open standard
for token transport would allow recipients to continue using Goodmail
if they wanted, become their own "imprinter", or allow competing
service providers.

> The same goes for SenderScoreCertified

Can that go on forever?  I don't know.   It seems to me that the
current evolution of "e-mail" is going to closed systems, like "message
areas" in social networking sites.

> } we all have to buy into your system before it'll work.
That's not true.  Bart has it correct (notation below), it only takes two to

make it worthwhile for them with incremental benefit as more players
enter.

> at the end there's still just as much spam as ever.

This time I disagree with both of you.  My recommendation requires
three configuration changes and a franking script.
1. DNS entry for (TGHOST.domain.tld)
2. VHOST configuration on a (likely leveraged) web server for TGHOST
3. Franking script at TGURI
4. Token filter rule at MTA or MUA (depending on if ISP or end
user implementation)

It is true that in both cases, the sender has to pick a token and affix it,
so some program has to perform that function.  I consider that the same
between systems.

>>much.  OK, so I've described one way, and Gerald another.
>>End of that discussion unless somebody else is  interested.

I have to admit that I find the idea of debiting a sender chargeback through
an
SMTP-extension to be an interesting idea.  I don't currently understand
Bart's
intended process for sender authentication, and as we agreed, the money
movement should be viewed as "black box".

The reason I prefer a "token" system over an extension to MTA conversation
is that a token system can be implemented by a smart MUA without the
cooperation of their ISP.

Gerald

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 25 Nov 2008 10:45:15 -0700

On 24/11/2008 17:24, "Gerald Klaas" <[email-masked]> wrote:

> profit margin big enough that large ISP's would be interested in transitioning

Doesn't look like it, so far.  I suppose that could change in the future,
but right now ISPs are still forced to more in anti-spam technology than in
pro-marketing technology.

But in any case, remember that a standardized token-clearing system won't be
the end of the story -- or even the beginning.  As Daniel Dreymann pointed
out, "It was a challenge to build a scalable clearinghouse...but the
processes supporting the accreditation of senders, reputation monitoring,
security, feedback loops, reporting, UI, etc. have proven to be at least as
complex."

---

From: "Gerald Klaas" <[email-masked]>
Date: Wed, 26 Nov 2008 19:16:01 -0800

> security, feedback loops, reporting, UI, etc. have proven to be at least as
I completely agree.  That's one of the main reasons I think the discussion
needs to be split between how a transaction occurs, whether through tokens
or
ESMTP extension, or some new TBD MTA technology and then
what happens within the transaction whether it's micropayment, sender
authentication, hashcash, value transfer, etc.

>From my view, there's great benefit in understanding the requirements of
a system before trying to build it. ( But then maybe I've had too many
professors and managers preaching to me about SDLC. )

In the reading I've done on hashcash, it seems there is valid debate about
whether or not e-mail should ever be "allowed" to be anonymous.

It seems there's usually valid debate on this list about whether or not
e-mail should include per piece metering (to include micropayments).

If one were to assume that a recipient should be able to determine their
own requirements with respect to veracity of sender identity and "cost"
related to bypassing SPAM filters, would such a system even be possible?
Would it make sense to allow users the freedom to make such choices?
Or are we debating with preconcieved notions that ISP's need to make
global decisions about these two parameters before any new technology
can succeed?

Every closed system I've seen makes some global decision about how
to verify senders, and the cost related to messages.   Are we debating
the answers to globally unanswerable questions?  Personally, I see
those answers as a configuration requirement for individual recipient
profiles in the FUSSP.  Recipients have to be able to answer those questions
for themselves and accept the risk and reward of their choices.

There are lots of people who already use personal filters that try to strike
a balance.  For example, Scott Adams requires "Dilbert" to be in the subject
line
of incoming mail.  His sender identity test isn't the same as what Goodmail
uses,
his only requires senders to know his "public key".    His "public key"
isn't
used as an encryption key, and it isn't distributed the same way as PGP
keys,
but it is effective *enough* for his purposes.

I whole heartedly agree that any FUSSP that uses micropayments will
have a huge sender identity and verification issue, but isn't that external
to how notice of a micropayment is transferred in a mail exchange?  Maybe
for a lot of users, sender identity at the level of "Dilbert" is good
enough.
Who should choose, the recipient or his ISP?

Gerald