> -----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.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
