Re: [Asrg] Final statement

[Matt Sergeant <[e-mail]>]

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 
______________________________________________________________________