Re: Comments on IM2000

On Wed, Apr 13, 2005 at 03:01:32PM -0000, James Craig Burley wrote:
> Heh..."FUSSP"?

The Final, Universal Solution to the Spam Problem:
http://www.fussp.org/

> But there are things we're doing with today's technology *now* that
> would have been thought of as "requiring" AI 20 years ago.  Google
> comes to mind, and when I think of how one of the ways it "works" is
> by drawing conclusions partly based on connections among trusted
> relationships, I think similar approaches can be brought to bear on
> the UBE problem.
> 
> (We're already using such approaches on an ad-hoc basis, in the form
> of RBLs, including arbitrarily blocking dynamic-IP-hosted MTAs like
> mine.)

That's not artificial intelligence, that's just policy (or human
intelligence turned into policy). "I expect all legitimate mail to come via
an ISP smarthost and not directly from a client machine. Therefore, any
client machine which opens an SMTP connection to me must be a spam sender".

It's got a significant false-positive rate of course (as you've discovered),
and all it does is force spammers with 0wned machines to locate and use
their upstream ISP's smtp server instead, which they're now starting to do.

That's the problem with the current ad-hoc mix-n-match approach. You try to
combine a bunch of techniques which, today, may indicate the possibility of
spamminess. The more viciously you apply these, the more you break
legitimate mail, and the more the spammers adapt.

Take SPF: research apparently shows that more spam is SPF-compliant than
non-spam. So if you want to use SPF as part of your spam-filtering policy,
you should bias SPF-compliant sources as more likely to be spam :-)

> >* It's an interesting point that the real criteria as to whether spam is
> >wanted or not is based on the content. However, I think you're imagining a
> >future world where a significant portion of bulk E-mail is sent from
> >legitimate businesses that you might actually want to deal with.
> 
> Not really, because, my "future world" includes a vast number of
> smaller, lighter-weight businesses (and other organizations, as well
> as people), from which I *might* indeed want to receive information on
> deals, offers, alerts (e.g. from churches, charities), and so on.
> 
> The infrastructure allows that kind of thing, except *I* don't have
> time to sort through it all myself, without some kind of technological
> assistance.

But is it reasonable to *require* anyone with an E-mail address to accept
arbitrary amounts of junk and to have to put in place the infrastructure to
filter it themselves? Doesn't it make more sense for the person who is
interested in particular deals, offers, alerts etc. to go to a broker who
collates these things, and pull them down on demand?

Despite filtering, I occasionally get spams from Taiwanese companies who
sell earth-moving equipment or build ships or whatever, and are looking for
distributors in the West. Assume for the moment that these are legitimate,
and not fronts for scams. Optimistically, one in ten thousand recipients
might actually work for a wholesaler/distributor who would be interested in
importing these things.

At best, the other 99.99% is wasted bandwidth, storage and/or filtering
effort. Why should these people be able to *push* this content to me, and
therefore force me to filter it?

Let's say effective filtering is available, at a price. Let's say 50% of
Internet users have this effective filtering (they buy it and install it on
their own PCs, or their ISP buys it and installs it for them). What are the
other 50% of users supposed to do?

> Right.  Remember, the most "obvious" way to know whether something is
> UBE, or at least BE, is the fact that it's sent in *bulk* to many
> recipients.
> 
> Therefore, recipients sharing information that "profiles" sources
> and/or topics of emails can discover, among themselves, that certain
> sources and/or topics are so widely involved in email, within a given
> period, that they indicate bulk.  Then it's up to each recipient to
> decide, based on the source, the degree to which it's unsolicited.

The trouble with distributed-trust systems is that you have to apply a level
of trust to the value judgements made by other people, but don't have the
resources to evaluate each of those other people. In other words, a spammer
can easily infiltrate such a system by sending in false positive reports -
"I just received this mail, and it was just what I wanted".

> My concern, here, is that we keep in mind that making email systems
> work *better* means, generally, we'll get even more email

Well, perhaps that's just the same problem restated differently.

If the postal mail system were to work better - if letters were delivered in
1 hour instead of 1 or 2 days - would that increase the amount of postal
mail I receive? Perhaps, because some things would be feasible to do by
postal mail which are not feasible now (e.g. some things which are done by
phone or fax now might be done by post instead).

But would that automatically increase the total amount of information which
I receive and have to process, post and non-post? I don't think so.

I think this only applies because spam is so cheap (and because spam is hard
to trace, although this applies to postal mail too)

> So, I find myself forced to imagine a more intelligent MUA that helps
> users sift through their incoming email based on more personal
> criteria.  Such an MUA would obviously appreciate having more
> information upon which to draw -- including message content -- in
> order to prepare its presentation to its end user.  Accordingly, it
> would want itself, and other MUAs, to be able to share information by
> propagating it upstream and to fellow MUAs, helping all of them detect
> bulk email, etc.

