Thank you Sebastion ! i'll check on that better ! Though, it does not solve the part of spam generation. Spams are still generated but killed on the Receiver side. If all this could be implemented on the protocol level and 'on demand' than it would work much better.
Cheers, Gergely ________________________________________ From: Sebastian Nielsen [sebast...@sebbe.eu] Sent: 07 May 2015 00:20 To: Gergely Debreczeni; postfix-users@postfix.org Subject: Re: proof-of-work principle applied to mail sending protocol(s) - spams IT do already exist: http://www.hashcash.org/ Im already using it. See this mail, you find this header: X-Hashcash: 1:26:150428:nielsen.sebast...@gmail.com::8G9E5dBe8isoyoyL:0000000000000000000000000000000007iLtb Thats a proof-of-work system with hashcash. Im currently have a module in my outgoing mail server that generates such "hashcash" stamps with the help of a milter. Spamassassin in default config should reward such headers with a negative spam score. -----Ursprungligt meddelande----- From: Gergely Debreczeni Sent: Thursday, May 07, 2015 12:11 AM To: postfix-users@postfix.org Subject: proof-of-work principle applied to mail sending protocol(s) - spams Dear List, I was advised to come to this list with the idea below. I apologize if this is not the right forum, in that case please point be to more appropriate list. In any case i would appreciate any feedback on the thoughts below, which I try to explain very densly and can of course eloborate in detail later in case of interest. A one liner: An idea based on the proof-of-work principle to tremendously decrease mail spam traffic. A short extract: The problem: The problem of spam mails is still existing and current solutions are trying to cure the issue on the wrong side of the problem. Despite the fact, that due to state-of-art spam filters spams are not really problems for the end user, spam mails are still generated, sent and generating malicious internet traffic. This is because a.) it is virtually free for spammers to send the mails and b.) spams are treated only after they arrived into their destination. The solution: While keeping all the good properties of open message/mail sending protocols, we need to change a.) and b.) and there is a way to do this in one step, which is the following: Let's imagine the following imaginary mail sending protocol. 1.) Sender contacts the Receiver 2.) Receiver verifies Sender's identity 3a.) If Sender identity is known to Receiver, then Receiver accepts Sender's message. 3b.) If Sender's identity not know for the Receiver then Receiver says to Sender: "I do not know You, but you can still send me a message if you solve this problem!" 4.) The Receiver gives a computational problem to the Sender which a.) can be infinitely, trivially (or parallely) generated b.) can easily be verified c.) and can be solved only serially, i.e. unparalellizable (so as to ensure that it takes more-or less the same time for everybody) d.) has a well estimable and tunable computational complexity e.) generated on the spot, has limited lifetime and used only once so as to exclude any second or aftermarket of problem solvers and mail senders 5.) If the Sender is really serious about to send the message it solves the problem, i.e. it dedicates N seconds/minutes of computational time to solve the problem and connects back the Receiver with the solution 6.) Having the solution presented to the Receiver the Receiver accepts the message, since a proof-of-work was presented. 7.) The user who reads the mail can mark Sender as 'known' so next time Sender does not have to perform calculation What follows: a.) This way anybody can contact anybody (no whitelist/blacklist) and it it only the first contact which is "painful". b.) No human labor intensive captcha solving is involved c.) No money, 3rd party, administration or any legal regularisation involved still working. d.) Since this way it becomes several order of magnitudes more expensive to spammers to contact unknown email adresses for the first time, it becomes economically unfeasible to operate and manage spamming botnets or other spamming machinery. e.) Problem requiring can be optional and problem complexity can vary from address to address. f.) Problem can be sent as a 1 liner error message inside SMTP communication g.) The idea can be implemented organically inside the SMPT protocol. h.) In this way spams are not even generated and does not generate internet traffic so spam issue is treated at the right side of the problem. There is of course many more little but important details to discuss about, this is just the brief overview of the idea. Would appreciate any feedback and/or volunteer prototype implementation in case of interest Sincerely, Gergely Debreczeni
