I am not sure from a legal point of view, but from a technical one you
could set up a rsync repository to distribute a big text file - rsync is
quite efficient at updating incremental text files with few variations and
most updates appended at the bottom. this means that you do not have to
provide a rel-time service that eats bandwidth, CPU and may cripple user's
performance if it should go down or be very slow.
if the idea gets to be successfull, it would then be easy to create a pool
of servers with round-robin DNS to share the load of a possible DDoS.
after downloading the file, each user would use a small script to upload
it to a local database and the use - for example - MySQL dialplan
extensions to check each DID in real-time.
a cron job would then be used for periodic updates.
it should not be very complex to do.
just my $0.02.
l.
PS. about this topic, have you seen the current top slashdot story?
http://it.slashdot.org/it/06/06/07/1949258.shtml
In data Tue, 06 Jun 2006 18:04:42 +0200, Mike Lynchfield
<[EMAIL PROTECTED]> ha scritto:
no sure on the dns thing, but as far as did score , thats just it. a
score.
Example
ProviderID,DID,score[1 to 10],reason[varchar64],flag[cof,sof,bi,etc]
1000, 1231231234, 9,confirmed abuse,sof
would be suspicion of fraud 90% sure for did 1231231234
code : cof = confirmed fraud.
bi = billing isues.
etc.
so you could actualy pull results nightly via corn or anythign you like
and
scpecify filters.
pull.php?flag=all&minscore=3 etc
you would then get that list to your pbx box and apply it as you wish.
as in output:
providernickname,DID,avgscore,totalcountofcomplaints,etcetc
On 6/6/06, Tomer Horn <[EMAIL PROTECTED]> wrote:
I agree with Florian.
I would like to add that technically, it should be implemented either in
style of RBL using DNS and/or DUNDi - where the DUNDi will be used as a
blackhole. Just make sure that by design you'll be able to create
redundancy sites in different locations in case of DDoS or whatever. Be
prepared for that. You should allow, as you suggested, to download the
complete list by using the web/dns-axfr.
I think with that comes the subject of moral responsibility for the
list:
- Under what rules a DID goes into the list? Who is allowed to commit to
the list?
- What prevents from those who are running the list to list "safe" DIDs
and abuse
the list for whatever purposes.
- Maybe the entries should have a feature to enter both positive and
negative
votes/scores/comments for each listed DID?
Just my 2 cents.
Florian Overkamp wrote:
> Hi Mike,
>
> Mike Lynchfield wrote:
>> We create an API , or Web portal , that would accept input
>> (DID,Reason,Flag)
>> and serve a list.
>>
>> This list would be a SOF (Suspicion of fraud) list in either txt,xml
>> or both
>> for you to download.
>
>> How does it sound ? ..
>
> The basic idea makes a lot of sense, although I think there should
> also be some meta-data like:
> - what is the nature of the SOF, in text, for customer support
purposes
> - when was the number registered as SOF
> - optionally, how many complaints were made about the number ?
> - if there was an identifiable source, of the complaint or notice, who
> was it ?
>
> Our national regulator also publishes a list of numbers that have been
> seen in auto-diallers. Maybe other countries do the same ?
>
>
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz
--
Assum est, versa et manduca.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz
