<div dir="ltr"><div><div><div><div><div><div><div>Hi Jamie<br></div>True, but I just took a look at last 7 days data. For my site, new valid users 2 , and junk users are around 10. So in this rate if it goes, i will have more junk users than valid users. <br>
<br></div>The only option that comes to my mind is, re-use the junk user space for new users (again it may be valid or junk user). But in the process always we will have less junk users.<br><br></div>However I will do once I finish number of pending tasks.<br>
<br></div>Best Regards<br></div>Kamal<br></div>Net Cloud Systems<br></div>Bangalore-08<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 21, 2013 at 8:19 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">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Why go through all that? You&#39;re
      reinventing the wheel. Just block the unwanted users and then a
      new user can not be created with the same name. <br>
      <br>
      Also consider that a vast majority of spammers use a program to
      randomly generate a user name. That means that their are huge odds
      of them never using the same name twice for registration.<div class="im"><br>
      <pre cols="72">Jamie Holly
<a href="http://www.intoxination.net" target="_blank">http://www.intoxination.net</a> 
<a href="http://www.hollyit.net" target="_blank">http://www.hollyit.net</a></pre></div><div><div class="h5">
      On 6/21/2013 10:15 AM, Kamal Palei wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      <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>
        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><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>
              <div>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" target="_blank">fred@example.net</a>
                or <a href="mailto:joe@domain.test" target="_blank">joe@domain.test</a> (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>
              <div>[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
    </blockquote>
    <br>
  </div></div></div>

<br>--<br>
[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br></blockquote></div><br></div>