Re: [marf] I-D Action: draft-ietf-marf-as-10.txt

"Murray S. Kucherawy" <msk@cloudmark.com> Fri, 24 February 2012 21:12 UTC

Return-Path: <msk@cloudmark.com>
X-Original-To: marf@ietfa.amsl.com
Delivered-To: marf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D2F21F86FF for <marf@ietfa.amsl.com>; Fri, 24 Feb 2012 13:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGyWQiHbTquZ for <marf@ietfa.amsl.com>; Fri, 24 Feb 2012 13:12:24 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB1121F86F9 for <marf@ietf.org>; Fri, 24 Feb 2012 13:12:23 -0800 (PST)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 13:12:22 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "marf@ietf.org" <marf@ietf.org>
Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-10.txt
Thread-Index: AQHM8lWLsMmqbRNTokGcZeQaAgi37ZZKx9yQgAIiAQD//597wA==
Date: Fri, 24 Feb 2012 21:12:21 +0000
Message-ID: <9452079D1A51524AA5749AD23E0039280454F2@exch-mbx901.corp.cloudmark.com>
References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> <4F47DA56.8090105@tana.it>
In-Reply-To: <4F47DA56.8090105@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/marf>, <mailto:marf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/marf>
List-Post: <mailto:marf@ietf.org>
List-Help: <mailto:marf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2012 21:12:30 -0000

> -----Original Message-----
> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Alessandro Vesely
> Sent: Friday, February 24, 2012 10:44 AM
> To: marf@ietf.org
> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt

A co-chair's note: At this point I think it's prudent to say we won't make any more changes unless they achieve rough consensus or they are merely minor editorial corrections.

> I have four points only:
> 
> *Solicited and Unsolicited Reports*
> 
> Section 3 may sound misleading, as it may seem to exclude that
> unsolicited reports may also be "due to recipients manually reporting
> messages as spam."  (The introduction can be understood both ways.)

Making a backward reference about the cause of the reports from the second paragraph to the first is possibly a simpler change than what you propose, i.e.:

"Other uses for ARF involve such reports sent between parties that don't know each other."

Is that sufficient?

> (Really, solicited/unsolicited sending is transparent to the user or
> any other stream-wise similar input mechanisms.  Is it too late to try
> and treat #1 of Section 4.1 and #2 of Section 6.2 in a unified common
> section?)

I'm somewhat partial against having a "common" section.  What do others think?

Also, what do others think of the idea of talking about spam traps in Section 4.1?  It doesn't seem to me as though it's advice specific to unsolicited reports, unless that would be something covered in the agreement implicated in a solicited feedback arrangement.

> *When To Generate Reports*
> 
> The title of Section 6.2 should more appropriately be "When /Not/ To
> Generate Reports", except for the last paragraph that matches neither
> title.  How about moving #5 to the previous (General Considerations)
> subsection?

I don't agree with the renaming, but I agree with the proposed rearrangement.  Others?

> *Where To Send Reports*
> 
> SPF doesn't sign.  In paragraph #4 of Section 6.3, I'd replace:
> 
>   Where an abusive message is signed using a domain-level
>   authentication technology such as DKIM ([RFC6376]) or SPF
>   ([RFC4408]), the domain that has been verified by the
> 
> with:
> 
>   Where an abusive message is authenticated using a domain-level
>   authentication technology such as DKIM ([RFC6376]) or SPF
>   ([RFC4408]), the domain that got a "pass" ([RFC5451]) by the
> 
> (Is it possible to cite IANA's "Email Authentication Result Names"
> rather than, or in addition to, [RFC5451]?)

I agree with changing "signed" to "authenticated", but I think the rest goes too far without making the point any more clearly.

> *What To Do With Reports*
> 
> No vacation replies.  In paragraph #4 of Section 6.5, I'd replace:
> 
>   a reply might be desirable to indicate that the complaint will
>   result in action
> 
> with:
> 
>   a non-automated reply might be desirable to indicate what action
>   resulted from the complaint

I agree with that one.

-MSK