<div dir="ltr"><div><div><div>I am thinking of below solution. <br><br>For my site, it is easy for us to find who are unwanted users using some mechanism. I am planning to write a custom module, that will allow administrator to list down unwanted users and these users references I will keep in a separate table , lets call it <b>table-a</b>. When a new user registers, I will check table-a, and if any entry found, I will use that entry&#39;s UID, for new user. Thereby over the time, anytime you see the unwanted users in my site will be less.<br>
<br></div>Best Regards<br></div>Kamal<br></div><div></div>Net Cloud Systems, Bangalore-08<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 21, 2013 at 7:30 PM, Jamie Holly <span dir="ltr">&lt;<a href="mailto:hovercrafter@earthlink.net" target="_blank">hovercrafter@earthlink.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The goal is to make it more difficult for people to register unwanted<br>
accounts. You aren&#39;t going to stop it completely. Email verification is<br>
just another hoop for them to jump through, one that is also accepted by<br>
a vast majority of regular users. It should always be used.<br>
<br>
Something I did for a client last year was a custom module. It did a few<br>
things. First we could set the number of registrations per IP in a given<br>
time frame. After that the account requires admin approval. It also<br>
recorded all the request headers so that I could look for a pattern,<br>
which I ended up finding. Once I was able to isolate that, I blocked<br>
that pattern from registering, which took a client&#39;s site from a few<br>
hundred spam registrations per day, down to one or two per week. Per my<br>
agreement with that client, I can&#39;t give out that pattern, but doing<br>
something similar on any site wouldn&#39;t be that complex.<br>
<br>
A common practice now is for companies to hire people to generate these<br>
accounts. They then use the accounts to spam your site. After that a<br>
company contacts you regarding the spam on your site, offering to &quot;clean<br>
it up&quot; and help your seo rankings. Very, very dirty indeed.<br>
<br>
The interesting part of that is what we found out. The registrations<br>
were happening from IP addresses all around the globe, yet the actual<br>
spam postings were mostly from U.S. IP addresses and over 70% were from<br>
hosting companies that offer VPS. We were successful in getting one<br>
hosting company to shut down an account, but most just ignore it.<br>
<br>
The whole morale of the story is vigilance. Things like CAPTCHA, email<br>
verification and keeping bad user accounts to prevent reuse of bad names<br>
and emails all give an extra layer of security (albeit not all that<br>
much). Or do you believe in leaving the front door of your home standing<br>
wide open, when you aren&#39;t there?<br>
<div class="im HOEnZb"><br>
<br>
Jamie Holly<br>
<a href="http://www.intoxination.net" target="_blank">http://www.intoxination.net</a><br>
<a href="http://www.hollyit.net" target="_blank">http://www.hollyit.net</a><br>
<br>
</div><div class="HOEnZb"><div class="h5">On 6/21/2013 1:56 AM, John Summerfield wrote:<br>
&gt; On 12/06/2013 10:37 PM, Jamie Holly wrote:<br>
&gt; &gt; +1 to that! Also, they can&#39;t reuse the email. Make it harder on them,<br>
&gt; &gt; not easier.<br>
&gt;<br>
&gt; Reread gmail&#39;s rules about its email addresses. One can generate any<br>
&gt; number of alternatives for any one email address. Besides, unless one<br>
&gt; requires email addresses to be verified during registration, users can<br>
&gt; use anything at all, even <a href="mailto:fred@example.net">fred@example.net</a> or joe@domain.test (both of<br>
&gt; which _can_ be valid).<br>
&gt;<br>
&gt; Email hosts often allow +arbitrarySuffix to the localpart of email<br>
&gt; addresses, but the &quot;+&quot; can be another arbitrary character, I&#39;ve seen<br>
&gt; hyphens used.<br>
&gt;<br>
&gt; And then there are some domains where everything is delivered, if not to<br>
&gt; a specific addressee then to a default address and that too is configurable.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
</div></div><div class="HOEnZb"><div class="h5">[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br>
</div></div></blockquote></div><br></div>