Subject: Re: Silly way to waste bits, ongoing.
To: henry nelson <netb@irm.nara.kindai.ac.jp>
From: Richard Rauch <rkr@olib.org>
List: netbsd-users
Date: 11/14/2003 04:11:02
Re. http://mail-index.netbsd.org/netbsd-users/2003/11/14/0001.html

The format is explained in: http://www.olib.org/~rkr/netbsd/netbsdusers.html

Most of your other questions are at least partially addressed by that web-page
as well.

Perhaps you got pointed to the .db file without seeing the web-page somehow?
If you saw the web-page and don't feel at all enlightened by it, then I need
to improve the web-page, since I did anticipate and *try* to answer most of
those questions already.  (^&


Why not city and country?  Because that doesn't plot well on xglobe.  (^&
However, I could add city/country fields.  It would be easy to then massage
the database into a table as you request.


I've seen a huge increase in spam starting around August (maybe July?).
I suspect that someone is piping some of the mailing lists directly to some
spammers, because I've seen multiple spams come in right after posting to some
of the lists.  )^&  However, I've scaled up my defenses: I've been using
RBLs for a while and every day I skim the RBLed IP numbers into a local spammer
list.  Now, I'm turning the spammer list into IPF rules, so spammers don't
get a second chance.  I haven't been doing this for very long, so I haven't
yet decided how long to keep an IP number "jailed".  Most of the repeat offenders
are from a few servers.  (I've also written a script to look for /24 blocks
containing multiple spammers, but it seems that there aren't that many.  Most
are one-time deals then they move on to a totally different IP number.)

(Blocking RBLed IPs doesn't help avoid spam, but it avoids putting repeated stress
on the RBLs.  What pushed me over the edge was Sven/Swen hitting me hundreds of
times a day.  I have a whole section of repeat-offender and/or multiple-mail-host
"wormers"...  No need to consult the RBLs for hosts that can't control their worm
population.  That's a bit draconian, but I figure once the worms are under some
semblance of control, I can turn off the wormer section of IPF rules....but keep
the rules handy for the next Microsoft worm/virus attack, since the same users
will probably be using the same ISPs and practicing the same "pick it up off
the street and chew it" approach to programs sent to their computers.)

(ramble)

Sorry, off-topic.  (^&


Note that you have multiple options for the contact field.  I have chosen to
weather the spamming and keep my main address in the database.  Some others
do so as well.  Others prefer to create a special mailbox just for the database.
Some give a URL.  Others leave the contact field blank.  To repeat what
should be somewhere in the netbsdusers.html web-page:

 The contact field is essentially optional (it has to be there, but can be
 blank).  I prefer a valid email address because when/if I automate the
 database maintanence, I can have the maint. script email you to let you
 know that your entry is expiring (letting you renew just by confirming,
 or perhaps slightly editing the entry with updated info).  But because
 of the potential for spam, I recognize that not everyone wants to put that
 out.  If it is non-blank, then at a *minimum*, the field should be usable by
 a human to contact you.  (Blackhole email boxes and dead-end web-pages don't
 do anyone any good.  The field might as well be blank if you do that.)

 Blank is perfectly acceptable, though I encourage non-blank.

A primary purpose of the database is social, so I view contact information
as highly desirable.  Perhaps a standardized permutation of the address
can be done.  (Conventional wisdom is that spammers don't presently try to
undo such, so if there is a trick that can be disambiguated from a "plain"
address, that might be a good compromise.)


P.S.: The largest single site in the database is now more than 6.  (^&
But that's a unique case so far.  Everyone else is 6-or-fewer.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/