On Jun 21, 2011, at 5:09 AM, Alessandro Vesely wrote: > Would it be possible to expand treatment of non-FBL data? I heard > rumors about FBL being considered illegal in Europe. I'd bet it's > not, although EU law requires users' consent. At any rate, for > clarity, I'd avoid calling "FBL" the unsolicited feedback generated > without prior agreement.
This particular Applicability Statement is already restricted to solicited, end-user-triggered complaint feedback, so it does (in section 2, end of list item 1) point to the part of the MAAWG Complaint FBL BCP which discusses policy concerns. > Appendix C in the CFBL BCP has some preliminary work on non-FBL. A > topic that I think should be worked out a little bit more is the > choice between mailbox and access providers. In section 2 of ARF-AS I > would say that a report can alternatively be sent to one of > > a) a sender authenticated with DKIM or SPF, > b) the abuse-mailbox found in the RIR WHOIS database for the IP > address of the boundary relay, or > c) a network provider higher in such allocation hierarchy. That'd need to be a different Applicability Statement, describing non-solicited feedback. This one only describes solicited feedback (as described in the introduction and in section 2 list item 3, among other places.) I don't believe that there's sufficient implementation experience for an AS on non-solicited feedback, but I could be wrong. > The CFBL BCP says to ignore abuse-reports sent by mistake. Perhaps, > this is where the non-spam ARF type has to be used, sending back the > message to the author's mailbox provider so that they can undo any > learning they had imparted to their spam filtering systems. Seems technically feasible, but I've never heard of any implementation which works that way today. > Of > course, the non-spam report needs to be acknowledged by the user who > originally reported the message as spam. In case the user and the > remote provider don't agree, either one or both of them deserve being > categorized as bogus abuse-report sources. (As silly as this may > seem, it may turn out to be a good way to categorize gullible spammers > and unreliable users.) This is already fairly common, without needing to juggle externally-visible metadata. For example, Cloudmark is known to track reporter reputation within their spam reporting system. > For a minor point, the possibility to redact reported messages is not > mentioned. Good point, especially since we have a separate draft for that. Only question is whether draft-jdfalk-marf-redaction will advance any time soon; I sure would like to get the BCP and AS finished and published sooner. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
