Final statement

[Claus v. Wolfhausen]

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

[Matt Sergeant]

Post by Claus v. Wolfhausen
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.
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".

Post by Claus v. Wolfhausen
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.

Post by Claus v. Wolfhausen
3.3 DNSBLs SHOULD have operational fals (Instead of MUST)

There are reasons for this not being a MUST, again associated with
informational lists.

Post by Claus v. Wolfhausen
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.

Post by Claus v. Wolfhausen
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
______________________________________________________________________

[David Nicol]

On Tue, Mar 1, 2011 at 10:34 AM, Claus v. Wolfhausen <

Post by Claus v. Wolfhausen
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"

I'm inspired to draft a BCP on BCP interpretation, which would include, but
not be limited to

"advice in BCP documents MUST NOT be misinterpreted as anything other than
opinion"

unfortunately the margins of this e-mail are too small ...