Subject: [Asrg] Final statement

From: "Claus v. Wolfhausen" <[email-masked]>
Date: Tue, 1 Mar 2011 17:34:05 +0100 (CET)

This is my last statement to this group before unsubscribing.

I came here after I have found that BCP 07 to do a serious discussion with
you, and you would have had the chance to convince me of your positions, if
you would have had good arguments. 
Unfortunateley, an objectice discussion did not happen, because you (and
that really means as good as anyone here) has prejudices against me, and so
I had to hear things as:
"Racket-Protection-Company"  even in the first answer I got from this group.

Really nice ... and very professional ....

I have to admitt that my answer to Mr. Lindford of SPAMHAUS was very ironic
instead of being neutral and objective, but that does not change the facts I
have given the audience about the SPAMHAUS-DNSBLs.

Unfortunateley I told in a meeting about that BCP and it seems some very
stupid workers got scared to lose their job.
They tried a very stupid action and they reached the opposite of what they
wanted to achieve:  They got fired by the CEO today in the morning.

Anyway those idiots made me look like an asshole and you were happy to see
me as an asshole instead of turning on the brain and trying to read between
the lines.
Chris and Matt do both know the full story what happend and it doesn't
matter to all others here. It doesn't belong to a public lists.

Since this group is unable to discuss BCP 07 without prejudices against me
and the UCEPROTECT-Network, I would simply waste my time, if I would stay in
this group any longer.

If there is at least *ONE* here that can think objective and logic, then
think about this:

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)
2.2.1 Listings SHOULD be temporary (instead of MUST)
3.3 DNSBLs SHOULD have operational fals  (Instead of MUST)

That list could be continued. Those examples I have given here are a clear
MUST for every responsible DNSBL-Operator.

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. 

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.

That means the UCEPROTECT-Network will gladfully ignore this group and it's
decisions or votings from now.

Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 01 Mar 2011 12:57:30 -0500

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:

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 
______________________________________________________________________