[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Anti-Spambot: what algorithm should be used?
Dr.Dimitri Vulis KOTM wrote:
> > Another problem: what would prevent an anti-spam zealot from posting
> > the following:
> >
> > From: [email protected]
> > Newsgroups: rec.sports.phishing,alt.fan.alice
> > Message-ID: <[email protected]>
> >
> > <something phishing-related>
> > --
> > Alice's ID# 123456 Drink Kaka Kola -- Kaka Cola is full of shit,
> > do not drink it, I am just collecting $$ from
> > stupid Alice, Hahaha!!!
>
> Yes, Bob could post something like "drink kaka cola and die" and
> "elect John M Gubor Sheriff if you want to be arrested".
> Hopefully, most Bob's won't.
That's questionable at best. Also, there can be so much ingenuity in
making the ads appear unreadable, that it would be hard to watch who
is good and who is bad.
For example, how about this signature that purports to advertise
http://www.kaka-kola.com:
^L^L^L
-----------------------------------------------------------------------
= please ignore contents of this sig -- skdjhgf asdgf -- == <blink>
<color=#000000> = http://www.devnull.com http://acd http://www.www.www
http://www.kaka-kola.com http://xxx == </color></blink> == this sig
intentionally made unreadable to cheat alice ==
-----------------------------------------------------------------------
> I guess the solution is for Alice's clients to pick regexps such
> that _any_ publicity is good publicity - such as a URL or a 900 number.
> If the regexp is "John Gilmore is a cocksucker", what can Bob add to it? :-)
See above
> > remember though that it will not be hard to modify newsreader clients to
> > automatically killfile all articles matching Alice's regexps, or even to
> > grab them automatically from her website. So Alice may discover that her
> > business is not as effective.
>
> Killfiles? So many scumbags whine about their inability to use them,
> so they try to silence whomever they don't like.
> Yes, if Alice just posts her regexps on a public Web page, a clueful
> person can automatically fetch them and add them to his killfile or
> even forge cancels for Bobs' articles that contain them.
> I think this would be a stupid thing to do because Bobs' articles
> may contain useful information besides Alice's ad. Also the regexp
> might occur in a followup to Bob's article, which may contain
> useful information.
Well, one can modify newsreaders to delete only lines that match
the regexps, but show other parts of the article. That may be one
of the pieces of functionailty of libkillfile.so that I once mentioned.
> Alice can try to keep her list of regexp's "confidential" and only
> give it out to Bobs that are the prospective posters. I don't think
> this would work. Someone would pose as a potential agent, obtain
> the list of regexps, and post it (perhaps via an anonymous remailer).
> So Alice might as well make it public.
Agree.
> Another possible candidate for killfile trigger is the "Alice ID".
> Alice can make it harder by not using one (as I originally proposed)
> but instead by recognizing the address "From:" header.
Another thing Alice can do is to make Bob post an encrypted ID, such
that each time it is encrypted with a separate "session" key. The
keys do not have to be that long.
Instead of ID Bob can encrypt the address to send the money to, and
possibly his public key. That generally adds robustness to the system,
since there would be no known person to complain about.
Bob can also ask Alice to generate a lot of IDs for him -- like 1000 or
so -- to use them later. Alice would have to keep a database of
ID <---> email address correspondence.
Alice can set up an autoresponder bot [email protected] that would generate
IDs and send them back to requestors.
> On the second thought, Alice may not need a prior contract with Bob,
> nor the ID#. She can just list the regexps she's trying to promote
> on her web page and go promiscuously by the address in the From: header.
>
> And if we forego the ID# and just look at the From: header then it's
> simpler: if Carol quotes Bob's article and includes a regexp, then Carol
> gets an e-mail from Alice with some e-cash, perhaps sent via an
> anonymous remailer.
>
> One problem is that a lot of people put fake addresses in the from:
> fields. Why waste good e-cash on e-mail to addresses that bounce?
See above.
> What Alice could do is send an e-mail like
> "Your article with message-id blah posted to blah contains
> a message that I'm paying to promote. Here is a cookie;
> if you return this cookie, I'll send you $n e-cash."
> If it bounces, or if the recipient never sends back the cookie - too bad.
If it bounces, Alice would usually get the money back in the bounce message.
Can't alice put a stop on a piece of digital cash? I am not sure, but it
may be possible. It is surely possible with adding one more trusted party,
and some more signing and encryption, anyway.
> > Alice's contract can also specify that if a third party forges a cancel
> > within a week for Bob's Usenet article containing the regexp, then Alice
> > will pay nothing and let Bob sue the forger for the lost income. (This
> > may become moot as more and more ISPs ignore forged cancels.) This gives
> > Bob the insentive to spam intelligently - not to trigger any cancelbots
> > and not to have his plug pulled by his ISP.
>
> After Alice's bot finds an eligible Usenet article, it should wait
> a week or so to see if it was cancelled or superseded before issuing a
> payment. If it's cancelled, then instead of payment it should send
> a notice saying:
> "Your article with message-id blah posted to blah contains
> a message that I'm paying to promote. I would have paid
> you $n e-cash, but unfortunately a cancel has been issued
> for your article: <quote cancel>"
> That should get Bob pretty mad at the 3rd party canceller. :-)
Alice can then cheat and issue the cancels herself. Since most spammers
are crooks, I expect that to happen a lot. No good.
> > Alice can also put some reasonable caps on the number of repetitions
> > because if Bob posts the same regexp 10,000 times, the marginal exposure
> > is less from Bob than from a newbie Carol. Again, if there are several
> > such Alices, the market will take care of negotiating such details.
>
> Alice needs to maintain a map of (poster,newsgroup,regexp) to # posts;
> when it reaches 100, stop paying this poster. I think 100 mentions by
> the same poster is way past saturation.
I can generate a gazillion posters from algebra.com.
Of course, Alice can also introduce per-domain restrictions.
- Igor.