Subject: Re: [marf] reporting-discovery

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 01 Feb 2011 15:22:25 -0500

In <[email-masked]>, on
01/31/2011
   at 03:08 PM, "J.D. Falk" <[email-masked]> said:

>There's no reason it couldn't be used to report drop boxes,

As I recall, the issue was timing; the priority was getting the RFC
out the door for the sending network.

>though that's not a common practice today.

There's at least one provider that will only accept abuse reports in
ARF. That makes it difficult to report drop boxes.

>That's part of what the Reported-URI field was intended for.

However, the current wording of 1.1.  Purpose seems to rule out that
use

   o  email abuse originating from their networks;

   o  potential issues with the perceived quality of outbound mail,
      such as email service providers sending mail that attracts
      the attention of automated abuse detection systems.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 01 Feb 2011 15:22:25 -0500

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 02 Feb 2011 09:55:40 +0100

On 01/Feb/11 21:22, Shmuel (Seymour J.) Metz wrote:
>> [report drop boxes is] part of what the Reported-URI field was intended for.
> 

While the first bullet restricts reported messages to those
originating from the networks of a report's recipients, the only hint
toward such interpretation in the second bullet lays in the term
"outbound".

Section 2 of draft-ietf-marf-reporting-discovery repeats the same
phrases, and explains how reporting discovery is going to support that
purpose.  In case the wording in MARF-BASE is misleading, the new I-D
should clarify it.

For a nit, the I-D "addresses *three* primary use cases", but then
only two of them are bulleted.

For a core issue, it is a fact that some abuse teams only want reports
that concern mail originating from theirs.  Thus, we should ask
ourselves how prominent the origin of the reported message has to be
in reporting discovery.  Is it more important than *feedback type*?

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 02 Feb 2011 12:12:56 -0500

In <[email-masked]>, on 02/02/2011
   at 09:55 AM, Alessandro Vesely <[email-masked]> said:

>For a core issue, it is a fact that some abuse teams only want
>reports that concern mail originating from theirs. 

Suggesting that the discovery mechanism should have fine enough
granularity to allow a consumer to indicate which types of abuse
reports they want to receive in ARF format.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 2 Feb 2011 10:40:07 -0800

> in reporting discovery.  Is it more important than *feedback type*?

The identifiers used in reporting-discovery to identify feedback consumers may be too limited to make dropbox reporting easier than it is currently.  A message referring to a dropbox at yahoo.com won't (in most cases) be signed by yahoo.com, so you can't be certain of finding the appropriate advertisement via the DKIM d= domain.  It also won't (in most cases) have been sent by an MTA within the Yahoo! ADMD, so you can't find it via the PTR record of the border MTA.

It's /possible/ that the dropbox address's DNS domain (RHS) will be the same as that DNS domain's d= value, but that's not certain.

Dropboxes and other identifiers found solely within the message may be out of scope for reporting-discovery, unless we can think up a way to make it work.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 03 Feb 2011 18:59:24 +0100

On 02/Feb/11 19:40, J.D. Falk wrote:
> Dropboxes and other identifiers found solely within the message may
> be out of scope for reporting-discovery, unless we can think up a
> way to make it work.

Currently a record can say

   _report.example.com. IN TXT  ( "r=[email-masked]; rf=ARF; "
       "rt=abuse,fraud,virus; re=[email-masked];" )

We could add a tag, say, ro= (o for *origin* of the reported message),
and possibly go= for generators.  The values would indicate classes of
reported messages that are relevant for reporting.  For example,
classes could be defined like so:

  *a* reported message is *authenticated* by DKIM, SPF, or other
      mechanism that proves it originated from the relevant ADMD.
  *b* reported message is *believed* to originate within the relevant
      ADMD, as determined by inspecting Received header fields, rDNS,
      block assignments, and similar ways.
  *c* reported message is *crap* with the Return-Path and/or From
      header fields abusively referencing the relevant ADMD.
      (Hey, this is just an example!)
  *d* reported message has a *dropbox* in its text, or in the From or
      Reply-To header fields, referencing a seemingly existing
      address in the relevant ADMD.

For report consumers, the relevant ADMD is the target domain.  Thus, by

   _report.example.com. IN TXT  ( "r=[email-masked]; rf=ARF; "
       "ro=ad; re=[email-masked];" )

example.com would state that they are interested in records about
messages that authentically originated from theirs, or that deploy
dropboxes related to them.

Note that the latter example omits rt=.  We could argue that frauds
are probably related with dropboxes, or that reporting abuse is only
interesting for messages originating from the relevant ADMD.
However, imposing more semantics on the feedback-type doesn't seem to
be viable.  Hence we add a new classification that is suitable for
reporting discovery.  Would we still need feedback-type, then?  If
not, then the new classification would also solve the problem of
adding other rf=, like IODEF, whose types are different from those of ARF.