Enforcing hashcash means rejecting all mails that have less than a certain bits on the hashcash stamp. (or no hashcash stamp)
So basically, its the chicken-and-egg problem. Senders wont start using it before receivers do enforce it. Receivers cant start enforcing it before senders start using it.(same can be seen with chip'n'pin, you can't simply start enforcing chip cards because theres lots of issuers who use magstripe cards, thus all card readers today still have magstripe reader - and same with pin, theres lots of card readers who dont have a pinpad, thus you cannot enforce pin on the "issuer side", you have to accept signature transactions too - and theres lots of readers without chip slot, thus issuers have to issue chip+magstripe cards, not chip-only cards)
So this is a problem that exist everywhere, once a system is widely adopted, its hard to change the system without either adding backwards compatibility or breaking the system.
Even if you implement hashcash on the SMTP protocol level, you cannot simply "upgrade" your system because then you will start rejecting all mail from old systems. This still means that regardless on how you implement it, senders must start using the system at own initiative before receivers can start requiring it. Just look at STARTTLS. Even if most mailservers do support it, theres still mailservers out there that wont support STARTTLS, thus you cannot require encryption. Another thing to watch out for, is that lists, like this (postfix list) would have to generate *LOTS* of proof-of-work to be able to send mail to its users. If lists would get whitelisted in a "hashcash-mandatory" system, and the list itself would require "hashcash", then spammers would simply use the list as a "spam amplification" system. Nowadays, lists like "postfix users" are free of spam, just because its easier for spammers to send out spam themselves.
But a thing mail server owners with greylist can do, is to express-lane all hashcash-stamped mails with a sufficent bit amount through, eg they dont have to negotiate greylist and queue mail for the specified waiting period.
Same can be done for spam filters.The good thing with hashcash is that it does not require any previous negotiation. You just generate a hashcash that is "sufficently strong" for your taste, and then you see if the receiver likes it or not. This means you can also configure your greylist system to enforce different delay periods for different hashcash bit levels, so even "weak" hashcashes are accepted partially.
-----Ursprungligt meddelande----- From: Gergely Debreczeni
Sent: Thursday, May 07, 2015 12:31 AM To: Sebastian Nielsen ; postfix-users@postfix.orgSubject: RE: proof-of-work principle applied to mail sending protocol(s) - spams
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.orgSubject: 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
smime.p7s
Description: S/MIME Cryptographic Signature
