Re: How is it a solution to spam?

"Stelian" <[email protected]> Tue, 1 Jun 2004 19:14:16 +0300
Newsgroups gmane.mail.im2000
Message-ID <000901c447f3$7d2cf5a0$7853c451@compk3f8yezqq2>
>> Each domain is used for a few hours for sending, making RBL very
>> hard to do. After the notification hit the users inbox, you can't do
>> much.
>
> The one big selling point of IM2000 is that the sending machine has to
> be traceable. For the recipients to be able fetch the mail from it, it
> has to have a static IP or at least an MX record (or equivalent)

Well, sending machines are already traceable in SMTP. The spammer can always
try to spoof his address, ex. by adding more Received fields, but this is
easily detected.
The requirement that the sending machine has to be online when the message
is read is of curse harder to satisfy, but if the operation is decentralized
using zombies and disposable domains, this can be achieved. IMO, the benefit
the spammer gets by being able to reach 20x people in a single run fully
justifies the trouble.
I'm even going to admit that the system will stop some spam, especially that
where rule no 3 applies (that's quite allot), but this is just not enough.
The costs required for changing the system completely must assure that most,
if not /all/ spam is gone.

>
> The system I'd always envisaged was a democratic blacklist..

Already possible and done. Not as effective as it seems in theory, for
reasons discussed below. Exterior to IM2000. We cannot make the change and
than expect that somebody devises some hack to stop spam under the new
system, it must be built in. The spam blocking must be proven against all
current are conceivable attacks before put in practice, and this still
leaves room for unconceivable but very real vulnerabilities, that the new
system presents.
I say the spam blocking must be built in, because this is the only way a
change could be made: spam is the only justification for such a massive
expense, because it can be recuperated in terms of productivity loss.

> if you
> open a message and it's spam, you click a button which notifies your
> blacklisting service. Once a critical mass of users have blacklisted
> the same server, the subscribers' software automatically refuses to
> fetch from there.

Hard to coordinate, as anything that requires many people to do something
together. Requires a central server. Easy to tamper with, see Google
bombing.

> You could make it hierarchical, so if the density of
> spammers in a particular domain or netblock exceeds a certain
> threshold, the whole thing gets blocked.

And at the same time suffer from all the sins of irresponsible DNS
blocklists
http://slashdot.org/yro/00/12/13/1853237.shtml

>
> The damage done by false positives is mitigated, because they'll
> remain on the sending server and can be resent when the server is
> removed from the blacklist.

Which could be to late, ex. for a business. Remember, this solution doesn't
use "the blacklist" it must use many, so the admin of the blocked domain
must go trough allot of trouble to be delisted from all, just like they do
today.

>
> Finally, it gives the big webmail providers a much easier way of
> stopping spam runs while they're still in progress. If they get a
> dozen complaints about mail from a particular user, they can delete
> that user's outgoing messages, potentially preventing millions of
> spams getting out.. The spammers can keep making new accounts, of
> course, but the sophisticated techniques that now exist for
> preventing automated account creation should slow them down
> significantly.

I don't think this is how most spam is sent, but I could be wrong. The
sophisticated techniques can be circumvented, especially if a human helps
you:
http://news.com.com/2100-1023_3-5207290.html?part=rss&tag=feed&subj=news

>
> The system doesn't have to be 100% perfect, it just has to make life
> sufficiently difficult for the scum for them to find something else to
> do with their time..
>

Well, spammers operate at different levels of response rates. Many spammers
work at the lowest level, by trying to send as much crap as possible to
everybody, and they do the most damage. A single reply in a million spams is
enough to make a profit, so small difference in the cost of a single email
can blow this balance off, making such spam unprofitable.
On the other hand, there are specialized spammers, with very targeted lists.
They send smaller volumes, and are much harder to stop, because their return
of investment per email is higher, so they are willing to pay to get their
message through. I once read that if challenge response systems became
common, many "direct marketers" are willing to pay humans for replying the
challenges (maybe porn will suffice, see above :).
Eh, at least we will see a change in the quality of spam.



>> Goodbye webbugs !
>
> I imagine many client implementations will prefetch messages they have
> received notifications for, before the user opens their mailbox. So
> while the fact that a message has been retrieves indicates it's been
> delivered ok, it doesn't prove it's been read.

Well, this effectively kills the idea of shifting the burden on the sender,
and it would make the system identical to the current one for all practical
purposes, from both the spammer and user POV. Consequently, it also kills
the traceability of the sender, in the sense you suggested in the first
paragraph.