Subject: Re: [marf] Comments about draft-ietf-marf-reporting-discovery

From: "J.D. Falk" <[email-masked]>
Date: Wed, 6 Apr 2011 17:10:21 -0700

On Mar 14, 2011, at 10:25 AM, Tanguy Ortolo wrote:

> I have just read the Internet draft about discovery of willingness to
> provide or receive ARF reports. Here are some comments about it.

Thanks, I appreciate the input.

> Section 5, §4:
>> In the case of a feedback generator, to inquire whether or not an ADMD
>> wishes to receive feedback reports, the DNS domain to which the
>> report should be sent is determined (using a mechanism at the
>> discretion of the generator)
> 
> The goal of this draft being to correct the lack of defined methods in
> [MARf-BASE] (cf. section 1, §1), I think it would be appropriate to
> define the method for determining the responsible domain name.

I'll adjust the text to specifically require using the DKIM d= string (unless anyone has an argument for not tying it to DKIM?)

> Section 5.2, §2:
>> gf the format of reports offered; […]
> 
> Feedback reports being an agreement between a producer and a consumer,
> it would be impossible to use if both require a different format (though
> there is currently only one such format defined). I suggest that the
> producer could offer several formats, making this tag a colon-separated
> list.  Maybe consumers could offer the choice between several formats
> too, but I think it would be less relevant, though I would not be able
> to argument it.

Right now ARF is the only format likely to be offered, but I wanted to leave it open for other formats that might be developed in the future.

> And finally, I think that this draft could cover the case where several
> entities under a same domain name would require separated reports. In
> fact, this would be the same use case as DKIM selectors: example.net has
> two entities, admin and marketing, that operate separately and would
> like to receive feedback separately. The use of such reporting selectors
> could be defined for authentication methods that allow such selectors
> (currently only DKIM, I think), and implemented in the exact same way as
> DKIM selectors: in my example, that would lead to the DNS records
> admin._report.example.net and marketing._report.example.net.

Today the reports are almost invariably routed by the last-hop IP address, so this kind of differentiation of mailstreams hasn't been possible.

With DKIM, I'd expect to see different subdomains in the d= string rather than selectors, because selectors are intended for key rotation.  Mailstreams could be identified by the i= string, but...well, there's a big long thread on ietf-dkim about that right now.  In any case, I think d= will emerge (again) as the best identifier to use.

On Mar 20, 2011, at 8:05 AM, Alessandro Vesely wrote:

> However, section 7 seems to be overly restrictive.  A generator should be
> allowed to send a report to a different domain in some circumstances.  For
> example, a RIR might provide a generic reporting address for (some of) its
> addresses.

Sure, but that'd be separate from this discovery mechanism.

> The problem here is that different formats may provide for different report
> types.  I think we should order them from most generic to most specialized,
> and urge specialized consumers to also accept generic formats, for the sake
> of interoperability.  For example, an operator may find it convenient to send
> ARF reports, but, if they happen to be involved in IODEF exchanged for
> specific cases, they may want to discover the possibility to send that kind
> of report to a given consumer.

I'd love to get some help on this from someone more experienced with IODEF.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions