On Saturday, February 04, 2012 08:51:36 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Scott Kitterman Sent: Friday, February 03, 2012 2:05 PM > > To: [email protected] > > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was > > -07> > > On Friday, February 03, 2012 01:58:11 PM Murray S. Kucherawy wrote: > > > The mechanisms described in this memo are primarily intended > > > for use > > > in generating reports to aid implementers of [DKIM] and [ADSP] > > > and > > > other related protocols in development and debugging. They > > > are not > > > intended for prolonged forensic use. However, such uses are > > > possible by ADMDs that want to keep a close watch for fraud > > > or infrastructure problems. > > > > I probably missed a discussion about this sometime, but why isn't this > > intended for prolonged forensic use? The applications of ARF I've seen > > that's exactly what they are for. > > The difference to me is that conventional ARF (e.g., spam reports) are > almost always provoked by some human action, like clicking a Report Spam > button in a mail reader. These, by contrast, will almost always be > automatically generated. Perhaps we should say that, rather than what's > there now. > > I think the current language is also drawn from implementation experience. > It's akin, I suppose, to running a binary in production that has full > debugging symbols included to enable detailed debugging versus a stripped > binary that is leaner but harder to debug. Indeed, running a report > generator with all of this turned on can obviously cause drag on a mail > system when large and/or constant volumes of these reports are being sent > in addition to regular mail. > > So how about this to replace the above paragraph: > > ARF reports have historically been generated individually as a result of > some kind of human request, such as someone clicking a "Report Abuse" > button in a mail reader. In contrast, the mechanisms described in this > memo are focused around automated reporting. This obviously implies the > potential for much larger volumes or frequency of messages, and thus > greater mail system load (both for report generators and report receivers). > > These mechanisms are primarily intended for use in generating reports to aid > implementers of [DKIM] and [ADSP] and other related protocols in > development and debugging. They are not intended for prolonged forensic > use, specifically because of these load concerns. However, extended use is > possible by ADMDs that want to keep a close watch for fraud or > infrastructure problems. It is important to consider the impact of doing > so on both report generators and the requesting ADMDs.
"not intended for prolonged"/"not generally intended for prolonged" and I think I'm happy. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
