Claus v. Wolfhausen wrote:
Really technical important things got a "SHOULD" OR "RECOMMENDED"
while a the content of a policy (if there is a payment option or
not) got a "MUST NOT" in BCP 07.
Examples:
2.1 Transparency - It is a joke that there is a SHOULD instead of MUST.
2.1.1 Listing criterias SHOULD be easy available (instead of MUST)
These two were a tough call. I'd prefer MUST here too, but if you look
at the CBL they don't list *exactly* why the listing is there, they
simply say " lists IPs exhibiting characteristics which are specific to
open proxies of various sorts (HTTP, socks, AnalogX, wingate etc) and
dedicated Spam BOTs which have been abused to send spam, worms/viruses
that do their own direct mail transmission, or some types of
trojan-horse or "stealth" spamware, dictionary mail harvesters etc."
which is fair enough but may make them fall foul of the clause if it
were a MUST.
It's easier for some other DNSBLs where the criteria is simply "the IP
emailed our spamtrap".
2.2.1 Listings SHOULD be temporary (instead of MUST)
I see no reason that has to be a MUST. Some DNSBLs are informational
only, and as such there's no reason for an expiration. This has been
discussed here a lot in the archives.
3.3 DNSBLs SHOULD have operational fals (Instead of MUST)
There are reasons for this not being a MUST, again associated with
informational lists.
According to your BCP 07 an DNSBL-Operator is not required to publish
a policy at all , but BCP 07 believes it can judge if there is a
payment option in that policy. That is ridiculous.
It's not entirely ridiculous. I stand by the fact that charging for
removal is a worse policy than not having listing criteria published in
certain cases.
That means your BCP 07 is at best a joke and nothing that a
professional person will ever take serious.
All people that have voted for it have clearly given proof that they
are really blind or incompetent and their only reasoning to vote for
this BCP was to harass the UCEPROTECT-Network.
You're right, the whole thing was a gag aimed at poking fun at
UCEPROTECT </sarcasm>.
Seriously, tone down the rhetoric. Perhaps if you had solid arguments
for needing to charge for removals you would have been taken seriously.
But when every other blocklist manages to do free removals without any
problems you need to come up with some pretty damn solid arguments.
Your argument for why the clause shouldn't be there is simply that users
need a good spanking so that they don't get infected again. In my
experience this is acheivable through other means, which perhaps you
haven't considered. The one I used is that sure they can delist if they
haven't fixed the problem (but only once per TIME_PERIOD), then
relisting happens again because they hit the trap, and if the sender
keeps asking to be delisted they get told not until they fix the
problem. Sort of a 3 strikes and they're out policy [*]. There's nothing
in the BCP which prohibits that, and it's MUCH more friendly than the
policy of charging. In my experience the implementation of such a policy
did not hamper the effectiveness of the blocklist whatsoever.
Matt.
[*] 3 because #1 is done on the web site via CGI, #2 is done via email
request, then #3 they are out until they fix the problem.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
_____________________________________________________________________________________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg