On Sat, May 30, 2015 at 1:29 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > On 26 May 2015 at 16:29, Adrian Hope-Bailie <adrian@ripple.com> wrote: > >> There is no double-spend problem to overcome in designing a system to >> send email over the Internet. >> > If double-sends were a problem, SMTP would have several serious race conditions in it, but as information transmittal is strengthened by redundancy, there is no problem. Two messages with the same message-ID is conceivably a problem, but message-ID uniqueness is again not important enough to really bother with, aside from mitigating double-sends. The fundamental piece to mitigate double-spending is the single-use token. In e-mail, the single-use token is the message-ID. When a MTA receives a message with a message-ID it has already received for a given addressee, it needn't deliver it (in theory AIUI anyway. Could be wrong, haven't checked RFCs on this point while writing this.) Block-chain enforces single-spend by insisting the next block validity. Centralized ledgers can enforce single-spend with row locking. Decentralized ledgers without a double-spend mitigation mechanism (it's easy to imagine alternatives to block-chain) simply aren't workable. And yes, double-sent e-mail is a problem, but it is a mild one, and how a MUA (or listserv software) deals with receiving the same message both directly and from a mailing list (as this message will be delivered, to four recipients who are on the mailing list it is also sent to) is a user experience design choice, as there isn't that much riding on it. For instance, listserv software might not bother to deliver to a recipient listed in the message headers, I think that's a fair optimization listserv software may do. -- 8mm shafts with 5/16" 24 TPI threads
Received on Monday, 1 June 2015 13:31:04 UTC