As I say, I don't think this can work except in small communities of users
who know and trust each other. It could work if there is a trusted third
party which all the users in turn trust to make value judgements on their
mail. This is essentially what DCC and spamcop do now.

> >Therefore, the fact that it's received as UBE *automatically* classifies it
> >as uninteresting to me, regardless of content. And so it should for everyone
> >else; unfortunately, even with a hit rate of 1 in 1000 or less, there are
> >still enough born every minute to make it worth the fraudulent spammer's
> >time. The other 999 spams cause huge annoyance, but the law enforcement
> >agencies at present seem completely disinterested in tracking down these
> >fraudsters - even when the spams include postal or telephone contact points
> >which would be easy to trace or sting.
> 
> When you say "received as UBE", I assume you mean from a known
> *source* of UBE, that is, not based on content analysis.

My incoming mail currently comes via some RBL blacklists (spam sources),
clamav (known bad content) and SpamAssassin on a friend's system.

You're right, if I am manually filtering messages in my inbox, then I
recognise spam by its content, its "spamminess". But I don't think that
automated systems are too good at this. Automated systems can analyse the
source and establish that it's bulk sending; humans are needed to judge
whether the bulk sending is justified (e.g. opt-in mailing lists, business
transactions) or attempts at fraud. This would be based partly on content,
and partly on exterior factors such as which IP address it comes from, which
in turn can be cross-referenced to forward and reverse DNS, registry IP
allocations, and such like.

> So, since SMTP already provides means to block incoming content from
> known UBE sources

Partly. IP-based RBLs are pretty effective, but not 100%.

The main issue is that IP addresses are shared. If you receive a mail from
smtp.example.net, it may be a spammer blatting content through it, or it
could be a legitimate user sending a legitimate mail.

SMTP smarthosts almost always require no authentication other than the
source IP address being in a known range. Combined with dynamic IP
allocation, that means it's very hard for an SMTP server to know which
account is being used to send messages, and to limit messages sent from that
account.

To make these systems properly effective you'd need to force senders to use
SMTP AUTH when connecting.

> And since both allow a receiving system to "tarpit" a known sender of
> UBE in some fashion, driving up her costs even just a bit, I cancel
> *that* out.

It *can* be done with SMTP, but in general it isn't.

Why not? Because (a) it's reasonably difficult, and (b) almost all the
benefit doesn't accrue to the person doing the work, but to the rest of the
Internet.

Even if you could persuade 50% of all ISPs to do this work, the spam problem
would be reduced by (at most) 50%.

Solutions won't be applied unless the benefit accrues immediately to the
implementor. This is why people are implementing things like SES. (If you
implement SES, then you are immune to 'joe job' bounces, and it's *your*
users who benefit)

> Consider bounces.  They made sense in a tangible-delivery context,
> because if you send Aunt Emma a package containing pictures of your
> newborn, and it can't be delivered for some reason, you *really* need
> those pictures to be shipped back to you by the delivery agent.  That
> agent simply dropping them into the trash isn't really a legitimate
> option.
> 
> So, it also made sense, to the designers of SMTP and some of its
> predecessors, that "electronic" mail was simply just mail done
> electronically.  As there was no tracking of tangible deliveries then,
> they provided none in the electronic version.  As the responsibility
> for delivering tangible mail naturally has to tag along with the
> content of that mail (and, pretty much or closely at least, with the
> notification that the mail is available), SMTP was endowed with the
> notion that responsibility for message delivery accompanied message
> content, and included responsibility for subsequent notification of
> delivery failure.

Sure, and it worked just fine too. However it gave too much trust to
untrusted parties: when accepting the mail, you trust that the return
address they give is correct. Giving the wrong return address just causes a
nuisance in the event that spam is undeliverable; it also puts (some) people
on the wrong track when trying to report a spam incident, because they
(wrongly) assume that the return path has some validity, which it does not
for spam.

Note that SMTP does not *require* the entire message to be returned in the
event of failure; just a notification that it failed.

> >  - Bulk mail, untrusted sender
> >      => probably fraudulent (= chain letters)
> >  - Bulk mail, classified as legitimate advertising by trusted third party,
> >    classified by subject area
> >      => can choose to reject based on the fact it's advertising (= MPS)
> >      => can choose to accept or reject based on subject area (= PPS)
> >
> >Such systems would work because you are not having to assess a level of
> >trust in potentially thousands of different organisations or individuals
> >trying to contact you each day, down to a handful of agencies who sign and
> >classify 'legitimate' advertising.
> 
> I'm still having trouble understanding how IM2000 makes this work
> *that* much better than SMTP.

You get an undeniable sender identity. And because the message is not
mangled by SMTP hops, you have a better chance of taking a reliable hash of
the message content, and (if you wish) of crytographically signing it.

> That definitely has collateral damage.  I don't use any traditional
> RBLs, though I do block email with envelope senders of known spammers

But that's stupid, because the envelope sender cannot be trusted!

One of my friends works at a UK government agency. Their system is sent up
to reject all mail sent from addresses @pobox.com (and hence mine), saying
that this is a "known source of spam".

In fact, pobox.com has *very* tight policies for its customer base. But that
doesn't stop someone else sending out spams which appear to be from
[email protected]. And therefore, the person who implemented this "anti-spam"
system decided (stupidly) to block mail from pobox.com.

Such a blacklist *could* work with IM2000 though.

It *could* also work with SMTP AUTH and a whitelist of trusted SMTP sources
(that is, those who are known to implement SMTP AUTH and truthfully pass on
the authenticated sender information when relaying messages)

But there's too much intertia to implement this.

> based on a central repository run by someone who uses whois-style
> lookups to confirm that domain names and/or email addresses are indeed
> "owned" by known spammers (so joe jobs do not result in innocents
> being listed).

That's roughly what SPF tries to do.

> But I really don't end up *seeing* lots of spam, because my primitive
> MTA (funnily patched qmail) dispenses with most of it via a
> combination of very trivial tactics -- giving a multi-line greeting in
> most cases, tarpitting multiple RCPTs, and a few other very simple
> content-based things done on the fly -- which somehow conspire to
> rebuke most older spam software

But your definition of spam is "sent by a program which does not correctly
implement Internet RFCs". 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. And besides, if your methods really are effective and lots of
people start to implement them, then the spammers will just "correct" their
code.

You are just helping to force spammers to write better software!

The same happened to checking domains on MAIL FROM. Originally, spammers
used to send mail with MAIL FROM:<abc@xyz123> or other made-up addresses.
People started to validate the domain portion, since this was quite a good
indication of spam. As a result, all spam is being sent with valid return
addresses of innocent people (spammers have nice big lists of E-mail
addresses that they can pick these from, of course). So as a result, the
problem is worse:
* we now have "joe jobs" to contend with
* plus, users who have accidentally misconfigured MUAs, which used to be
  able to send us mail, are no longer able to do so

> So, there *has* to be a widely supported means for any software
> running on a home PC to send an arbitrary email "upstream" to an MTA
> (SMTP server, IM2000 message store, whatever) that is more trusted and
> more assuredly connected (that is, a real server, not a home PC that
> can and might well be turned off as soon as a message is "sent") than
> the home PC or a Blackberry.
> 
> That means 0wned machines will send such emails via that same method
> anyway.  IM2000 really can't improve on this at all, that I can see,
> in terms of the volume of such messages reaching a recipient's inbox.

Well, they can easily count the number of messages sent via a particular
message store in a day, and apply a limit. This is harder to do with SMTP
relays.

> Sysadmins are always asking questions (on the qmail list anyway) about
> how to get finer-grained control over lifetime of emails in their
> outgoing queues, as well as over incoming message sizes, and the like.

Sysadmins can do whatever they like with messages on the systems they manage
- if their software is flexible enough. qmail is pretty poor in that regard.
If you haven't seen Exim, then you need to :-)

> IM2000, being a "new" protocol, can enable such things out of the box
> with less muss and fuss.  The question is, does that offset the
> *penalties* that go along with IM2000 being a "new" protocol (in terms
> of adoption expense, etc.)?

I think a replacement protocol will only be implemented if it gives
immediate benefits to the implementors themselves. I can see those as being:

- company and departmental mailservers
- people who communicate with small trusted user groups (e.g. family)

Those users would benefit from having more trust in the mail they receive
via the new protocol, and fewer filtering false-positives, whilst still
having gateways for the old protocols when talking to people who have not
migrated.

> What I mean is that, in a greylisting-type system, it is assumed (and,
> often, correctly so) that a second or third attempt to send an email
> lowers the probability that it's UBE.

Only because spam senders today don't bother to perform retries. If it
becomes worth their while to do so, they most definitely will. It is, after
all, not difficult.

> I see email as representing a subset of a continuum here, though.  If
> I'm maintaining a software package, incoming patches and bug reports
> are really a lot like email messages

Oh indeed. For a lot of people, being able to receive mail from the whole
Internet is important. [email protected] would be a big exapmle.

> Though I have yet to delve into the world of wikis, I *think* they are
> kinda like what I mean here.  It's the maintainer of the wiki'd site
> who, theoretically, wants to receive arbitrary updates regarding the
> content of the site from arbitrary people, and that's an email-like
> model

It's more of a bulletin board model, based on trust. Anybody can update the
wiki, without reference to the admin. If it is defaced, the admin (or anyone
else) can put it back to rights.

Wikis are getting defaced a lot at the moment, because of link-counting
search engines. Wiki-spammers are putting links to their own sites on every
Wiki they can find, just to move their sites up in the search engine
rankings. Vandalism... but despite it, some wikis still seem to survive.

Regards,

Brian.