Hi,
> IMHO, it is not so much being Americans or whatever, as being versed
> on legal points of view.
It's the US legal system vs. the European legal system. Since Europe has
an opt-in system and the US have an opt-out system in the US the FBL
generation is a necessary way to support US laws.
>> Some things that are mentioned are not possible under European
>> Jurisdiction. For example providing Feedbackloops is especially in
>> Germany a very critical task.
>> Is it? I guess in Italy we have more or less the same European
> directives. So long as the user is clearly informed about what data
> is being sent to who, and grants her/his consent to that, it should be
> legal to do FBLs. Yet, IANAL.
Exactly. Is there an FBL in Italy so far? I don't think so. The hoops
ISPs have to jump through and the burden they have to put on end-users
are way to high. That is the problem. It's not so much about the
possibility and more about usability.
> The best thing, IMHO, would be do gather users' consent on the first
> time they hit a "This is Spam" button. At the same time, give them
> the option to redact their email address in the header. (See
>http://tools.ietf.org/html/rfc6590 ).
That is not the problem at all. The problem is, that a user clicking on
the spam button has every time he clicks on the spam button acknowledge
that his mail is being sent to a third party. And in addition to that he
has explicitly acknowledge the receiver. Think about 50 spam messages
per day. That would mean that the a user has to click 50 times the spam
button, than 50 times "Yes I want to report this message!" and than 50
times "I'm okay that this message will be sent to X!"
From a usability point this is ridiculous and exactly that is one of
the main problems. And in addition to that ISPs would like to provide
FBLs, but they do not want to annoy customers with this harassment,
because users would not do it and as soon as there will be a way around
it they will not do it because they are afraid it's getting complicated
again.
We first need to find a simple for end users secure way to report that
does not destroy the usability and the trust and than come up with
solutions.
>> So rfc 6650 is good but unfortunately does not fit all use and legal
>> cases.
>> We need to clear up this issue. Googling for that I find that ETIS,
> which is based in Europe, has an "Anti SPAM Co-operation Group" that
> "is also working on an anti-spam feedback loop project." (Quotes from
>http://etis.org/groups/anti-spam-task-force ). I'd guess you know
> them; they have a meeting on next Oktoberfest... Would they cover
> those legal concerns?
Yes ETIS is exactly working on these legal issues, but imho have not
found a way around it. The project that is ongoing there has nothing to
do with user feedback. It's about spamtrap data provided by the ETIS
members. I'll be probably at the next ETIS meeting in Munich and
hopefully can help to take some next steps.
> A recurring objection in the acm-tf was that RIPE handles just a
> region, and therefore we'd need anti-abuse practices to be specified
> by some global body such as the IETF. Now we have it. We should use
> it as we use SMTP. And the fact that our law is better than theirs
> should be an aid, not a hindrance!
We have an IETF specification, but this does not stand over the law. We
can specify as much as we want, if this is not a within the legal
framework we can't use it. And that is exactly what I mean, the rfc you
mention does not take in account that European legal system is opt-in
and not opt-out. Same on the different direction. Most ESPs in the US
don't care about opt-ins which is legally recommended in Europe.
This is a basic difference between the US and Europe which can not be
ironed onto the same level. The outcome must be the same, but the way to
this will be different.
Thanks,
Tobias