Re: [marf] draft-jdfalk-marf-as

["J.D. Falk" <[e-mail]>]

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