{"id":2002,"date":"2016-11-26T18:35:31","date_gmt":"2016-11-26T15:35:31","guid":{"rendered":"http:\/\/www.gatchev.info\/blog\/?p=2002"},"modified":"2016-11-26T18:35:31","modified_gmt":"2016-11-26T15:35:31","slug":"canning-the-spam-by-crypto-payments","status":"publish","type":"post","link":"http:\/\/www.gatchev.info\/blog\/?p=2002","title":{"rendered":"Canning the spam by crypto-payments"},"content":{"rendered":"<p>Many methods to fight spam and e-mail viruses decrease them, but nowhere close to zero. This is an attempt to describe a method that will practically stop them.<\/p>\n<p><strong>Attaching payments to e-mail<\/strong><\/p>\n<p>The essence is to attach to every e-mail a payment to the receiver. E-mail that does not carry a payment should be discarded by the receiver&#8217;s software. If an e-mail carries a valid payment, that is automatically extracted into a receiver&#8217;s wallet, and the e-mail is presented to the receiver. The wallet can be used by the receiver to attach payments to outgoing e-mail, and\/or to deposit \/ withdraw sums.<\/p>\n<p>The size of the payment should be negligible in a real e-mail correspondence, but prohibitively big for a mass-mailing spammer. To ease the adoption, initially it can be symbolic, to grow later to an effective value. Methods to refund the payments in a real conversation can be used. Whitelisting can be implemented for e-mails that match specific trust criteria.<\/p>\n<p>The payment can be done in a cryptocurrency, existing or specially created for e-mail paying. In the second case, one will have to be created by the Internet governance. As its usage will be mostly legal and its market will be relatively stable, it will soon establish on the cryptocurrencies market.<\/p>\n<p>The scheme is self-imposing: after a significant amount of e-mail addresses start refusing e-mails that don&#8217;t contain payments, the others will be forced to adopt it, too.<\/p>\n<p><strong>Methods of attaching a payment<\/strong><\/p>\n<p>There are many possible. An incomplete list of suggestions follows:<\/p>\n<ul>\n<li>Adding in an e-mail a header field that contains a (confirmation of a) transaction to the receiver.<\/li>\n<li>Using specially developed e-mail exchange protocol(s) that allow for requesting a payment during the exchange.<\/li>\n<\/ul>\n<p>One or more might be defined as standard by an Internet authority.<\/p>\n<p><strong>Balancing payments<\/strong><\/p>\n<p>In a typical real e-mail conversation the number of the mails in both directions is comparable, so the cost balance of the entire conversation will be negligible. In addition, mechanisms can be introduced that periodically zero the balance in real conversations.<\/p>\n<p>Conversations might be marked \/ unmarked as real following a set of criteria. An incomplete list of suggestions follows:<\/p>\n<ul>\n<li>Manually by the reader.<\/li>\n<li>Whether the conversation contains replies (esp. if more than one; unsubscription requests might be omitted from consideration).<\/li>\n<li>Whether previous conversations with this correspondent have been marked as real.<\/li>\n<li>Validating the correspondent e-mail address \/ domain against public databases \/ lists with &#8220;non-spammers&#8221;.<\/li>\n<li>Checking the sender IP address against public blacklists and\/or whitelists during e-mail transfer<\/li>\n<li>Analyzing the message contents<\/li>\n<\/ul>\n<p>Correspondence balance is most easily zeroed by the net gainer sending a &#8220;machine-only&#8221; e-mail with a transaction containing the net profit to the net loser. There can be other possible methods, as well as additional checks designed to make the balancing methods work in practice.<\/p>\n<p><strong>Whitelisting<\/strong><\/p>\n<p>Correspondents belonging to a specific list might be exempted from the payment requirement. The list can be maintained by specific criteria. An incomplete list of suggestions follows:<\/p>\n<ul>\n<li>Manually listing \/ delisting e-mail addresses and domains by the recipient.<\/li>\n<li>Already having conversations with this correspondent.<\/li>\n<li>Validating the correspondent e-mail address \/ domain against public databases \/ lists with &#8220;non-spammers&#8221;. (In practice will require also the message to be e-signed with a trusted PKI.)<\/li>\n<li>Checking the sender IP address against public blacklists and\/or whitelists<\/li>\n<li>Analyzing the message contents<\/li>\n<\/ul>\n<p>When sending an e-mail to a whitelisted correspondent, the e-mail software might add a specific mail header that tells the correspondent&#8217;s software to not add payments when mailing back (or lack a header that gives the size of the demanded payment when writing to).<\/p>\n<p>Correspondents can be notified of being added to or removed from the whitelist by a &#8220;machine-only&#8221; e-mail (eg. containing a specific mail header). Such an e-mail will be read by the correspondent&#8217;s software and used to mark the sender as requiring or not requiring e-mail payments, and possibly to consider whitelisting the sender in response. As they are not intended for the recipient, &#8220;machine-only&#8221; e-mails will be exempted from the payment requirement.<\/p>\n<p><strong>Obtaining correspondent payment details<\/strong><\/p>\n<p>To make a payment transaction to an e-mail recipient, the sender&#8217;s software must have its wallet address. If there is no fixed payment sum per e-mail defined globally, it will be good to know also the payment amount the recipient demands per e-mail. There are many possible ways to obtain these. An incomplete list of suggestions follows:<\/p>\n<ul>\n<li>Sending a &#8220;machine-only&#8221; e-mail to the recipient that contains a request for payment details, eg. as a specific header. The recipient&#8217;s software should automatically reply with a &#8220;machine-only&#8221; e-mail containing the details, eg. in a specific header. After that, the real e-mail is sent together with the required payment.<\/li>\n<li>Obtaining the payment details from a public database \/ list.<\/li>\n<li>Using a specially designed MTA protocol that allows the MTAs to negotiate e-mail payment details.<\/li>\n<li>Replying to e-mails without payments with a &#8220;machine-only&#8221; e-mail that contains payment details, eg. in a specific header, and waiting a &#8220;machine-only&#8221; response with the payment. (Should be well-secured to prevent backscatter abuse.)<\/li>\n<\/ul>\n<p>One or more might be defined as standard by an Internet authority.<\/p>\n<p><strong>Wallet-related<\/strong><\/p>\n<p>It must be protected well enough against viruses that infect the system it is running on.<\/p>\n<p>A good practice might be to limit by default the maximal sum depositable to it to the size usually needed to maintain daily correspondence. This will make the wallets less attractive target for siphoning by malware.<\/p>\n<p><strong>Weaknesses<\/strong><\/p>\n<p>The method will require significant upgrades of the existing MUAs, and in some variants by MDAs and MTAs.<\/p>\n<p>The scheme provides plausible denial of responsibility for the payments to the e-mail receiver. This can be used to launder money by sending them as e-mail payments.<\/p>\n<p><strong>Other<\/strong><\/p>\n<p>Currently the ideas is bare-bones only. Should it be considered valuable, it can be developed further.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Many methods to fight spam and e-mail viruses decrease them, but nowhere close to zero. This is an attempt to describe a method that will practically stop them. Attaching payments to e-mail The essence is to attach to every e-mail a payment to the receiver. E-mail that does not carry a payment should be discarded [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"hide_page_title":""},"categories":[],"tags":[],"_links":{"self":[{"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2002"}],"collection":[{"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2002"}],"version-history":[{"count":0,"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2002\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2002"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.gatchev.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}