> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Wednesday, February 01, 2012 2:48 AM > To: [email protected] > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 > > >> 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...
The last step already does talk about including the "rs=" string, if there was one. What does need correction though is step 8 which presumes "ra=" is there. I'll tidy that up. > 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.) We've used the "semantically equivalent" language in a few places without complaint, most notably ADSP and I think DKIM as well. I think adding specific implementation detail about possible alternate implementations will just clutter the matter rather than improving it, so I'd prefer to leave it alone. > >> 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.) 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. It seems very appropriate to me to call that out in Security Considerations. > 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. I think to do so we would wander into the realm of speculation, not specification. I don't think that's a good idea for something that's asking for Proposed Standard status as a protocol document. Perhaps it could as an applicability statement, but that's not what we're doing here. > >> 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? :-) If we're going to talk about handling of large report volumes, given our current document set, the AS is the right place to do it. If you think that's important, now's the time to make such a proposal, before WGLC closes. > 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? 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. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
