Re: [marf] Robert Sparks' Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)

"Murray S. Kucherawy" <msk@cloudmark.com> Wed, 25 April 2012 05:16 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 3F39021F870E for <marf@ietfa.amsl.com>; Tue, 24 Apr 2012 22:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.635
X-Spam-Level:
X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 tn9MgtqbDF1A for <marf@ietfa.amsl.com>; Tue, 24 Apr 2012 22:16:02 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 382C921F8701 for <marf@ietf.org>; Tue, 24 Apr 2012 22:15:54 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 25Fk1j0010as01C015FkWh; Tue, 24 Apr 2012 22:15:53 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=MJriabll c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=2yULNDzDLVcA:10 a=zutiEJmiVI4A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8 a=u6cicfyKABuvnULZKwwA:9 a=0Um7TzdPG6ezEnD0rpIA:7 a=QEXdDO2ut3YA:10 a=0MAqpqVwYqEA:10 a=QMZKka45TBd+hNGtXG2bIg==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 22:15:44 -0700
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: Robert Sparks <rjsparks@nostrum.com>, The IESG <iesg@ietf.org>
Thread-Topic: Robert Sparks' Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)
Thread-Index: AQHNIjJaeEooO/OWr0mELwJupYTFTpaq++ow
Date: Wed, 25 Apr 2012 05:15:43 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928101C27@exch-mbx901.corp.cloudmark.com>
References: <20120424155216.17623.92039.idtracker@ietfa.amsl.com>
In-Reply-To: <20120424155216.17623.92039.idtracker@ietfa.amsl.com>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335330953; bh=rOuW+Ab1P0XqfG2SWl9muauoTiix//fuzMxbfRMb8wQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=HURk8wdTEAp7fwNbIb/nauZV9z689Ay+rfV3vGSYxWfcq3Cl00HPTn5TSHSfLJJie sjaaNio7weIa01xNq8ugYdqLUO2IBOin8Fs2LsVh6Dy5BxmJsqUlyY1LFIL6QqgjxE qkzVfkLbzqDoJNFgCthxgKTNF/2gFiI7UXasbuos=
Cc: "draft-ietf-marf-as@tools.ietf.org" <draft-ietf-marf-as@tools.ietf.org>, "marf-chairs@tools.ietf.org" <marf-chairs@tools.ietf.org>, "marf@ietf.org" <marf@ietf.org>
Subject: Re: [marf] Robert Sparks' Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)
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: Wed, 25 Apr 2012 05:16:03 -0000

> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: Tuesday, April 24, 2012 8:52 AM
> To: The IESG
> Cc: marf-chairs@tools.ietf.org; draft-ietf-marf-as@tools.ietf.org
> Subject: Robert Sparks' Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)
> 
> Robert Sparks has entered the following ballot position for
> draft-ietf-marf-as-14: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The MUST in section 4.5 item 1 may need clarification. Do you mean to
> say that the system MUST accept a report with a feedback type with any
> value that makes it into the (specification-required) registry? Or are
> you wanting to scope that to values that were registered with an RFC
> that Updates/Obsoletes 5965? Or something else?

The intent is the first case, or basically any "official" type.  At present, that means the registry.  Obviously there's no signaling mechanism from IANA to implementers when new types are added, but that's still the intent.  Since this is an applicability statement and not a technical specification, I don't think we need to establish a protocol to ensure compliance, but rather perhaps say that implementers need to check periodically for new types of feedback to appear in the registry as a result of the publication of other registering documents.

> Is this effectively
> requiring implementations of automated report processing systems to be
> configurable with what feedback types it will accept? If so, would it
> make sense to say that explicitly?

That is one option, except that in addition to merely accepting the types by name, adding parsing support for types which (for example) add new feedback header fields might be necessary.  So it might not be as simple as configuring a list.  Perhaps "add support for" would be better.

> Also, consider more detail on what
> accept means here. Does it mean the system can't return a rejection
> response (what bad happens if it does?) or is the intent that it must
> _process_ the report.

The intent is "not reject", as in no SMTP 5yz replies and no DSNs generated.  Rather than requiring automated processing, a system that sees a report type it doesn't explicitly know how to handle might simply set it aside for manual handling.  The rejection can't necessarily be distinguished by the sender as "unsupported report type" if the other side is only looking at SMTP reply codes, for example; we'd have to provide a more detailed signaling mechanism on top of SMTP.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In section 5.1 item 1, is there a typical unstandardized out-of-band
> mechanism for telling unsolicited reporters to please stop that you can
> call out as an example (an existence proof)?

I'll see if I can find one.  I don't know of one personally, but someone in the working group probably does.

> In Section 6, item 1, the sentence "Automatic feedback generators MUST
> select recipients based on data provided by the report recipient." is
> really hard to understand (it's almomst circular). Is it trying to say
> something like "Automatic feedback generators MUST only send to
> addresses explicitly provided by willing recipients."?

Yes, that's better.  We can patch that in.

Thanks,

-MSK