Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Alessandro Vesely
> Sent: Thursday, February 02, 2012 4:16 AM
> To: [e-mail]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was-07
> 
> > I don't agree.  The I-D is meant to present the mechanisms for
> > requesting and providing these reports.  That is, "If you're going to
> > do this, here's how we think you should go about it."  There are some
> > obvious concerns with doing so across-the-board without any checking
> > or thought to it, though one certainly could do that.
> 
> What's that "could"?!  There's nothing I can conceivably do besides
> setting the RR properly.  If that is not enough for getting reports
> from whoever will happen to get a broken signature, then this I-D is
> completely useless --I can well receive occasional failure notices from
> friends based on authfailure-report only.

I think we're talking past each other here.  What this draft presents is a method that amounts to a two-way handshake between someone that wants reports about DKIM failures and someone willing to generate them.  You need to consider both sides of that equation.  For report generators in particular, simply turning this on without giving any thought to the potential for creating a mail storm is possibly a bad idea, which means we should provide appropriate cautions.  For senders/signers, you need to be aware that requesting reports might mean you get (legitimately) mailbombed.  That's what Sections 8.5 and 8.6 try to point out.

> Differently from abuse reports, authentication failures may affect
> personal messages and confidential content.  Concern over divulging
> that is due.  If I were to report to unknown people, I would probably
> want to redact most header fields and omit the body.

But that's a risk in any ARF context, isn't it?  I don't see why it's necessary to call it out here (or, presumably, in spf-reporting).  It's called out appropriately in the authfailure-report draft (Section 3.1 at least), which this one normatively references.

> >> This I-D is not specifying blind-to- witting transitions, and I'm not
> >> suggesting it should, but maybe it can still suggest some details of
> >> such activity.
> >
> > I think to do so we would wander into the realm of speculation, not
> > specification.
> 
> Let me describe a possible case, just to make sure we're talking about
> the same thing:
> 
> Alice writes to Bob, DKIM-Signature breaks, ISP-B (Bob's ISP) start
> reporting to ISP-A.  ISP-A receive the first reports, check that they
> are good and confirm, possibly on http://postmaster.ISP-
> B.example/acknowledge?key=ISP-A_beenhere, that they would like to
> continue receiving them.  That doesn't lower the amount of redaction
> applied to reports.  Yet, ISP-A can collect reports and form a
> statistic picture of how their configuration goes.
>  Useful work already, isn't it?

Sure, but I think if you take the DKIM-specific aspect out, you're talking about a generic feedback loop scenario.  And that means it's more appropriate for the applicability statement draft.

> > I don't think that's a good idea for something that's asking for
> > Proposed Standard status as a protocol document.
> 
> The idea is just to note that there are data items about ISP-A, such as
> acknowledgment, contacts, responsiveness, and involvement, that is
> worth being stored on a per-domain database.  We don't need to say that
> such data may turn out to be useful for looking into spam
> (reporting) issues, as that is indeed speculation.

But that isn't specific to DKIM reporting, so I don't think that belongs here.

> Are you saying the AS is the right place for both flow control and loop
> avoidance?

Yes.  That draft is now in WGLC, so if you want to make a pitch to add text to that document, now's the time.

> What do everybody else think?

That's a fine question.  I suggest summarizing the proposed change in another thread.

> > I think if the advice that's been added about observing the behavior
> > of the report recipient as input to a throttling mechanism is actually
> > impractical, we should remove it rather than expanding on it and
> > complicating the document further.  We risk confusing the reader.
> 
> Hm...  I don't think that a non-empty envelope sender may cause
> reporting loops, as reporting does not actually use it.  Hence, we
> could use it for flow control.

Actually anything that isn't the empty envelope sender could cause a forwarding loop, modulo normative guidance to the contrary.  Section 6 covers this.

> For some unsorted details, we may recommend 552 after RCPT for
> momentarily stop reporting, but had better not rely on it.  Rather, I
> propose we encourage getting acknowledgments and recording them along
> with per-domain reporting history.  Report generators should use VERP,
> and suspend reporting to rejecting domains for an amount of time
> inversely proportional to the confidence, e.g.:
> 
>   0.5T      for an acknowledged domain,
>   T         for a first-time first-failure,
>   2T,
>   4T,
>   ... ,
>   one year  for dorks.
> 
> where T is the TTL of the relevant _report's RR if retrieved with the
> AA flag, or some other time constant either agreed with the domain or
> set by default.

And you think this would improve Section 8.6 rather than complicating it?  Personally, I'm satisfied that the last paragraph of what we have in that section is adequate to introduce the idea.  Developing and recommending a detailed tracking system design seems like overkill here.  If someone wants to do such a thing, it would certainly be valid, but I think suggesting that such a thing might be necessary could become a barrier to adoption.

-MSK