Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: [spam-stopper] Akismet and Lyceum

  • To: spam-stopper@xxxxxxxxxxxxxxxxxxxx
  • Subject: Re: [spam-stopper] Akismet and Lyceum
  • From: Roy Schestowitz <r@xxxxxxxxxxxxxxx>
  • Date: Tue, 23 May 2006 22:13:37 +0100
  • Delivery-date: Tue, 23 May 2006 22:13:40 +0100
  • Envelope-to: s@schestowitz.com
  • In-reply-to: <Pine.LNX.4.61.0605182135150.12968@tribal.metalab.unc.edu>
  • References: <Pine.LNX.4.61.0605110201240.12883@tribal.metalab.unc.edu> <Pine.LNX.4.61.0605182135150.12968@tribal.metalab.unc.edu>
  • User-agent: Internet Messaging Program (IMP) H3 (4.0.3)
___/ On Fri 19 May 2006 02:36:43 BST, [ John Joseph Bachir ] wrote : \___

On Thu, 11 May 2006, John Joseph Bachir wrote:

Matt Mullenweg said:
Even if you're a non-profit, send something to the contact form
before doing this though, as putting too many blogs on a single key
without pinging us will get you blocked.

Hey,  John.  Seen your project mentioned in a Linux site a couple of  days
ago, so congrats.

What do the Akismet folks see as the most ideal practice for
multi-blog installations in the long term? My impression is that the
Akismet heuristics depend on there being one key per 'person', to
determine if someone is trying to game the system. Would it be
impossible to install one key for a multi-blog system the 'right

The  same  problems  (potentially) exist in WordPress, namely  /em  masse/
registrations  and installations of blogs. With enough E-mail accounts, it
is  also  possible to game the system with wp.com accounts. Clearly,  this
may  be  more  difficult  than mass  instantiation  of  Blogspot  accounts
(reasonable  example  due  to  their notoriety, attributed to  SEO  and  a
plethora of abuses) where everything is rather lenient.

Is  it  possible to become just a client of Akismet  without  contributing
back?  I  don't  see much harm in that. The sample set is very  large  and
diverse  already.  Then  again, I am not familiar with the  system,  so  I
should probably make no such remarks.

For example on deployments with open registration, there may be a
few users trying to game the system amongst the many legitimate
users. Are there other options for differenciating these things,
such as url / domain name?

Why  not distributing a different key to each user? I believe this can  be
trivially implemented, even if databases are shared.

It seems like making the heuristics compatible with single-key
multiblog applications would be desirable eventually. For commercial
installs you guys could charge per head. <kool-aid guy voice>Oh

Anyone have any thoughts on this?

To  make  a good statistical discriminant, you probably don't need  /that/
much  input. To a user who relied on Spamcop or SpamAssassin, for example,
all  that  is  needed is a clean system that is regularly fed  by  trusted
sources  until  it matures. As long as it gets regular input,  it  remains

Best wishes,


Roy S. Schestowitz      |    Useless fact: ~70% of organisms are bacteria
http://Schestowitz.com  |  SuSE GNU/Linux   ¦     PGP-Key: 0x74572E8E
10:00pm  up 26 days  4:39,  11 users,  load average: 1.20, 1.11, 0.91
     http://iuron.com - help build a non-profit search engine

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index