Re: Comments on IM2000

On Mon, May 09, 2005 at 08:56:04AM -0000, James Craig Burley wrote:
> >There's no point having another button which says "send but don't
> >try very hard". Why would I ever push that button when I could push "send"
> >to have a better chance of my message being delivered?
> 
> If the default is like SMTP, the default "Send" button would probably
> do little more than transmit the message and then send one tracking
> request about a minute later, another maybe 10 minutes later, a third
> maybe 24 hours later, and a fourth about a week or two later, as
> necessary.

And if, in practice, that is not good enough to ensure successful delivery
in the vast majority of cases, then senders will choose more aggressive
parameters.

> Spammers will naturally keep trying to gin up new identities, but the
> new system is more easily able to "punish" that, without necessarily
> triggering a lot of false positives, by expecting any *legitimate*
> messages that come from unknown sources to be reasonably and
> frequently tracked by their sender.

And assuming that they do, since they desire to get their spam through, what
have we gained? You assert that this tracking is likely to be too expensive
for them. I assert that it is trivial, and demonstrated how to write a
program to do it for many millions of recipients.

> I get the impression you don't yet have a *coherent* view of what an
> email *system* should do.

My view has always been:
- spam is anything which originates from spammers
- if we can quickly and unambiguously recognise new spam sources, before much
  of it has been delivered, then we can block it before it causes much of a
  nuisance, and also make it so ineffective as to be not worth sending in
  the first place
- if we can identify the sender accurately and quickly, this would help
  enforce anti-spamming laws

What should the E-mail system do? It should have an *unforgeable* identity
in each incoming message; and we should be able to tell where that identity
originated from, so that a place where large numbers of identities are
created for spammers can be treated as a single identity.

I'm afraid I don't see many other approaches. Trying to identify patterns of
behaviour which characterise spammers from non-spammers is doomed, because
spammers can *easily* mimic the behaviour of non-spammers. This is what they
did when people started filtering on non-existent MAIL FROM:<...> domains,
for example.

The one thing which spammers can't mimic is the fact that they send spam -
vast quantities of untargetted mail. If you can detect this reliably,
without harming those people who have legitimate reasons for sending large
quantities of mail, then you have a good solution against spam. Sooner or
later a human element and a trusted third party need to be involved, simply
to share the work of classifying new sources. (You see such TTPs as
potential points of attack - as indeed they are - but I believe such systems
are capable of being built in such a way as to defend themselves).

Current solutions such as RBLs and DCC attempt to implement exactly this,
with some degree of success, but with an unfortunate amount of collateral
damage simply because SMTP doesn't give them a sufficiently fine-grained
view of the sender identity, particularly when mail goes via shared relays.
And because they are not sufficiently good at their job, people implement
other types of filtering too, which often block legitimate mail.

Now, that's assuming you want to be able to receive mails from people you
don't know. The only other solution I can see is to take the view that
everyone you don't know is suspect. This also requires an unforgeable sender
identity - so you can create whitelists of your friends. Anyone who is not
known, needs to be given a sufficiently difficult thing to do to get through
to you - whether that be pay a 5c e-stamp, or spend 5 x 1GHz CPU-seconds
calculating a cryptographic problem. This could be anything which a single
person sending you mail could do at low expenses, but for which sending a
million mails would become prohibitively expensive. (It may not be
prohibitively expensive if spammers *targetted* their lists, but then it
wouldn't be spam any more)

But the extra work involved by the spammer has to be quantifiable, and
controllable (so that over time, the "cost" can be increased proportionately
as required by improvements in CPU speed, devaluation of the cent, or
whatever). An arbitary constant constraint like "must poll for message a few
times in a certain period" doesn't really cut it.

Regards,

Brian.