ietf
[Top] [All Lists]

Re: Engineering to deal with the social problem of spam

2003-06-03 02:36:15
On dinsdag, jun 3, 2003, at 03:14 Europe/Amsterdam, Dave Crocker wrote:

TH> I agree with the idea of a BOF, but 'anti-spam' is the wrong focus. Spam
TH> is a social problem, not an engineering one.

Ok, maybe the word "spam" is too overloaded to be useful in a technical discussion. However, it's always good to keep the customer experience in mind, and the customer experience is "I don't want all this spam".

TH> Focus the group on a tangible engineering problem, deployable
TH> authenticated email. Or as Vixie labeled the more generic, interpersonal
TH> batch communication system.

Just adding authentication only solves a very small part of the problem: we can then accurately whitelist known senders.

A new interpersonal batch communication system certainly sounds like a good idea. The problem with email is that it is incredibly ill-suited for transferring larger files. A new protocol should be able to do much better in this area. However, this doesn't have much to do with spam issues and might make the whole thing much more complex.

No one believes that a house lock keeps out all intruders, and indeed
some do get in. But we *do* believe that house locks reduce the threat
to a socially acceptable level.

The trouble is that on the internet, you can go from house to house and try to break locks and nobody will stop you. In the real world, you wouldn't be able to do that for very long.

First of all, there is not yet any existence proof for the reduction of
spam. Some interventions have reduced some aspects of spam, but the
total size of the beast has only been growing, and rapidly.

Which is kind of ironic because spammers are thereby creating their own tragedy of the commons. Spam is so much out of control that any individual spam isn't going to have much of a return, so they need to send out even more of it. And the volume of spam is becoming so painful that people are now seriously working at getting rid of spam. So far with limited success, but that will change one way or the other.

There is a
key lesson here and it is mostly missed. The lesson is that spammers are
adaptable

So let's show some adaptability of our own and plug those SMTP holes.

So, let's not worry about the all-encompassing definition of spam. Let's
just -- hah! "just" he said -- target a single type of spam that is
massive and is massively offensive.

My personal favorite definition, these days, is

   Unsolicited Bulk Mail (UBE)

Not all unsolicited mail is bad.  Not all bulk mail is bad.  But the
combination is universally reviled.

Completely agree.

So we then need to define unsolicited properly. We must make sure to
permit me to make contact with someone for the first time.

One way would be solicited == whitelisted. Remember that this is only necessary for bulk mail. So everyone would need to create a whitelist of all the mailinglists and newsletters they're subscribed to.

And we need to define bulk properly. This will be difficult. If I send
an unsolicited message to 2 people, does it qualify? What about 10
people, 100, 1000? Why? Why not?

Why look at individual messages? How much non-bulk mail can someone possibly need to send? 10 messages per hour? 100? 1000?

The problem, here, is that I believe the qualifier "bulk" captures an
essential aspect of the problematic mail, so we can't simply drop the
term or say "anything greater than one". Worse, the instant we choose a
number, the spammers will simply send batches that are one addressee
fewer than that maximum.

That's why it's important to look at ALL mail rather than just copies of one message. Spammers by now know how to make messages look different even though they're essentially identical.

Someone's "home MTA" sould be able to simply rate limit the number of messages an individual user gets to inject into the global email distribution system. Then all we need is a system to differentiate between trusted MTAs and rogue ones run by spammers.

And that's why this is a research topic, no matter how essential it is
to to engineer some mechanisms sooner rather than latter. Let's do the
engineering and deployment, and let's do it quickly, but let's
appreciate that it is really research.

I'm not convinced.