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

From: Alessandro Vesely <[email-masked]>
Date: Tue, 21 Jun 2011 14:09:22 +0200

On 15/May/11 18:27, J.D. Falk wrote:
> http://datatracker.ietf.org/doc/draft-jdfalk-marf-as/
> 
> I've already noticed a couple of minor things I need to correct,
> but I'll wait until there've been more comments before uploading
> another version.
> 
> What do y'all thank?

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.

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.

In section 3, I'd complement bullet (c) above with the suggestion that
a network provider who receives a report relative to an IP that they
gave to a mailbox provider, may forward that report to that provider's
abuse-mailbox, besides possibly doing their own trending.

Bullet (a) should also be cross-checked with WHOIS data, according to
the last paragraph of section C1 of CFBL BCP.  I'm not sure how.
Should abuse-mailbox's parent entries have a (repeatable) "domain"
attribute?  Domain WHOIS apparently don't have abuse-mailboxes.

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.  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.)

For a minor point, the possibility to redact reported messages is not
mentioned.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 23 Jun 2011 11:29:55 -0700

> clarity, I'd avoid calling "FBL" the unsolicited feedback generated

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.

> 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.

> 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

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

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

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2011 19:29:29 -0000

>I don't believe that there's sufficient implementation experience for
>an AS on non-solicited feedback, but I could be wrong.

I've been sending all of my abuse reports in ARF format for several
years.  I get the target addresses by a combination of looking up rDNS
in abuse.net and a largish local table of IP address ranges->domains.
It works reasonably well, at least as well as sending messages just
pasted in as text.  I used to get a lot of responses that said "we're
too scared and/or incompetent to open your attachment so send it
pasted in", but I haven't gotten any of those in a while.

My experience, which may or may not be typical of what other people
would find, is that sending reports in ARF format works fine, but
figuring out where to send them is a big challenge.  In particular,
getting the addresses from WHOIS works poorly both because of the iffy
quality of WHOIS data, and because WHOIS servers don't have the
capacity to handle high volume scraping.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 23 Jun 2011 12:51:07 -0700

> capacity to handle high volume scraping.

Since you're pretty much the only one, a "My Uncommon Practices" document could be useful.

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2011 20:27:34 -0000

>Since you're pretty much the only one, a "My Uncommon Practices"
 document could be useful.

Surely it should be a BCP. Since it is the only practice, by definition
it must be the best, and we know from the DKIM mailing list document
that whatever the C stands for, it's not common.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Fri, 24 Jun 2011 10:10:26 -0400

> that whatever the C stands for, it's not common.

Stop being snarky.

[Checks "from" line.]
Oh, wait... never mind.

Barry, as Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 24 Jun 2011 18:17:26 +0200

On 23/Jun/11 21:29, John Levine wrote:
> figuring out where to send them is a big challenge.

Yes.

> In particular, getting the addresses from WHOIS works poorly both
> because of the iffy quality of WHOIS data, and because WHOIS
> servers don't have the capacity to handle high volume scraping.

I don't agree.  WHOIS is trying and getting better.  IIRC, I found an
abuse POC in Arin saying something like they haven't been able to
verify such address for a while.  A rather non-formal statement that
suggests they do routinely check those email addresses.
https://www.arin.net/policy/nrpm.html#three6

The abuse contact is mandatory in Apnic
http://www.apnic.net/policy/proposals/prop-079

Ripe has an abuse finder tool, and a task force is discussing the
introduction of an abuse-c.
http://apps.db.ripe.net/search/abuse-finder.html
http://www.ripe.net/ripe/groups/tf/abuse-contact

I think a document is needed in order to state the "obvious" facts
that RIRs don't have the scope for discussing.  Since JD said it
cannot be part of the FBL AS, we'd probably better write a new one.

Is it possible to do so?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Jun 2011 10:42:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Friday, June 24, 2011 9:17 AM
> To: [email-masked]
> Subject: [marf] Abuse reporting, was draft-jdfalk-marf-as
> 

We'd have to recharter to do it.  For now if you want to get started, post it as an individual submission, and later we can consider rechartering to take it on.

Also, John pointed you at the WEIRDS pre-working-group list.  ICANN people approached me about starting that effort up, and right now they're exploring requirements.  There will probably be a bar BoF at the Quebec City conference next month followed by a lobby to create a working group later on once they get some momentum going.

It's true that any standard we produce won't compel a WHOIS provider to give out information it doesn't want to make available, but ICANN does have a little more stomping power on registrars than the IETF does.

-MSK