> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Alessandro Vesely
> Sent: Friday, January 27, 2012 11:17 AM
> To: [email protected]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-04.txt
>
> On 26/Jan/12 07:16, Murray S. Kucherawy wrote:
> > I'm caught up on the feedback for this, I think. Please review the
> > latest version and provide commentary.
>
> Some points, nits, and ideas:
>
> *Updates 5965*
>
> It doesn't seem to actually update the format. If the use of ARF is
> meant to be updated, we probably need a section where that update is
> identified.
It's my understanding that "RFCx updates RFCy" means "if you are implementing
RFCy, you really also need to read RFCx". For an applicability statement,
therefore, this is typical.
> *Section 5*
>
> The second part of the second paragraph ("Abuse addresses in WHOIS
> records [...]") covers a where-to-send question similar to the one
> answered by bullet 5 in Section 8. Would it be an improvement to have
> them near to one another?
That doesn't seem to be beneficial enough to warrant rearranging the whole
thing.
> BTW, this method is also "not universally
> true", as the retrieved abuse mailbox can belong to a network provider
> who may or may not forward reports to the relevant mailbox provider or
> ESP.
True, will add that nit-text.
> *Section 6*
>
> The text "Section 3.4 of that document" gets a wrong link in bullet 1
> of http://tools.ietf.org/html/draft-ietf-marf-as-04#section-6
>
> Repeating the same reference makes for a less appealing prose, but is
> easier to markup and search.
That's unfortunate, so OK.
> *Section 7*
>
> In bullet 4, "That system" refers to the automated system considered in
> the previous bullet. It is unclear, now that that text has changed.
> Hints for rewording: bullets 4 and 5 apply to automated systems, so
> they might be further indented.
I just changed "That system" to "An automatic report processing system".
> Bullet 7 could also refer to Section 4.4 of [RFC6449], as it covers
> redaction. However, RFC 6449 treats that the same irrespectively of
> the redaction algorithm used. Should we say how to recognize and take
> advantage of /conforming/ redaction?
Added the reference and a sentence reiterating the point of standard redaction,
which is to enable correlation and prioritization by the recipient.
> *Section 8*
>
> Bullets 1 and 2 sound quite obscure, or maybe it's just me. As a minor
> improvement, maybe s/generating/reporting/?
Done.
> Bullet 3: s/service provider/mailbox provider/.
Done.
> Perhaps before bullet 9: do we want to mention that a network provider
> MAY use ARF data for automated forwarding of Feedback Messages to the
> originating customer, as described in the last paragraph of Section
> 4.4 of [RFC6449]?
Added.
> Bullet 11: kudos for that, great! Do we want to refer to Section 3.5
> of [RFC6449] from there too?
Added.
> In particular, feedback providers who save the unsolicited reports they
> send (as they should) can provide a web page for the report at hand.
> That page would display all parts of the report --thereby solving the
> issue of bullet 10-- and also provide any FBL-related link that is
> mentioned in Section 3.5.1 of [RFC6449]. Would this be good?
Possibly, but without an implementation it's hard to say that we can justify
including it in an applicability statement. Have you actually tried this?
> If we like it, we could summarize such approach by adding an example
> of unsolicited feedback in an appendix of this I-D. The human readable
> part of the exemplified message might contain text such as:
>
> This is an unsolicited feedback report for an email message
> received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT)
> and generated according to [this memo]. If you are unable to
> correctly visualize any of its parts, you may want to access
> https://postmaster.feedback-provider.example/fbl?key=1a2b3c4d5e
> (certified by http://unusual-CAcert.example/certs/root.crt).
>
> Our web page above also contains links to general information on
> our Complaint Feedback Loop program and how to get enrolled, so as
> to receive feedback reports like this regularly or to stop them
> altogether.
>
> Alternatively, you may reply to this message to confirm the email
> address that was used to send this report. Please tell us what
> action you took in order to avoid that the abusive behavior we are
> complaining about will continue.
Simpler would be to suggest that sending unsolicited feedback SHOULD populate
the text/plain part of the report with ample explanatory text about what this
message is and where to get more information, since there's no guarantee the
recipient will understand the other two MIME parts. But I believe bullet 10
already covers that.
-MSK
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
