(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.