ietf
[Top] [All Lists]

Re: Engineering to deal with the social problem of spam

2003-06-04 00:54:51
(I really wanted to stop this thread with my previous message, but...)

On woensdag, jun 4, 2003, at 02:54 Europe/Amsterdam, Tony Hain wrote:

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

Two points:
1) besides white listing, the approach also provides irrefutable
evidence to law enforcement about spam sources.

Ok, there's some value in that if we build a good key infrastructure. Wouldn't say "irrefutable" even then, though.

What I meant to say: we need more than authentication.

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.

We can always make it more complex than necessary, but it is pointless
to compare the complexity of a new system that does the job with a
system that is proven to be open to abuse.

SMTP shouldn't be used to transfer binary files. It leads to all kinds of problems: clogged mailboxes, wasted bandwidth (base64, aargghh!), you name it. A better batch interpersonal communication system would be able to send the message, but then negotiate what to do with the attachment. From some people you may want to always immediately receive the attachment, from others you may want to read the message first and then decide whether to inititate the transfer of the attachment.

This would be very cool except that it breaks current email systems at a fairly fundamental level. Adding authentication on the other hand, can be done in a way that may not be compatible with current ESTMP, but it does (or at least: could) fit into the current email architecture without too much trouble.

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.

Adopt draft-hain-ipv6-pi* as the standard addressing plan, provide
automated intrusion detection reporting, and Internet prowlers wouldn't
be able to attack for very long either.

Only if someone cares enough to go to the place where the prowler deploys his activities. There was a time when this was a reasonable assumption; but this time is now in the past.

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

Or simply leave SMTP to the spammers and move on.

Fine by me.

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

@ 5kB/message on a 10MB/sec link, 2k/sec.

And how exactly would those messages be "non-bulk"? I mean, I type fast, but even then it takes a second or so to even find the recipients for a message.

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.

Exactly how would you coorelate email across multiple accounts, on
multiple service providers?

We push this back to the source MTA. Then if the source MTA does a bad job, we revoke the MTA's "not-a-spammer" accreditation so only messages with whitelisted senders can get through.

Alternatively, we can build a serial number system. An MTA must then add a serial number that starts from 0 every day or every week to every message. This way everyone who receives a message from this MTA knows how many messages the MTA has already transmitted this period. Obviously spammers will fake the serial number so we also build a system that makes it possible to check if a serial number wasn't used more than once afterwards.

This shouldn't be much of a problem for spammers if they can set up a new MTA in five minutes, but if they (for instance) have to get three people in good standing to sign the new MTA's key in order to be able to start a new spam run, then it gets more troublesome for them.

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.

Why would a spammer limit themselves to a single MTA, or account. Run
VMware on a laptop, and there could easliy be 10 parallel rate-limited
sessions going on. If the rates are low enough, each virtual system
could automatically log into another account on another MTA, then come
back when the timer goes off.

At a limit of 1000 messages per hour per account, they need 10000 account-hours to send out 10 million spam messages. Assuming it takes 64 hours (on the weekend) to get an account yanked for spamming that's 160 accounts. This is a good start. Add some additional stuff such as limiting the number of messages per hour based on the number of bounces received and we should have something that's pretty effective.




<Prev in Thread] Current Thread [Next in Thread>