On Sat, Nov 22, 2008 at 12:00 PM, John R Levine <johnl(_at_)taugh(_dot_)com>
wrote:
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
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 LHS(_at_)domain(_dot_)tld 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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg