Re: Comments on IM2000

>   As long as you don't let people read mail(IM2000) or deliver 
>mail(SMTP) if they can't reach  the blacklist service (via *whatever* 
>protocol) DoS-ing the blacklist service doesn't let people read your 
>spam; rather it prevents them reading anything, including the spam.  And 
>once the DoS ends, people can once again get the blacklist info and drop 
>the spam.
>
>    That is, the signifigant difference is that in the SMTP 
>implementations to which you refer, DoS-ing the blacklist works because 
>mail gets delivered if the blacklist is unreachable.  If you refuse mail 
>  ("try again later") when you can't reach your blacklist(s),  DoSing 
>the blacklist just backs up *all* the mail, and doesn't let your spam 
>through, either.
>
>    However, that does bring in your other argument -- if people DoS the
>blacklists for a service that works this way, and stop *all* mail, 
>people may decide that this design is untenable, and dump it.  Classic
>prisoners dilemma -- if everyone would stick to a 
>no-blacklist==no-delivery rule, the spammers would have to give in
>'cause they can't live without email delivery, either.  But as long as
>some amount of folks just drop the rule to let their legitamate mail 
>through, then the spammers win.  And the spammers are willing to
>go a few days or a week without their mail getting through...

Yes, this is all correct.

It's important to realize that there exists a *continuum*, between
unimpeded blacklists and fully-DoS'ed blacklists, such that email
delivery *slows* down, and such that *some* hosts experience more of a
slowdown than others.

That is, spammers can focus their attacks on the sites that they find
to be most of concern.  (Just as some apparently attacked and
destroyed a site that was providing free C/R for hotmail, or some
other free email service, by forcing it to thrash around delivering
all sorts of spurious Challenges.)

Practically speaking, this has significant implications for any design
that assumes all white hats would agree to stop accepting email in the
face of such an attack.

How would they know whether the attack was across the board?  They'd
have to *communicate* regarding whether to keep relying on the DoS'ed
blacklist, or move to a new one.  And how would they do that, since
their main method of communication -- email -- is under attack?  How
would they all agree to resume accepting email, since the effects of
the DoS would probably never be *completely* uniform?

If the attack wasn't across the board, that means only a few sites are
affected.  That is, either the blacklist has chosen to specifically
stop responding to them (they're the source of too many problematic
callbacks, through no fault of their own), or *that* blacklist is out
while others are working.

Both possibilities have worrisome implications.  If spammers can
convince a blacklist operator to selectively deny some of his own
customers, he doesn't have any incentive to let up on the attack as
long as he is able to send email to users on systems that aren't
denied as customers of the blacklist.

But if there are multiple blacklists to choose from, the customers of
the targeted one might simply choose to switch to another blacklist in
order to receive email, at which point the attacker "wins", as the
blacklist no longer serves any purpose.

Alternatively, the customers of the targeted blacklist can communicate
with all legitimate (IM2000) customers of *all* blacklists, or perhaps
the blacklist operators communicate among themselves (recursing to the
communication problem described above either way)...

...and *everyone* decides to stop receiving email as long as *any* of
them are under attack.  This is a sort of "solidarity" response to an
external attack.

Problem is, this last approach is an overreaction to an attack; it
greatly amplifies the effect of *any* attack, as long as it has any
promise of success, improving the success rate of such attacks to the
point that the system as a whole is useless.


In summary, I don't believe blacklists represent a viable long-term
"solution" to the UBE problem.  They have short-term convenience, but
they don't scale up well.

It might actually be better to have, instead of a few central
blacklists, a few central relays (for SMTP) or mail stores (for
IM2000) that provide only authorized access to email, upon which
everyone (or most everyone) chooses to rely to exchange email.

Since everyone is ultimately relying on a handful of root servers for
DNS, it's not all that difficult to believe that centralized email
*exchange* (rather than exchanging only some tangentially interesting
metadata on email) could be the simplest and most direct approach to
getting rid of (most) UBE.

I don't like that solution either.  I just like the fact that it makes
the centralized third parties act, simultaneously, both as *enablers*
and *disablers* of email exchange, making it much harder for spammers
to DoS them while still getting their UBE through them.

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>