Dear Jose-Marcio,
You wrote:
The same way as all you've said is only a personal opinion coming from a
company who is part of the "racket protection" community.
I strongly recommend that you avoid insulting words as "company who is part
of the racket protection community", if you want to be taken serious by me.
Sure my posting also just reflects an opinion, but it is an opinion that is
backed up by UCEPROTECT's broad userbase.
There is IMHO no reason for a discussion about how DNSBL's handle delistings
as long as that is explicit stated into the DNSBL's policy.
We are known to have the most transparent policies and our users exactly
know what they are doing and why they are doing it.
If our users would not agree to our policies, then ourlists would simply not
be used and then we would not have this discussion.
The standard procedure at UCEPROTECT-Blocklists is that a listing
automatically expires free of charge 7 days after we have seen the last
abusive action originating from a listed IP.
Different to that, the optional immediate expedited express delisting
requires manual work to be done, which is not offered free of charge by us.
In our jurisdication one is free to charge for services offered, so it is
neither racketeering nor extortion if we are charging listees for freely
chosen optional services.
No one is forcing listees to order an expedited express delisting. They
could simply fix their problem and wait for the free automatic expiration.
Just to counter your arguments, there are many alternative ways to "educate
people" without "racketing them" : you can make harder and harder to be
whitelisted people being frequently blacklisted. You could accept to remove
immediately people being blacklisted for the first time or people who wasn't
blacklisted in the last one or two year period...
You seem to defend people that were too negligent / incompetent / lazy /
whatever to secure their systems in first place.
Those that get listed in a DNSBL missed to do so and therefore they are
guilty for supporting spammers. It is their own fault, even if most of them
blame others afterwards.
I don't know of any jurisdiction where first-time offenders are explicit
not subject to prosecution" by the law.
So why should a DNSBL handle first-time offenders like they would be
innocent people?
Anyway you made a point: It might be a good idea if we would punish
second-time offenders harder than first-time offenders.
I would have no problem to increase listing period by a factor 100 for
second-time offenders, but this was probably not what you wanted me to do
:-)
Otheway, your phrase : "That is a really important point, which is often not
seen by people which had never run a public DNSBL." and mainly "often not
seen by people which had never run a public DNSBL.". Well, you surely missed
a point as you surely don't know who are all people in this list. I consider
this a sign of useless arrogance against all of us.
It is not necessary to know all the people in this list because logic told
me that there can't be many DNSBL-Operators here or they are really inhonest
Otherwise they would have seen and mentioned also a big "Conflict of
interests" at "commercial DNSBLs" in the "draft-irtf-asrg-bcp-blacklists-07
:
Commercial DNSBLs which charge for usage have real problems to list their
paying customers in situations where a big ISP which is customer of their
commercial DNSBL" is also a big spammer hoster.
It was really interesting for me to see that this really big "Conflict of
interests" was not also published in the draft.
Either way, discussion about this draft took a very long time. You could be
there while this was discussed. Where were you ? You are free and welcome to
participate on all discussions in this list.
I found the January changes to the draft yesterday as our search algorithm
found an article from January 2011 on the listserver which mentioned
UCEPROTECT.
Earlier versions of this draft (V6 and older) were known to me and they didn
t contain such personal biased opinions like the new version.
I did therfore not see any reason to participate in this group earlier.
Drafts of "best practices" and also eventually resulting RFC's MUST ALWAYS
contain pure technical information only and if opinions are mentioned in
them, then they MUST BE neutral.
For this Draft this means it MUST either mention "Conflicts of interests"
for any kind of DNSBLs or it MUST NOT mention any at all.
Regards
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg