On 30/Jan/12 20:39, Murray S. Kucherawy wrote:
>
>> From: ietf.org On Behalf Of [email protected]
>
>> Filename : draft-ietf-marf-dkim-reporting-07.txt
>
> - addresses Alessandro's last point about fraudulent signature detection
>
> - fix up the examples, and split the first one since DKIM reporting is now
> split into two parts
>
> - change "rd=domain" to "r=y" in the signature
>
> - add "policy" and "other" report types
Does this I-D update RFCs 5617 and 6376? I'm just trying to learn...
1. *Introduction*
How about mentioning [I-D.MARF-AUTHFAILURE-REPORT] here too?
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.
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".)
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.
In the definition of rr=, you need to add "d", "p", and "o" to
rep-rr-type. Same applies to Section 4.
In the definition of rs=, it may be worth noting that the reply code
should not be part of the string.
BTW, why isn't the rs= string actionable even in the absence of ra=?
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.
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.
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.
4. *Optional Reporting Address for DKIM-ADSP*
See notes above for rp= and rr=.
5. *Requested Reports*
s/this these/these/
5.2. *Requested Reports for DKIM ADSP Failures*
s/[ADSP]-related reason/[ADSP]-related failure reason/
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.
Typo: s/wil pass/will pass/
8.1. *Inherited Considerations*
[I-D.MARF-AUTHFAILURE-REPORT] is missing here.
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.
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.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
