Hi Murray,
version -04 looks nearly good for WGLC. Thank you so much!
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.
*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? 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.
*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.
*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.
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?
*Section 8*
Bullets 1 and 2 sound quite obscure, or maybe it's just me. As a
minor improvement, maybe s/generating/reporting/?
Bullet 3: s/service provider/mailbox provider/.
Bullet 5: sounds good, but see previous comment for Section 5.
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]?
Bullet 11: kudos for that, great! Do we want to refer to Section 3.5
of [RFC6449] from there too?
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?
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.
Just a thought.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
