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 by the receiver’s software. If an e-mail carries a valid payment, that is automatically extracted into a receiver’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.
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.
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.
The scheme is self-imposing: after a significant amount of e-mail addresses start refusing e-mails that don’t contain payments, the others will be forced to adopt it, too.
Methods of attaching a payment
There are many possible. An incomplete list of suggestions follows:
- Adding in an e-mail a header field that contains a (confirmation of a) transaction to the receiver.
- Using specially developed e-mail exchange protocol(s) that allow for requesting a payment during the exchange.
One or more might be defined as standard by an Internet authority.
Balancing payments
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.
Conversations might be marked / unmarked as real following a set of criteria. An incomplete list of suggestions follows:
- Manually by the reader.
- Whether the conversation contains replies (esp. if more than one; unsubscription requests might be omitted from consideration).
- Whether previous conversations with this correspondent have been marked as real.
- Validating the correspondent e-mail address / domain against public databases / lists with “non-spammers”.
- Checking the sender IP address against public blacklists and/or whitelists during e-mail transfer
- Analyzing the message contents
Correspondence balance is most easily zeroed by the net gainer sending a “machine-only” 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.
Whitelisting
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:
- Manually listing / delisting e-mail addresses and domains by the recipient.
- Already having conversations with this correspondent.
- Validating the correspondent e-mail address / domain against public databases / lists with “non-spammers”. (In practice will require also the message to be e-signed with a trusted PKI.)
- Checking the sender IP address against public blacklists and/or whitelists
- Analyzing the message contents
When sending an e-mail to a whitelisted correspondent, the e-mail software might add a specific mail header that tells the correspondent’s software to not add payments when mailing back (or lack a header that gives the size of the demanded payment when writing to).
Correspondents can be notified of being added to or removed from the whitelist by a “machine-only” e-mail (eg. containing a specific mail header). Such an e-mail will be read by the correspondent’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, “machine-only” e-mails will be exempted from the payment requirement.
Obtaining correspondent payment details
To make a payment transaction to an e-mail recipient, the sender’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:
- Sending a “machine-only” e-mail to the recipient that contains a request for payment details, eg. as a specific header. The recipient’s software should automatically reply with a “machine-only” e-mail containing the details, eg. in a specific header. After that, the real e-mail is sent together with the required payment.
- Obtaining the payment details from a public database / list.
- Using a specially designed MTA protocol that allows the MTAs to negotiate e-mail payment details.
- Replying to e-mails without payments with a “machine-only” e-mail that contains payment details, eg. in a specific header, and waiting a “machine-only” response with the payment. (Should be well-secured to prevent backscatter abuse.)
One or more might be defined as standard by an Internet authority.
Wallet-related
It must be protected well enough against viruses that infect the system it is running on.
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.
Weaknesses
The method will require significant upgrades of the existing MUAs, and in some variants by MDAs and MTAs.
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.
Other
Currently the ideas is bare-bones only. Should it be considered valuable, it can be developed further.
That is moronic- lets make internet paid.
@Anonymous: I prefer a different definition of moronic – “criticizing a proposal without reading it”. The one above clearly intends to keep Internet free for the non-spammers, but paid for the spammers. I consider this one of its strengths.
I still think malware will target system like that. By draining enough credits they will have a way to continue spamming…
Emails can be sent on behalf of computers and for computer recipients. Payments are made only between legal entities, e.g. people or organsizations, and are subject to taxes and regulations. You need to invent a new term for “an electronic message between legal entities”, email is not that.
P.S. An escrow is effective for any risky service, not only mail (electronic or not). For example an applicant who doesn’t match the written criteria for a job but still goes to the interview.
Notes:
– Involving real money in the process means a new ways to steal them, exploiting that process.
– “the internet governance” having control of all emails. What could go wrong.
– Spammers rarely use their own machines and servers to spread mails, they use infected bot nets.
– Whitelisting by automated email. Yeh, what could go wrong.
– Securing wallets. That’s harder than securing emails.
The main idea is to make sending spam cost something to the spammers. I should note that in USA the paper mail spam is a thing and it does cost something. So it won’t stop spam, at best it would limit it.
Also, it definitely will not stop viruses, because viruses are spread from person to person, using victim’s address book, where all channels are already whitelisted.
Sorry, but the whole scheme is extremely complicated and this is in its sketchy description. It would just open a new can of worms, without guaranteeing any real benefit, even if universally accepted.
The SPF adoption shows how painful and slow process is making even the smallest changes in the email system.
You should understand something, email is thing from the past. It’s used mostly as business communication tool, because businesses don’t like to change. For the casual people Social Networks provide communication channels and these are centralized.
@Dr.Serbezov: A wallet written with security in mind must be able to block the access of almost any malware to it.
Also, keeping wallets maximal sum limited by default will severely limit the amounts of mail a malware that accesses the wallet can send – far below the amount it needs to propagate. Currently, less than 1 out of 1000 sent malware-attached e-mails succeeds to infect the target. If the wallet is limited by default to maximal sum needed to pay for 100 e-mails, each new wave will infect 10 (or more) times less targets than the wave that sent it. In just a few months all botnets that rely on e-mail propagation will die.
Finally, if a malware succeeds at gaining access to a wallet, it will be drained and its owner will be unable to send e-mail. This will prompt the owner to take measures and clean the malware. This is a very good development, compared to the current situation, when people unknowingly host malware on their systems for years, and sometimes don’t care to clean it even if they know about it.
So, the scheme naturally provides for defense in depth, and that is always a good thing. 🙂
@Петър Петров: Cryptocurrencies so far aren’t covered by most financial legislation. Also, no financial legislation forbids exchanging small sums of money between non-commercial entities.
In addition, the system is hardwired to balance the payments to a zero final sum. So, it can safely be omitted from the scope of the financial legislation.
@Иван: I don’t agree with some of the notes.
– Doing anything has risks. Unless shown that risks outweigh the benefits, they cannot be an argument against the new thing.
– The internet governance will only define the standards of payment attached to them. That does not give to it any degree of control over the e-mails. So I don’t think this argument is valid, either.
– The scheme is created exactly to beat the fact that spammers use botnets. See above in this comment.
– Whitelisting by automated e-mail can go wrong, but is not a mandatory part of the scheme – as the whitelisting at all.
– Securing wallets is MUCH easier than securing e-mails – much enough to make the difference between “hard” and “practically impossible”. It just takes some care to write one decently. And the fact that money are involved will raise the stakes to a degree where the writers of wallet programs will have to take that care.
In USA paper spam is a problem precisely because the cost of sending it is negligible. A similar system will help with that problem, too.
As noted above in the comment, viruses need to send a lot of e-mails to have positive network quantity gain. The addressbooks of the users are usually too small to provide that many targets. That is why spammers buy e-mail lists, and these lists are the scourge of Internet.
I do not agree with the evaluation of the whole. Yes, it will have problems, but the benefits will outweigh the negatives by a lot.
The SPF adoption was delayed because the process is not self-imposing: the fact that someone has introduced it does not push the others to do it too. This scheme has a self-imposing tendency, so its adoption would be much faster.
I most categorically refuse to “understand” that the e-mail is a thing from the past. It will be a valid, useful and widely used tool for at least the next few decades, I believe.
the solution is ultra -complicated. Because of that, it could probably be misused in various ways, both from criminals and governments.
The implementation and maintenance expenses will be higher than the losses caused by spam.
Payments can be traced. Bye bye privacy.
Spam is not that much of a problem these days. I receive one spam email per week, max. two. Plus a daily list with all the crap sent to me, so if needed I can retrieve a wrongly sorted email. I waste about 2 minutes every week to deal with spam, not more.
So for all practical purposes, spam doesn’t exist for me. This situation does not need improvements, especially complicated ones.
@Пешо: Actually, one of the greatest advantages of the scheme is that it is between four and six magnitudes simpler than most existing anti-spam solutions. (That is one of the reasons it probably will be far more effective than them.)
The misuse by criminals is possible, but again harder than that of the existing anti-spam solutions. Same for the governments.
There will be implementation expenses, but those will be offset by the time economy within less than an year. Maintenance expenses are practically non-existent.
Cryptocurrency payments are very hard to trace. That is one of the reasons their “killer app” is the criminal deals. Actually, the impossibility to trace is a slight disadvantage, for this reason.
For people that use e-mail, spam is a scourge and the situation desperately needs improvement. The yearly losses of the world due to spam – spam-sent viruses harm, con successes, expenses on salaries and equipment for anti-spam proposes – are considered to be between 4 and 10 billions. Due to its simplicity, this solution can successfully be implemented worldwide for 1/10 of these yearly losses.
… God I wish a comment from someone who has read the proposal!
That’s an interesting idea (quite similar to postage stamps, right?) that has been discussed and implemented multiple times in the past 15 years:
http://www.geek.com/news/charging-for-e-mail-will-stop-spam-551697/
https://www.newscientist.com/article/dn17577-pay-per-email-plan-to-beat-spam-and-help-charity/
http://www.heinz.cmu.edu/~rtelang/Kraut05-PricingEmail.pdf
I assume the goal is to force the cost for sending spam to be on par with that of filtering spam. If that’s the case, I think there’s a much better alternative proposed by the prominent cryptographer Adam Back (http://www.cypherspace.org/adam/) and it’s called Hashcash: http://hashcash.org/
However, it should be noted that both methods (pay-per-email and Hashcash) have some shortcomings and one of them is how to deal with legitimate mailing list traffic. This can be sorted out with whitelists, but puts the decision in the hands of the end users, and mailing list operators can’t do much about it.
Most of the proposed methods to deal with spam suffer from the same inherent issue – wide adoption is required in order to become effective. SPF, DKIM, and DMARC have a head start in this regard – they’re backed by most of the major mail operators.
I don’t think that spam is a solved problem yet, despite what Пешо claims above, and personally I’d love to see something like Hashcash to gain traction.
@Vladimir Blaskov: The goal is to force the cost for sending spam to be prohibitive, while that of sending legit mail to be negligible (due to the volume difference).
Putting the decision on the whitelisting in the hands of the end users is great idea. It has some shortcomings, but there is no technical difference between a legit list mailing and spam, so any method that takes the whitelisting decision away from the end users creates an unclosable opportunity for the spammers. So, leaving the decision to the end users is the better choice.
Hashcash is an excellent idea for the pre-blockchain times. Paying for the e-mail is the better approach, but until the rise of the blockchain-based e-currencies it was impractical. So, I believe that in practice the proposal above will be superior in practice. (The detailed discussion on this is very interesting, but also very long.)
A key difference from most of the previous proposals (including Hashcash) is that this one proposes a financial payment to the mail recipients. I believe that this makes it far superior to the other proposals. (The detailed discussion on this is also very interesting, but rather long.)
I believe that this proposals will be easier to adopt in practice, despite requiring some new software, for several reasons:
– It is fully backward compatible, but not forward compatible to the current e-mail: people who apply it will be able to keep their connectivity, while those who don’t will start losing theirs, and thus will have the incentive to also apply it.
– It puts the initiative for the move in the hands of the interested party – the mail recipients. (And also creates an additional financial interest for them.) This works to overwhelm the spammers on several lines at once, this achieving high efficiency against the spam.
– It creates a financial interest for the end users to battle the malware in their systems, thus limiting the technical opportunities to distribute spam (and the benefits only start here).
– It creates a legal / financial interest to the anti-malware solutions providers to not accept payments by malware providers to not detect a malware. (Currently this occurs rarely, but in the future may become widespread.)
Many other reasons exist; this also is an interesting and fruitful, but long decision.
@Григор
Не виждам особен смисъл да си приказваме на английски и ще продължа на български .. сега по темата.
Решението наистина е изключително сложно, не виждам как успява да ти се струва по-просто от съществуващите решения.
Какви са съществуващите решения? – най-просто казано, претърсване на текста на съобщенията, плюс проверка на определена информация за подателя в уайт/блек листи. Евентуално плюс сканиране на прикачени файлове за вредители. Това са лесни за използване, разработени технологии, с много безплатни разновидности.
Преди време успях да сведа спама почти до нула просто чрез конфигуриране на филтри за входящата поща (използвам theBat, където тия неща са много добре направени). Сега ме мързи да се занимавам, не че е кой-знае какво занимание, но не виждам смисъл. При платените хостинги които използвам, мейла се чисти от спам и вируси на ниво сървър. Същото от доста време го правят и много от доставчиците на безплатни услуги. Не помня от кога в Yahoo не съм получавал предложения да си уголемя части от анатомията или да помогна на изпаднал в беда нигериец. С други думи спама вече не е проблем.
Дори спама да беше реален проблем, пред схемата с плащанията има доста пречки. За да е ефективно, такова решение трябва да се приеме повсеместно в развитите страни – и от потребителите, и от бизнеса, и на държавно ниво. Схемата не може да се наложи, ако всички те не я приемат. Няма да проработи, ако я харесат само в Естония и Канада, примерно. Това значи, че трябва да има споразумение между всички каква валута да се използва. След като в момента, поне доколкото знам, няма държава в която криптовалута да е официално платежно средство, не виждам как това ще стане във всички развити страни. Причините да не стане са много, и всичките са много по-съществени от съществуването на спам и борбата с него.
Плащанията по правило са обект на облагане и камара от правила и регулации. Дори само за изключване на мейл плащанията от облагане и регулации, ще са необходими законови промени и какво ли още не. Спамът не е проблем, заради който си струва някой да се занимава с всичко това.
@Григор,
The big businesses are the reason why your scheme would never be adopted.
1. They send a lot of emails. It means that they would have to pay a lot of money upfront, just to use something that used to be free.
2. They might have to pay a lot of money on regular basis, as they might send more emails than they are getting back. All legitimately.
3. They need to receive emails from all kind of idiots that cannot be bothered to implement something new. Usually small businesses.
Because of #3 they would have to pay both money for your new scheme and anti spam filtering.
As you can see, your scheme is not self imposed, quite the opposite. It’s impossible to be imposed.
—
Also:
– About e-currency. I do not think that you have good idea how it works in real life. But lets keep that can of worms closed.
The biggest problem with e-currency is fundamental economics of fixed supply money schemes.
To be viable e-currency must be fixed supply, meaning that “minting” should be limited, so that the money supply cannot be inflated indefinitely. e.g. most of the possible bitcoin hash-sums have already been discovered. Discovering of new coins is still possible, but it is getting exponentially harder. Still it is known that their number is finite.
Imagine entities who get emails and never reply. With time, they can accumulate a great number of e-currency, big enough to hinder normal transactions.
The second problem with e-currency is that its real money value might be fluctuating. Imagine that you used 1 bitcoin per email. A few years ago, you could bye dozens per dollar. Now, a single one cost thousands of dollars.
You are going to need a central authority and special virtual money that are used only for emails. It would ensure that email-currency have fixed price and there will always be enough of them.
– The central authority do have the ability to block all email from a given source by not validating the payment for it.
Even now, some spam blocking lists are in the business of extorting money from innocent entities. E.g. open source maillists.
– Securing wallets is extremely hard. It is something that banks still haven’t got hand of. If your computer is compromised, everything you do on it is compromised, including your electronic banking. You are at their mercy.
The only way to be secure is to use separate devices that generates one-time-use codes that are manually entered by the human. That’s just too much work for email.
– Since most people send few emails, the malware may not use up all their funds at once, thus avoid immediate detection.
Instead of 100 emails, people would be able to send 10 and if they run out of wallet money. In that case, because the sums are small, people might actually prefer to pay up another monthly fee, rather than pay for cleanup. (e.g. 1cent per email, $1 per wallet).
Even paying $10 a month might be cheaper than paying for antivirus.
– Address books might contain few addresses, but viruses could scan your inbox and send emails to all people who have ever contacted you. Or even better, everybody you have whitelisted.
– Whitelists are mandatory, if you want to keep maillists.
—
Do you want even better idea?
Since we are creating a central authority that manages all payments for email transactions, why not skip a step and simply put the email themselves on that authority servers.
The authority could monitor how many emails are sent and impose flexible quota schemes, it could run spam and virus checks on all emails. If the same email is sent to multiple people and some of them mark the email as spam, then all emails could be removed for everybody.
So, if everybody uses Gmail and block all external traffic, then the problem is solved.
All hail our Alphabet overlords. 😉
If your goal is to simply limit the number of outgoing unanswered emails to 100, it could be done now without involving third party and troubling with international money transactions.
It’s simple:
1. You must send emails from the server where you receive them. Clients could connect from anywhere, but they must be authenticated before connection. The fields “From” and “ReplyTo” must be the same, unless the mail is redirect from a maillist and have a field that identifies the list.
2. The server sends and receives emails only though the ISP mail relay. ISP rejects all emails that do not originate from its network or that are not recipients to its network. The sender ISP relay communicate only with the receiver ISP relay. The receiver relay might be queried from the DNS of the recipient, like SPF.
ISP relay is the one that enforces the quota.
3. Maillist emails are not counted toward the quota (in or out). Maillist operators must negotiate with their ISP before starting a list.
4. If user have reached a quota he phones to its ISP and they give him 100 more emails. If they want they could charge him $1 more for the month.
The problem with this scheme. Well all ISP in the world have to implement it. Currently, most of them simply block mail relay entirely. It’s also questionable if the quota should be counted toward the server or toward each user on it. I guess it is safe to assume that a single ISP client is the user of all email accounts on its own private server.
The good thing is that big ISP could impose the scheme on smaller ISPs and block ISPs that intentionally host spammers. There could also be a transition period where mails that are received directly are not rejected but considered suspicious. Like mails without SPF record.
The scheme even allows creating of dynamic reporting of spam. E.g. If you receive spam email, you mark it as spam and send it back to the sender ISP mail relay. If the relay gets 2 spam warnings for same client, the relay blocks all emails until human operator can inspect the complaints.
Also big email hosts (gmail, hotmail, etc) could have their own email relay. I guess there might be need for a central authority that registers all legitimate email relays. The authority could be all the ISP relay and host operators, that decide who should be included or excluded from the trust network.
@Иван: I disagree with most of these points too.
The big businesses will love this scheme (except the very few who are into the spamming business). Their losses from getting spam are in the magnitude of hundreds of millions, maybe billions, per year. Most of them send more e-mail than they get, but the difference, if the e-mail cost is correctly chosen, will be in the range of millions or tens of millions. That is economy of two magnitudes. Also, they don’t really need to receive emails from everybody, except on a very small number of contact e-mails, so their expenses on anti-spam will decrease drastically. In total, the big businesses are one of the forces behind the fact that the scheme is self-imposing: they would love to adopt it, and thus will force everybody who wants to exchange e-mails with them to use it, too.
As for cryptocurrencies, I suggest to you this article as a start. Here will point only the most obvious mistakes in your idea about them:
– E-currency can have a supply and still be limited to a fixed sum – eg. there will never be more than 21 millions of bitcoins, regardless of how long they are mined.
– E-currency can have a supply that is not fixed and still be valuable – eg. if its supply is not substantially bigger than the loss.
– Entities that never reply will receive emails rather rarely – probably a couple of e-mails per week in the beginning. If the cost of an e-mail is $0.01, they will gain about $1 / year. And probably nobody will anymore write to them after an year of silence.
– If an e-currency is dedicated to e-mails payment, its value will not fluctuate by much: there is no reason to.
– Even if there is a central authority in issuing e-mail payment coins, this doesn’t mean that they will be able to validate the payments. (Hint: that is why not any e-currency is proposed, but a blockchain-based cryptocurrency.)
Other positions also appear wrong to me:
– Spam blocking lists that extort money usually bankrupt in just a few months, as they are unreliable as a spam source directory. Most e-mail admins, me included, immediately stop to use lists who appear to be in the extortion business.
– Security of wallets have by far not only a technical side. A moderately secure wallet that has no more than $1 on it is generally safe, as the size of the loot does not justify the effort on breaking it.
– The main inconvenience on having your e-mail wallet drained is not the expense on filling it again (the sum is small), but the effort spent on doing that. It is offensive to see yourself being robbed again and again in the same spot. This will raise the efforts on keeping the systems clean much more than the actual expense – much enough to break the chain infection propagated through e-mail. If you clean your system because of frequent inability to send e-mail, you will likely clear it also from the keyloggers that drain e-banking, and this will decrease the loot size further. This will decrease the incentive of the malware distributors, who are among the big distributors of spam. Etc.
– Encrypting on-disk data is a well-researched and established technology. Breaking this encryption is beyond the abilities of all or almost all malware creators. So, keeping the addressbooks and maillists properly encrypted can stop malware from using them. A software writer just has to have the incentive to use such an encryption. When the users become security conscious enough – and having to pay for e-mail sent by malware on your behalf will contribute to this – the software writers will find this incentive.
– Creating a central authority that processes all e-mails is a cheeky, but otherwise useless idea.
– The idea for using a mail relay for all outgoing mail was used for several years by some connectivity providers here, without much of success on stopping the spam.
https://en.wikipedia.org/wiki/Proof-of-work_system
Данъци и бюрокрация! Ето това е една от водещите причини тази идея да не проработи.
За всяко писмо ще се налага да се пише отделен ред в данъчната декларация. Освен това за да се спази закона може да се наложи да се събират личните данни на лицата, които изпращат писмата (заради законодателния спам, свързан с театъра на сигурността във връзка с прането на пари и финансирането на тероризма и данъчното законодателство, в частност ДДС).
Варианта с безполезно прахосване на компютърни ресурси (HashCash) е по-доброто решение, защото така няма плащане (и съответно няма правно-бюрократични проблеми).