[Operators] How-to fight with SPAM accounts

Mihael Pranjić tux at limun.org
Sat Dec 12 08:19:40 CST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009-12-12 05:28, Peter Saint-Andre wrote:
> On 12/11/09 9:08 PM, Mihael Pranjić wrote:
>> On 2009-12-12 04:06, Peter Saint-Andre wrote:
>>> On 12/9/09 2:51 PM, Jesse Thompson wrote:
>>>> On 12/3/2009 3:02 PM, Peter Saint-Andre wrote:
>>>>> On 12/2/09 2:22 PM, Jesse Thompson wrote:
>>>>>> Peter Saint-Andre wrote:
>>>>>>> On 11/25/09 11:53 AM, Jesse Thompson wrote:
>>>>>>>> Peter Saint-Andre wrote:
The message got a bit huge IMHO, I removed the lines I am not going to
comment, however I left the authors.

> So what? We've had that for 10+ years. Unused accounts are a fact of
> life, not a problem.
But I dont think we can not solve problems here. Probably its not even a
big problem at all. I just know that most services keep deleting old
unused accounts. I was quite interested in what others think should be
the general approach to this. IMHO gravitation is a fact of life but in
some point I agree that unused accounts are not _such_ a problem.
>> So how to fight with that? Should it be a standard of XMPP services to
>> remove accounts that were just created and then not used for 2 weeks or
>> more. 
> 
> IMHO that is not a best practice for XMPP operators.
> 
>> Should it even be a standard to remove accounts at all? 
> 
> Unclear, and a different thread.
> 
>> Are we
>> removing them because we want someone else to use the JID that becomes
>> free or do we want a database without unnecessary accounts? If you want
>> to bypass the problem of the identification of a person and also save
>> disk space and have less "spam" accounts in your database there would be
>> a simple solution. Keep a table with deleted accounts and disallow
>> re-registration.
> 
> Sure. Make a feature request or send in a patch to your favorite server
> project. :)
> 
>> What we get: only one person can register it, and we can safely remove
>> accounts. Maybe not only an unsubscription request should be sent to all
>> the contacts of the roster, but also a message containing for instance
>> "This account has been automatically removed by our system because it
>> was not used". This would leave it open if you should allow
>> re-registerin because in a way the contacts would be informed that the
>> account was deleted.
>> Also it would be possible to keep a list when accounts were deleted and
>> re-registered. It takes a huge database but would make it possible to
>> see if an account still belongs to the person you think it does. If you
>> see that it apparently changed owner you can assume that it is not the
>> same person.This idea again leads to some kind of centralization of data.
> 
> Single point of failure. Never a good idea, and opposed to the basic
> XMPP philosophy of decentralization.

I kind of forgot to mention that I dont like centralization either...
and yes it is opposed to the basic XMPP philosophy but I still wanted to
mention it.

>> So in short imho:
>> CAPTCHA - yes
>> Problems - not really solved
> 
> The problems are not clear to me in what you describe. The issue of
> deleted accounts is tangential to the spam issue.
What I was saying is that CAPTCHA raises the probability of
human-created-accounts. However, you may still have thousands of unused
accounts. Is it safe to just remove them?


>> o.O
> 
> What the hell is "o.O"???
> 

o.O or O.o should be an emoticon...

>> Afaik we were trying to find a way to safely remove unused accounts on a
>> server. Spam may become a problem, but you can just block a user and the
>> problem is gone.
> 
> I don't care about unused accounts, except that I don't want a million
> accounts clogging up the jabber.org service. 330,000 semi-active
> accounts is enough for me.

Semi-active: yes, but there are accounts that are not used for years, I
dont call that semi-active.

Mihael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksjpnYACgkQr+feV2OERJ5wZgCfYjWqytO6p2winoeyy3aPAs1Y
CI4AnikNTZSLEzGLJJqCt1PXbbOODvQM
=//Lt
-----END PGP SIGNATURE-----


More information about the Operators mailing list