Steve Atkins <[email protected]> wrote:

>
>On Feb 1, 2012, at 12:14 PM, Scott Kitterman wrote:
>
>> On Tuesday, January 31, 2012 04:23:33 PM Barry Leiba wrote:
>>> I am re-posting this without the extra recipients; please reply to
>>> THIS message, and NOT to that other one.  We can discuss later who,
>>> exactly, should get the truncheon treatment here.......
>>> ---
>>> 
>>> Here begins a last call for the MARF working group on the subject
>>> document, detailed below.  Please make any comments you have on this
>>> version no later than 10 Feb 2012.  That's a week and a half, which
>>> should be enough for this active and vocal group, wot?  Please do
>not
>>> wait until the last minute, and especially do not wait until the
>>> document goes to the IESG.  You will be beaten with a rubber
>>> truncheon.
>> 
>> It looks good to me.  Just a couple of comments:
>> 
>>      3.  The Mailbox Provider SHOULD send reports to relevant parties
>who
>>       have requested to receive such reports.  The reports MUST be
>>       formatted per [RFC5965], and transmitted as an email message
>>       ([RFC5322]), typically using SMTP ([RFC5321]).  The process
>>       whereby such parties may request the reports is discussed in
>>       Section 3.5 of [RFC6449].
>> 
>> Although I understad the MUST here in context, it could be misread
>out of 
>> context by people trying to insist on ARF.  Could we have some kind
>of "To 
>> implement the recommendations of this draft, the reports MUST ..." or
>similar?
>> 
>> 12.  Although [RFC6449] suggests that replying to feedback is not
>>        useful, in the case of receipt of ARF reports where no
>feedback
>>        arrangement has been established, a reply might be desirable
>to
>>        indicate that the complaint will result in action, heading off
>>        more severe filtering from the report generator.  Thus, a
>report
>>        generator sending unsolicited reports SHOULD ensure that a
>reply
>>        to such a report can be received.  Where an unsolicited report
>>        results in the establishment of contact with a responsible and
>>        responsive party, this can be saved for future complaint
>>        handling and possible establishment of a formal (solicited)
>>        feedback arrangement.  See Section 3.5 of [RFC6449] for a
>>        discussion of establishment of feedback arrangements.
>> 
>> The SHOULD seems strong here.  While I agree it's a nice idea, the
>odds of 
>> this actually happening are vanishingly small in my opinion. 
>Something 
>> without a RFC 2119 keyword would be better here.
>
>Unsolicited reports sent from an undeliverable address aren't terribly
>useful, as you can't ask the sender for additional context (data that's
>already there for FBLs). They're also more likely to be discarded or
>blocked.
>
>I think the SHOULD is a reasonable level of strength (though I
>wouldn't object to MUST).

That's a much better rationale.  The draft should leave the SHOULD and add that.

Scott K


_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf

Reply via email to