On 31/Jan/12 21:00, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> BTW, why isn't the rs= string actionable even in the absence of ra=?
>
> Good point; fixed.
Nice, thanks for this --and for the other fixes as well. Does this
change have to be addressed also in the last step of the reporting
algorithm? See below...
>> 3.3. *DKIM Reporting Algorithm*
>>
>> The last paragraph of this section is rather convoluted. In order to
>> simplify it, I would modify the first step of the algorithm
> I think that falls under "semantically equivalent", so I'd prefer
> not to change it.
Steps 2-9 are quite precisely stated, so I'm not sure how obvious it
is what amount of latitude is left to programmers' common sense. An
alternative is to use regular text phrases to discuss the SHOULDs and
MAYs of generating a report, as well as the relative independence
between that and honoring rs=. The algorithm proper would then
specify what to do after those decisions are made. (Hey, numbering
paragraphs /is/ meaningful in this case.)
>> 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/.
>
> What this section is trying to say is that people should not
> implement systems that do this kind of reporting work by default.
Yes. In this sense, that paragraph is rowing in the opposite
direction than the rest of the I-D. (I understand "reporting of
message authentication failures in an on-demand fashion" as
I-set-record=you-send-report.)
> 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.
Agreed.
> I don't think this harms what -as is saying about unsolicited
> reports.
Not at all. However, marf-as says
Where an unsolicited report
results in the establishment of contact with a responsible and
responsive party, this can be saved for future complaint
handling and possible establishment of a formal (solicited)
feedback arrangement.
That is, it provides for transitioning to an out-of-band agreement, if
interpreted in this I-D's context.
> This document discusses a specific kind of feedback and thus this
> is not a statement about ARF in general.
It is, since the paragraph talks about "these (or any) ARF reports".
And it is good to do so, IMHO. 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.
>> 8.6. *Reporting Multiple Incidents*
>>
>> 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.
Yes, such specification should belong to some other I-D
(reporting-discovery? :-)
> 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>
While that may be semantically correct, there is the practical problem
that 4xx reply codes are not reported timely. It is necessary to
query the mail queue in order to know whether there are outstanding
temporary failures. In case the boundary box where the report
generator lives does not send mail out directly, it is not practical
to determine that condition.
On the other hand, 5xx reply codes should cause the current message to
be discarded. On resuming reporting, new reports are transmitted,
rather than the queued flood initiators. However, in order to ensure
immediate notification of rejections in all cases, one would have to
use purposely configured variable envelope senders.
What do you think?
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
