Re: Comments on IM2000

On Thu, Apr 14, 2005 at 09:34:26PM -0000, James Craig Burley wrote:
> I didn't explain that very concisely, I guess.  I block email with
> envelope senders *known* to *belong* to spammers.

Oh, so you mean the tiny proportion of spam which does not carry a forged
return-path. Clearly, the more people who implement this check, the higher
the incentive for spammers to forge their return addresses.

Maybe we need to think of adding some sub-classification to "spam". The vast
majority of the spam I see is from scumbags. They want to get their
fraudulent message into my inbox, and either get eyeballs on their website,
or get me to phone or fax them for the con-trick to begin. They don't care
if I can E-mail them back or not, and they don't care if any of their
millions of messages bounces. It's a positive boon if the E-mail is
difficult to track back to source (since they are almost certainly involved
in fraud anyway)

Hence the random return addresses, sending spam through 0wned bots, and so
forth.

There is a lesser category of spam: people who are engaging in legitimate
business, and who would quite happily be contacted by return of E-mail.
These people are probably also not too concerned about bounces, since when
you send to 10 million people you probably don't care than 1 million bounce
(and indeed, don't want to deal with the fallout), but they'll probably give
a real E-mail address in the message body.

These people don't use 0wned machines (which would also be criminal). Their
"crime" is simply a distasteful use of a broad barrage of E-mail to an
extremely large number of mailboxes, knowing full well that the vast
majority are not at all interested. They are happy to cause them annoyance
and waste their time, bandwidth and mailbox space.

> >But your definition of spam is "sent by a program which does not correctly
> >implement Internet RFCs".
> 
> No no no no no!  My definition of "spam" is everyone else's -- UBE.
> It so happens that a substantial % of UBE-sending software can't
> tolerate trivial variations in SMTP server responses, such as
> multiline greetings.

And so does another percentage of legitimate E-mail sources. Maybe your trap
catches more spam than non-spam - today. But it will have false positives
today, and as the spammers change, it will get worse.

I think what you were saying before is that it's the *content* which
distinguishes a spam from a non-spam; I won't argue too strongly against
that. Certainly, a human being paid to delete spam from your inbox would do
a very good job, just by examining each message.

But for any sort of automated spam control to work, the only other useful
definition of spam I can see is "stuff that is sent by spammers".

If you were able to block all communication from spammers, you'd block all
spam (by definition). You'd also block all non-spam sent by spammers, but
since they are scum, most people don't care. You might care if your job is
to run an abuse-tracking service, and you need to be able to communicate
with spammers.

You'd block all non-spam sent by machines which have been hacked into by
spammers. That's an unfortunate consequence, but hacked machines really
shouldn't be on the network in the first place.

For me this means: blacklists of spammers' accounts (and machines controlled
by spammers).

IP-based RBLs work surprisingly well. If you combine a blacklist of IP
blocks owned by spammers (e.g. spamhaus), one of open relays and proxies,
and a dynamic one which reacts in real time to new spam sources (e.g.
spamcop), they work pretty well even in the current world. The problems are
to do with identifying new sources quickly enough, and more importantly the
collateral damage when you list an IP address which belongs to a mailserver
shared between spammers and legitimate users.

To avoid that damage, you need an indication with each message of the
account identity used to submit it. This could be done with SMTP AUTH; but
inertia means it won't happen. It is an inherent capability of IM2000.

> >However, this means you'll refuse to accept mail
> >from "good" mail sources which also happen not to implement the RFCs in the
> >expected way.
> 
> No I won't.  *Their* clients will just have trouble transmitting email
> to me.  That's *their* problem -- I haven't "refused" it at all.

I fail to see the difference between causing a problem when someone tries to
send you a mail (such that it cannot be delivered), and refusing to accept
the mail.

Most people are *users* of E-mail software. They do not have the technical
ability to *fix* the E-mail software that they use.

> All of the "fixes" spammers need to apply to jump those hurdles
> represent additional cost, especially writing and deploying new
> software.

They *will* happen, and soon (i.e. within months at most), as surely as the
widespread implementation of MAIL FROM domain checks made spammers change to
sending out mail with real (but forged) E-mail addresses as the envelope
sender. The cost is minimal.

> No, as is widely recognized.  It's a temporary tactic, one which
> raises the bar in terms of increasing the expense of sending UBE (and
> the visibility that one is doing so), which is kinda the whole point
> of IM2000, right?

No.

I don't support any change in the E-mail system that we use today, which can
be bypassed just by the spammer changing tactic. Any solution has to be
*strong*. Otherwise, it's a total waste of time.

And incidentally, being on this list doesn't mean I think we *should* all
switch to IM2000. I'm still thinking about it :-)

It's clear that IM2000 still allows spam to be sent; ISTM however that *any*
concept of a 'mailbox' which arbitary people are allowed to drop mail
into, will also support the delivery of spam.

At the moment, I think the best we can achieve is the near-instant
"cancellation" of accounts being used to send spam; and the blacklisting of
IP sources which allow unrestricted creation of new accounts, or unlimited
sending of messages from a single account, or are entirely controlled by
spammers.

It has to be reactive like this, since spammers can create new on-line
identities at will.

IM2000 suits this sort of cancellation pretty well, and the level of changes
required across the Internet to achieve the same thing with SMTP would be of
similar order of magnitude.

Regards,

Brian.