<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi James,<br>
<br>
starting the discussion was my main intent, as we were losing
ourselves in potentialities and small-small...<br>
<br>
<blockquote cite="mid:D0169266.6F32F%25jbladel@godaddy.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Thanks to Volker for getting this conversation started. I
also share the belief that we should define a system that
assures reporters their claims will be relayed by P/P services.
However, I disagree on some key points raised by Volker and
others.</div>
</blockquote>
No worries ;-)<br>
<blockquote cite="mid:D0169266.6F32F%25jbladel@godaddy.com"
type="cite">
<div><br>
</div>
<div>First, I do not believe there should be any attempt to filter
submitted reports based on content. That approach does not
scale, and simply results in an arms race where would-be
spammers attempt to circumvent the filters. Also, I do not
believe P/P services should relay —all—reports. This treats the
P/P email point of contact as an email “alias” for the
beneficial user’s real address, and completely defeats the
purpose of the service (most of our P/P customers engage the
service to avoid being spammed). <br>
</div>
</blockquote>
I agree in as much as there should not be a requirement to attempt
to filter by content, however it should be an option for a
value-added service. So for example while a basic service might
forward everything but obvious spam, a premium service might screen
all communications. I would suggest that content filtering should be
an allowed option, but not an obligation. <br>
<blockquote cite="mid:D0169266.6F32F%25jbladel@godaddy.com"
type="cite">
<div>I favor an approach that is modeled after ICANN’s Invalid
WHOIS Reporting System, and one that many Registrars have
implemented to guard against WHOIS harvesting – an access
whitelist. Speaking generally, such a system would require
reporters to identify themselves when submitting a claim for
relay. Is reporter should also have to designate the email
address from which relay claims will originate, and the service
provider agrees to honor relay request from that Address without
discriminating on its content. The P/P service provider can
then monitor the use of the relay system by each reporter, and
suspend or terminate access for any reporter that is found to be
abusing the system. <br>
</div>
</blockquote>
I like this, although this would require that all services cooperate
in maintaining such a list or would have to relegate this to a third
party such as ICANN. <br>
<blockquote cite="mid:D0169266.6F32F%25jbladel@godaddy.com"
type="cite">
<div>If this sounds familiar, it is blatantly copied from the
EWG's proposed RDS concept. I think this idea has merit, and
regardless of what happens to the rest of the EWG's
recommendations, we should consider opportunities to implement
this proposal in existing contexts.</div>
</blockquote>
In many ways, RDS as proposed would make privacy services less
needed anyway as data could be hidden as a basic setting.<br>
<br>
Best,<br>
<br>
Volker<br>
<br>
</body>
</html>