On 25 Dec 2008 at 10:29, Stephen J. Turnbull wrote: > Bernie Cosell writes:
> > [same as with the USPS > > Aye, there's the rub. The USPS is, even today, a state(-protected) > monopoly. Email is not, and cannot be, unless you make the whole > Internet a state monopoly. What I was suggesting was not to model it on the USPS directly but on the *international* postal system. What I had in mind was the rough analog of considering each SMTP server as being sort-of a country-unto-itself and so settling its "international" email accounts with other SMTP servers in sort of the way the USPS and CanadaPost and RoyalMail and .. all do. > > Actually, this is backwards. email *started* that way [remember that > > forwarding was provided for and there was even that cute explicit-routing > > form of email address] and has, IMO, evolved off into needing to be > > *more*like* Christmas cards. > > 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). Right, and in my model I can treat *my* SMTP server as a well-behaved black box. > .. 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 an unnecessary frill and a relic of the 1800s. All that's required is that the sending SMTP server and the receiving SMTP server keep accounts. But note that this is *exactly* what has to happen with international mail. CanadaPost doesn't [directly] get any of my 57cents [or whatever it is] when I send a letter from the US to Canada -- it is accounted for and the USPS [as I understand it] "banks" the extra 15 cents and then clears accounts with CanadaPost at some interval [annually?]. Nobody transfer "micropayments" across the border. > ... 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. Not at all true. Email isn't transmitted by IP packets, it is transmitted by TCP connections from one SMTP server to another and so provenance isn't in question. A receiving SMTP server knows *exactly* which SMTP server is sending the message and could easily 1) decide whether or not to accept the connection based on whether the sending-server was a "deadbeat" or not, and & 2) keep a record [that'd be matched by the outgoing logs at the sending SMTP server] of the traffic so that at some interval the two could rectify accounts. Note that in what I was suggesting, the receiving SMTP server doesn't know or care what _individual_ sent the message, only that it came from SMTP-server-X. SMTP-server-X can decide how *IT* wants to pass on the cost of sending the message [or not!] to whomever *it* accepted the message from, be it one of their customers or some other SMTP server. > ... all that will happen is that the email network will become > disconnected (as we are currently observing, anyway): a "backbone > cabal" of email providers will evolve, and people with Linux boxes etc > will set up wildcat SMTP networks along the lines of the old UUCP > network. I doubt that. If google and AOL and just a few others refuse email from any SMTP server that doesn't have a transfer-account-in-good-standing, I doubt that the 'wildcatters' will get very far. I'm not convinced that the scheme will work, but it really doesn't require any changes in SMTP or required assured-authenications or micropayments or anything along those lines, and so it *might* work. Note, too, that 'satellite' SMTP servers can play along if they choose : if I'm mycompany.com and I don't want the bother of having a lot of email transfer payment accounts with SMTP servers around the world, there's room for a "paypal" like enterprise: I sign up with them, I use *THEM* as a relaying-smtp server [basically exactly like the way individual customers use their ISP's outgoing SMTP server] and my "email paypal" would handle all of the accounts with the other SMTP servers and I could just settle with my 'relay' by whatever contractual arrangement I'd made. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:ber...@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <-- ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9