> -----Original Message----- > From: Alessandro Vesely [mailto:[email protected]] > Sent: Thursday, April 05, 2012 10:26 AM > To: Murray S. Kucherawy > Cc: Pete Resnick; [email protected] > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-12.txt > > > Sounds to me like you're saying the same thing. > > More or less yes. It's not a sharp concept, however tweaked. I was > just trying to make sure we're not introducing wrong interpretations, > such as "always put the same type since recipients may not care"...
It's meant to be a level-set of assumptions. If you don't know how your report recipient will handle types other than "abuse" (which all of them use), then you can't make any assumptions. > > Ah, right, this was lost to memory when Pete and I discussed it in > > Paris. So how about this, re-inserted as 6.3/1: > > > > 1. Rather than generating feedback reports themselves, MUAs SHOULD > > make abuse reports back to their mailbox providers so that they > > can generate and send ARF messages on behalf of end users. This > > allows centralized processing and tracking of reports, and > > provides training input to filtering systems. > > As long as "make abuse reports back" is clear, that may work. MUAs > could use any of John's taxonomy techniques[1], I don't know if it > could be acceptable to refer to that page... I'll note here that there's no standard signaling mechanism for use between MUAs and ISPs to trigger reports. > For a nit, the I-D uses the term "report generator". Its meaning is > obvious. However, RFC 6449 uses "Feedback Provider" instead. Would > the addition of a definition in Section 2 ease such references? E.g. > something like so: > [...] Actually changing "report generator" to "Feedback Provider" is a better idea because it makes the two documents even more consistent with each other. So I'll do that as well. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
