Subject: [marf] draft-jdfalk-marf-reporting-discovery

From: "J.D. Falk" <[email-masked]>
Date: Tue, 11 May 2010 14:31:56 -0600

Fellow MARFarians,

I've written a draft titled "Advertising and Discovering Willingness to Provide or Receive ARF Reports," which uses a DNS TXT record inspired by (but necessarily separate from) the extensions to the DKIM record proposed in draft-ietf-marf-dkim-reporting.

There are three types of advertisements: ARF generators offering feedback, ARF consumers requesting feedback, and mailbox providers who wish to collect complaints from their end users.  (I'm not certain if this latter should stay in this document, or be split into another.)

It needs a lot of work, but I wanted to seek your input before continuing.

http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-00

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 11 May 2010 16:43:36 -0600

> http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-00

I just noticed that xml2rfc lost my hangtags, with the result that section 5 looks far less complete than it actually is.  Oops.

You can find the XML (which is relatively human-readable) at http://disgruntled.net/~jdfalk/draft-jdfalk-marf-reporting-discovery-00.xml.txt -- and if anyone can help me figure out how that got lost, it'd be much appreciated.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 11 May 2010 19:28:01 -0400

Thanks.

Is there a current demand for this in the ISP community? My impression
was is that ISPs negotiate private arrangements for feedback loops and
generally do not advertise such addresses.

Yakov

On Tue, May 11, 2010 at 4:31 PM, J.D. Falk
<[email-masked]> wrote:
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf
>

---

From: John Levine <[email-masked]>
Date: 12 May 2010 01:33:32 -0000

>It needs a lot of work, but I wanted to seek your input before continuing.

I would suggest backing up a little bit and clarifying what problem(s)
this is supposed to solve.  I can see several possibilities:

A. Automated discovery of reporting path for a mail service's own users

B. Automated discovery of reporting path for a signing (or otherwise
   responsible) domain, either to send reports or to negotiate an FBL.

C. Automated updates to reporting path for negotiated FBLs.

D. We'll send reports under some conditions to some people.

E. Various hints to humans about how to set stuff up.

I think the ASRG argument established that there's some depand for A,
although little agreement about much else, including for something
like this, what domain a user would use to do the lookup since there
is nothing in a normal POP, IMAP, or SMTP 

For B, there's probably some demand, since people use abuse.net, but there
is at least as much demand to publish reporting addresses for IP ranges
and ASNs.  If I were the IESG (which, lord knows, I'm not), I'd want
something that addressed all three, which is a huge can of worms both
politically, and just technically identifying a place in the DNS to put
the info which is credibly under the control of the right people and doesn't
require adding a million new records for a million IP addresses.

For C, it seems harmless, but I don't see much demand for it.

For D, I don't understand the point, unless it's supposed to lead to a
handshake of some sort to establish an FBL which seems fraught with
security and abuse issues.

For E, there seems little point in publishing anything beyond a single
pointer to a web page, since people can read web pages at least as
well as they can decode code letters.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 May 2010 20:14:35 -0700

> http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-00
 From a security aspect, feedback discovery should depend upon 
verifiable information confirming a relationship between outbound and 
inbound servers.  Otherwise, an unprotected discovery mechanism seems 
destine to become a method for abuse.  The relationship could be 
cryptographically based, or use something as simple as having EHLO/HELO 
confirm IP addresses of outbound servers, with inbound servers being 
within the same domain.  Feedback might represent paths not part of DSN.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 May 2010 14:25:20 +0200

> A. Automated discovery of reporting path for a mail service's own users

It has been worked out in the ASRG. I'd suggest splitting the I-D, and 
stress this by splitting this thread :-)

> I think the ASRG argument established that there's some demand for A,

Let me invite anyone who hasn't done so already to review 
http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs for this 
subject. That page doesn't point out clearly what are the good 
choices, just the pros and cons of each option discussed. IMHO: Using 
A-R (the "Per message approach") is the best method; "Via IMAP" is 
cuter but also more difficult and more restricted.

JavaScript programming is not my forté, but I tried and examine A-R 
fields of my TB inbox. The one thing I've been able to do is to match 
the authserv-id with the "by" tag of the next "Received" line. If such 
token also matches the very first "Received" (which is the same one, 
in case the MX is the final server) I'd automatically trust it, and 
enable the button. In all other cases, I'd require specific 
configuration from the user/installer. Is that correct or do I miss 
something?

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 May 2010 14:27:06 +0200

>     responsible) domain, either to send reports or to negotiate an FBL.

This is the next step, after A :-)

> require adding a million new records for a million IP addresses.

There is a known overlapping area between MARF and IODEF/RID. I've 
seen they are active, and their RID transport document is currently in 
LC; however, I don't know what lists they use, therefore I take the 
freedom to CC to that doc's authors' addresses.

Requirements are probably very different. Can an extensible TXT 
resource record format be arranged so as to serve most purposes 
correctly, possibly without requiring a too huge discussion?

The issue of whether to negotiate an FBL or just send reports belongs 
to MARF. But I'd be curious to know how network operators establish 
trust among one another.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 May 2010 09:59:14 -0400

> I just noticed that xml2rfc lost my hangtags, with the result that section
> 5 looks far less complete than it actually is.  Oops.

I've corrected JD's XML, and I'll send him the correction separately.

Barry

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 May 2010 14:58:05 -0600

> generally do not advertise such addresses.

Most are fairly public that they have feedback loops, and then they use their own criteria (which varies, but is generally along the lines of "don't be a spammer") to decide who gets in.  That's why I included the "gp=r" policy, whereby a Feedback Generator can specify that reports will be provided only after the prospective consumer has completed an application process found at URI defined by the "gu=" tag.

I expect that that'll be the most common configuration at first.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 12 May 2010 14:58:12 -0600

On May 12, 2010, at 6:25 AM, Alessandro Vesely wrote:

> It has been worked out in the ASRG. I'd suggest splitting the I-D, and stress this by splitting this thread :-)

And I'm entirely open to this idea -- possibly even in favor -- but was hoping for more WG discussion about it before splitting off a new draft.