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
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg