Subject: [ietf-smtp] Anti-spam - paid network

From: Jacob Palme <[email-masked]>
Date: Thu, 3 Dec 2015 14:44:50 +0100

The main reason for the proliferation of spam is that the cost of sending a message is so small for the sender. The real cost - for delivery, anti-spam tools, personal reading and rejection of spam, is a cost for the recipient, not for the sender. I myself spend about 15 minutes a day on opening and rejecting spam messages, even though I use multiple spam filter. The total cost for all internet mail users is billions of dollars.

I think that the only workable method of getting rid of spam is to charge the sender of messages a price of perhaps 0.10 $/recipient for sending messages.

To implement this, we should set up a network of smtp stations (MTAs) which charge a price of perhaps 0.10 $ for receiving a message and transmitting it to its recipient. We might perhaps call such stations CMTA (for Charged Message Transfer Agents) This network should be separate from the existing network of mail transfer agent. a CMTA should not charge for messages coming from other CMTAs) A secure method must be defined so that a recipient can distinguish between messages from the CMTA from messages from other non-charged MTAs. Probably some kind of cryptographic method has to be defined. A way of reducing the right to act as a CMTA must be found for CMTAs who represent spammers.

I believe that people will be willing to accept the complication of receiving messages from two SMTP networks, the conventional network and the new CMTA network. Mailing lists must be handled within the CMTA network, so that the sender of a message to a mailing list need only pay 0.10 $ for sending the message to all members of the mailing lists. I am not yet sure how to avoid spammers from misusing large mailing lists, but probably a human has to approve every message before it is distributed to members of mailing lists.

The income, 0.10 dollars per recipient, can be used to set up and manage the network of CMTAs, paying for the human monitors of messages to mailing lists. Any surplus might go to IETF. We should avoid systems run by private companies for their own profit.

Invoices sent by conventional e-mail should be invalid, and the recipient need not pay such invoices.

My proposal will not stop such spam where the sender is willing to pay 0.10 $/recipient to submit the message. But propably this will be a very small percentage, perhaps 1 % och 0.1 %, of the present amount of spam.

Recipients should set up their mailers so that messages coming from CMTAs get higher priority and messages coming from the old mail network will get lower priority, or perhaps dismissed without being read. Possibly put charged messages into a different mailbox than no-charged messages.

There are several technical details to be resolved to realize the network of CMTAs, but IETF should be able to resolve these details and define a variant of SMTP for transmissions to and between CMTAs. And I do not think any other anti-spam method will work. Details to resolve:

- How to handle the payments for sending mail to CMTAs and distributing the income.
- How to block malicious fake CMTAs.
- How to send and receive charged messages.
- How much to charge for sending a message, price per recipient.
- How to set up the network of CMTAs.
- How to handle mailing lists, where the price for the sender cannot be 0.10 $ per member of the mailing list.
--
Professor emeritus Jacob Palme <[email-masked]> (Stockholm University)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Dec 2015 06:53:12 -0800

> I think that the only workable method of getting rid of spam is to charge the sender of messages a price of perhaps 0.10 $/recipient for sending messages.

There are many approaches to solving spam that will work quite
effectively, if only they were able to work at all.

Your view is one of many that is oft-repeated, very appealing, and
entirely unworkable in the current real-world.

As such proposals always warrant, please carefully review Cory
Doctorow's famous checklist:

     http://craphound.com/spamsolutions.txt

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2015 19:12:59 -0000

>     http://craphound.com/spamsolutions.txt

For more details, see this white paper I wrote.

It's ten years old but nothing of importance has changed other than
that you might add the occasional extra zero to orders of magnitude.

http://www.taugh.com/epostage.pdf

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Dec 2015 15:24:29 -0500

--On Thursday, December 03, 2015 06:53 -0800 Dave Crocker
<[email-masked]> wrote:

>> I think that the only workable method of getting rid of spam
>> is to charge the sender of messages a price of perhaps 0.10
>> $/recipient for sending messages.
> 
> 
> Your view is one of many that is oft-repeated, very appealing,
> and entirely unworkable in the current real-world.

Dave,

While I agree with you (and John Levine) that there is almost no
chance of this working, I think Jacob's very considerable
contributions in areas of messaging and online discussions
justify, perhaps even require, being somewhat less dismissive.

In particular, the stereotypical and quite telling categories of
the Cory Doctorow and Vern Schryer
(http://www.rhyolite.com/anti-spam/you-might-be.html) lists,
Jacob's proposal is, IMO, a member of a family of things that
have been getting a lot of traction in the IETF of late.  

Models of that sort are also ancient in network time.  When the
Internet was young, the number of hosts was small and the
user:host ratio large, the assumption (never completely correct)
was that each host (and institution) was responsible for its
users and their behavior.   If someone behaved badly, the
assumption was that the institution could, and would, identify
the offending parties and apply appropriate remedial measures.  

Now we are dealing with huge numbers of users and machines.
When large-scale email services are involved, the typical
provider has very little idea who even the legitimate users of a
mailbox are, resulting in a situation in which there is too
little user identification and authentication for tracing bad
behavior and, as we've seen in a recent and continuing thread,
for too much of it from the standpoint of privacy concerns.

With each of the current proposals in that family, the notion is
that, if only a recipient can depend on the message originator
having been validated by the relevant submission server and that
submission server somehow validated, then the odds of the
message being spam are drastically reduced.  Jacob's current
ideas, as I understand them, tie that validation to the transfer
of small amounts of money.  Most of the others involve more or
less complex rituals (e.g., special DNS entries and special
header fields linked to them).  He hopes that the fees can be
set at a level that will stop spammers but not deter legitimate
users.  The DNS-and-header based methods assume (or hope) that,
despite many of us having observed that we know ways to game or
work around the methods, the spammers will be sufficiently
discouraged by the amount of effort involved in those
workarounds that they will stop spamming.

I see a lot less difference between Jacob's "pay per message"
approach and the DNS-and-header-field ones than one might like
to believe, if only because both ultimately depend on the
assumption that we can find (or have found) a sweet spot in
which the use of email is too costly (along some dimension(s))
for the spammers but inexpensive enough to not deter appropriate
uses.

The one big difference I see is that, the debacle with the
initial deployment of DMARC and mailing lists notwithstanding,
the DNS-and-header-field approaches seem fairly easy to deploy
(and confer benefits) incrementally.  The "pay" approach, at
least as I understand it at this point, requires deployment and
acceptance of a new trust structure to be at all useful.  You
have argued the difficulties of such plans far more powerfully
than I have, but we agree that such a requirement would provide
a very high barrier to success even if the ideas were otherwise
sound.

best,
       john

---

From: Brandon Long <[email-masked]>
Date: Thu, 3 Dec 2015 13:20:26 -0800

/me looks at the number of messages we send a day, multiples by 10 cents,
laughs
/me looks at the amount of money an ad supported service earns per user,
looks at per message costs of 10 cents, laughs

Regardless of any other complication, charging enough to matter to bad
senders but not enough to deter real senders... this whole thing is a
non-starter.

As for equating DMARC (which is an anti-spoofing / anti-phishing proposal,
not an anti-spam proposal) with this, I don't even...

Brandon

On Thu, Dec 3, 2015 at 12:24 PM, John C Klensin <[email-masked]> wrote:

> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Dec 2015 16:38:23 -0500

--On Thursday, December 03, 2015 13:20 -0800 Brandon Long
<[email-masked]> wrote:

> /me looks at the number of messages we send a day, multiples
> by 10 cents, laughs
> /me looks at the amount of money an ad supported service earns
> per user, looks at per message costs of 10 cents, laughs

Right.   I agree that the economics are unlikely to work in
practice, even if one titrated the amounts.  I tried to say that
in a more general way.

> Regardless of any other complication, charging enough to
> matter to bad senders but not enough to deter real senders...
> this whole thing is a non-starter.

See above.

> As for equating DMARC (which is an anti-spoofing /
> anti-phishing proposal, not an anti-spam proposal) with this,
> I don't even...

I didn't intend to "equate"  them and certainly understand the
distinction.  DMARC was mentioned only because it provides a
fairly recent example of a method based on assumptions of proof
of authorization to send mail from a particular address or
domain whose deployment caused disruptions.

Personally, I don't believe this is worth pursuing even to the
extent of more traffic to explain why it is a bad idea.  There
are a lot of reasons why a general fee-for-mail (especially a
fee that, as you point out, is small enough to not provide any
deterrent) is not going to work and a lot of independent reasons
(a few of them actually hinted at in Jacob's note) why it would
be likely to be impossible to deploy in practice.  

I was objecting almost exclusively to the style in which the
proposal was dismissed, independent of whether it is a good idea
or even one that should be taken seriously.

     john

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2015 21:44:59 -0000

>acceptance of a new trust structure to be at all useful.

It's not just a trust structure, it's a payment system.  There seems
to be a tendency to assume that problems in areas that we're not
familiar with are easier to solve than ones in areas that we
understand.  In this case, we all know about the misery of spam
filtering, but most of us haven't spent a lot of time looking at
payment systems.

To pick a few straightforward problems: the number of email messages
sent every day is at least in the billions.  The largest online
payment system is Visa's, which has a burst capacity of 47K
transactions/sec, which would be about 4 billion per day.  That's not
a real number since they can't run flat out all day at the peak rate,
but it tells us that to handle mail payments we'd need to create a new
system as large as Visa's, but for an average transaction of 10c,
while Visa's is about $100.  Visa's per transaction fee is at least
25c, so even if all the money went to pay for the network it's not
close to being enough.  The situation is actually much worse since
most mail is spam. most spam won't have a valid payment, so unlike
Visa we'll have vast numbers of failed transactions with no revenue to
cover the costs.

The usual next suggestion is Bitcoin!, but anyone who has looked at
bitcoin knows that the current system tops out at about 10 tps due to
block size limits, and it takes 10 minutes or more to clear a transaction
which will not make mail users happy.

Even if we assume we can wave our hands and somehow invent a
transaction system, the next problem is who pays for bogus
transactions because this is real money.  For example, if a bad guy
plants malware on your PC and sends 1,000 messages, who pays for them?
If the answer is not "you do", who decides, and how do you tell the
difference between a real victim and a spammer who plants malware on
his own computer?  If it is "you do", how do you explain to Grandma
that if she uses e-mail, random crooks are likely to steal money from
her mail account every time she clicks on an unfamiliar link?

Then there's the mailing list problem -- who's going to pay the $10
per message for the 100 people on the list?  If we assume that the
postage is somehow waived, how's that going to work, and how will we
deal with all of the scams it enables?

There's more, see http://www.taugh.com/epostage.pdf

My point here is that if we want to make progress, we need to stand on
(to borrow a phrase) the shoulders of our predecessors, not on their
toes.  Everything I've said in this message has been well known for a
decade, so I'm somewhat in despair that we keep recycling the same
bad ideas because people don't do their homework.

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 3 Dec 2015 18:03:40 -0500

On Thu, Dec 03, 2015 at 09:44:59PM -0000, John Levine wrote:
> Everything I've said in this message has been well known for a

+1.  All "e-postage" schemes may be dismissed on inspection.
There is absolutely zero need to give them any further attention.

---rsk

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Dec 2015 15:11:39 -0800

> justify, perhaps even require, being somewhat less dismissive.

It has /no/ chance of working.

It is a very old, very tired, very failed, and long-dismissed approach.

The proposal reflected no sense of the topic's history and demonstrated
no sense of the challenges.

Yet the proposal asserted simplistic 'certitude' not curiosity-driven
'exploration'.

Given how wasteful posting such a proposal is, my response was arguably
more polite than warranted, not less.  And while the poster's background
shouldn't matter, in this case it would have justified even less
politeness...

d/

---

From: Al Iverson <[email-masked]>
Date: Thu, 3 Dec 2015 17:25:40 -0600

>> justify, perhaps even require, being somewhat less dismissive.

Nobody's stopping him from building this and trying to make money off
of it. He's free to try to convince others to do it. But, stopping
this from getting a hearing here, is, IMHO, the correct thing to do.

It describes a scheme flawed to the point of being a non-starter, nor
is it even clear why this (IETF) would be the mechanism to define and
recruit support for such a thing. In 2015, design of anything used to
transmit money or payments or consideration would likely need
involvement from key financial sector stakeholders looking to define
that specification. Anything less than that is just some random,
uninvolved person wondering "What if?" Perhaps a neat idea for a
research paper, but not very useful for this forum.

Regards,
Al Iverson

--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com