
On Thu, 2008-12-25 at 10:29 +0900, Stephen J. Turnbull wrote:
Including a national monopoly email provider, I guess? What I interpret Lindsay to be saying is that for Christmas cards you can treat the USPS as a well-behaved black box (in the systems analysis sense; it may or may not do the job it claims to do at all well, but you can figure out what job it reliably does). In particular you can determine that a piece of mail was properly paid for by the addressee because each and every one has postage *attached*, not merely "accounted for" somewhere. This is not true for ICMP or for email as currently designed; there is no way to determine the provenance of a packet in general.
To carry this analogy a bit further, here's an idea. IPv6 provides a substantial improvement in flexibility over IPv4, and the upgrade path from IPv4 to IPv6 is clear and relatively seamless. Would it not be possible to establish a dual-key cryptographic packet signature protocol for email sent using IPv6, applied at a packet level, and this signature could be authenticated against a private key, present only (or indicating) if the email sent using these packets has been been paid for?
For v4 systems behind a IPv6->IPv4 gateway the v6 wrapper would be stripped away and the encapsulated email would be delivered normally, along with all the spam sent to it. For SMTP servers that are truly v6-aware and running on a v6 network it would be possible to verify the payment signature contained in the packet extensions and discriminate between paid-for email and spam.
Perhaps the payment-autentication system could be developed in the context of a distributed database resembling that used for DNS, or more like DNSSEC, perhaps.
Piggybacking this SMTP extension on the top of the already robust IPv6 standard would provide the flexibility for system that were not IPv6 aware to opt out of the signature system and accept _all_ email. The logical key here is that it's up to the _originating_ SMTP system to obtain a cryptographic key and negotiate payment. It's up to the _receiving_ system to decide whether to discriminate between paid-for email and unpaid email, so as to reject it, pre-tag it, or deal with it in some other fashion with the (v4) default being to treat all inbound email as it's treated now.
This would not require a re-design of SMTP, only an extension of it.
If this were feasible, it would certainly spur the deployment of IPv6 which could stand a kick in the ass.
-- Lindsay Haisley |"Fighting against human | PGP public key FMP Computer Services | creativity is like | available at 512-259-1190 | trying to eradicate |<http://pubkeys.fmp.com> http://www.fmp.com | dandelions" | | (Pamela Jones) |