> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Alessandro Vesely
> Sent: Tuesday, January 31, 2012 11:09 AM
> To: [email protected]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.txt
>
> Does this I-D update RFCs 5617 and 6376? I'm just trying to learn...
No. Someone implementing those isn't encouraged to be familiar with this work.
It's purely an optional extension.
> 1. *Introduction*
>
> How about mentioning [I-D.MARF-AUTHFAILURE-REPORT] here too?
Seems reasonable; same for the spf-reporting draft. Scott?
> 2. *Definitions*
>
> I'd add a short section to define /report generator/, e.g.
>
> A report generator is an entity that generates and sends reports.
> For the scope of this memo, the term refers to Verifiers, as
> defined in Section 2.2 of [DKIM], designed to also generate
> authentication failure reports according to this specification.
Seems reasonable; same for the spf-reporting draft. Scott?
> 3.2. *DKIM Reporting TXT Record*
>
> s/The Verifier (if it supports this extension)/A report generator/ if
> you inserted that definition. (For capitalization, I found eight
> occurrences of "Verifier" and just four of "verifier".)
OK, and capitalized the four lowercase instances.
> In the definition of rp=, maybe s/The value is an integer value/The
> value is a decimal integer/. If you do, the same applies to Section 4.
I just dropped the second "value". Saying "the value is an integer" is fine.
> In the definition of rr=, you need to add "d", "p", and "o" to rep-rr-
> type. Same applies to Section 4.
Fixed.
> In the definition of rs=, it may be worth noting that the reply code
> should not be part of the string.
It says "included", which to me makes it clear that it goes in the reply, not
that it is the reply.
> BTW, why isn't the rs= string actionable even in the absence of ra=?
Good point; fixed.
> 3.3. *DKIM Reporting Algorithm*
>
> Typo: "on a message fails". If you added the above definition, you may
> replace this text:
>
> The following algorithm, or one semantically equivalent to it, MUST
> be applied when an implementation is equipped to generate reports in
> compliance with this specification and its evaluation of the DKIM-
> Signature header field (see [DKIM]) on a message fails for some
> reason.
>
> with something like
>
> Report generators MUST apply the following algorithm, or one
> semantically equivalent to it, on each DKIM-Signature header field
> whose verification fails for some reason.
Done.
> The last paragraph of this section is rather convoluted. In order to
> simplify it, I would modify the first step of the algorithm to read
> like so:
>
> 1. If the DKIM-Signature field did not contain a valid "r=" tag
> and if there are no different out-of-band arrangements,
> terminate.
>
> I don't attempt to actually simplify that paragraph, but note that it
> might refer to Section 8.5 (Automatic Generation) for out-of-band
> arrangements.
I think that falls under "semantically equivalent", so I'd prefer not to change
it.
> Murray, the "previous implementations" that the subsequent paragraphs
> refer to are a rather obscure entity. They seem to be internal notes
> that somehow happened to make their way into the published spec.
They're there deliberately to explain the choices made with this algorithm,
especially when the people reading it might be familiar with pre-RFC
implementations of DKIM reporting.
> 4. *Optional Reporting Address for DKIM-ADSP*
>
> See notes above for rp= and rr=.
Fixed.
> 5. *Requested Reports*
>
> s/this these/these/
It's one list, so "this" is correct.
> 5.2. *Requested Reports for DKIM ADSP Failures*
>
> s/[ADSP]-related reason/[ADSP]-related failure reason/
I think that's redundant, but harmless, so sure.
> 6.2. *Envelope Sender Selection*
>
> In our case, mail loops may occur among _report addresses. For
> example, bad signature => dkim-report with bad SPF => spf-report with
> bad DKIM-Signature => dkim-report with bad SPF...
>
> Perhaps, the I-D could say that, for ARF messages of any kind, the r=
> tag of a DKIM-Signature MUST be ignored and automatic report generation
> MUST NOT take place. Out-of-band arrangements can still provide for
> manual ways to report failures of the reporting mechanism itself.
I think the existing text in this section already covers that case, especially
the first SHOULD. I also think a general admonishment of this type is not
appropriate in this subsection because it has nothing at all to do with the
envelope sender. So I'll add it in its own subsection.
> Typo: s/wil pass/will pass/
Fixed.
> 8.1. *Inherited Considerations*
>
> [I-D.MARF-AUTHFAILURE-REPORT] is missing here.
Fixed.
> 8.5. *Automatic Generation*
>
> The last paragraph, about out-of-band arrangements, seems to defy this
> I-D's very purpose of automating reporting. Considering what marf-as
> is going to say on unsolicited reports, I'd s/create/persist sending/.
> The resulting wording implies an upper limit for reports generated
> automatically that are destined to a given domain. That, in turn,
> implies maintaining a domain-indexed database of what's going on with
> the email. In this case we may count the overall number of reports
> sent with no out-of-band arrangement.
What this section is trying to say is that people should not implement systems
that do this kind of reporting work by default. It can create a ton of traffic
due to simple infrastructure problems at the signer/sender, for example. The
obvious mitigation, rate limiting the generation of reports, isn't an ideal
solution for various reasons.
I don't think this harms what -as is saying about unsolicited reports. This
document discusses a specific kind of feedback and thus this is not a statement
about ARF in general.
> 8.6. *Reporting Multiple Incidents*
>
> This section seems disconcerting, especially the middle paragraph.
> Since the rp= tag is specified with utter sharpness, implementations of
> the logarithmic approach seem to be out of the way. Perhaps, we can
> recommend a switch-to-manual upper limit instead, counting the number
> of reports sent per day (or per hour), using the same database as
> above.
>
> To suspend report generation for some time after an RCPT rejection of
> the reporting address might also provide for a safe approach.
Since it's Security Considerations, none of this is normative. It's just a
suggestion for handling large volumes of reports. Your two are equally viable,
so it would be fine to add them as well, especially since the latter one talks
about a way to do rate limiting at the report receiver rather than relying on
the report generator to do it all. So I'll add this:
<t> Other rate limiting provisions might be considered,
including detection of a temporary failure
response from the report destination and thus
halting report generation to that destination
for some period, or simply imposing or negotiating
a hard limit on the number of reports to be sent
to a particular receiver in a given time
frame. </t>
-MSK
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
