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

[Alessandro Vesely <[e-mail]>]

On 02/Feb/12 19:16, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>> 
>>> 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.

I don't think we are at cross purposes, as we have more matching than
contrasting points.  Yet, at times we are unable to understand each
other --possibly my English doesn't help much.

Define "giving any thought".  Auto or manual?

Section 8.5 is about out-of-band arrangements.  The only sense I'm
able to make of it is that the signer has already set up an FBL with
the report generating domain.  If that's correct, it has to be said
more clearly.  BTW, the last phrase:

   data found in the DKIM signatures, which could have been
   fraudulently inserted.

is obsolete now that the data is checked in the DNS.

Section 8.6 is about run-time control of traffic.  We may solve the
problem or just mention it.  Let's see if anyone else is interested.
In any case, the mailbombing is limited by a max in/out ratio of 3 (if
one fails SPF and DKIM and gets a spam report for each message) so it
should be fine for sites like mine where that ratio is usually around
10~20.