From msk@cloudmark.com Thu Apr 1 11:18:06 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DB13A684C for ; Thu, 1 Apr 2010 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=-1.511, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1wAqGZRUG5N for ; Thu, 1 Apr 2010 11:18:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 8CAD33A6A94 for ; Thu, 1 Apr 2010 11:18:00 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Thu, 1 Apr 2010 11:18:33 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 1 Apr 2010 11:18:32 -0700 Thread-Topic: IETF 77 MARF WG meeting minutes Thread-Index: AcrRx7yhwBe82uiXT5K9dkkPwcWqKA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01CF9473A9EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] IETF 77 MARF WG meeting minutes X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:18:06 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01CF9473A9EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The MARF Working Group met at IETF 77 in Anaheim, California. Approximatel= y 25 people attended in person. JD Falk presented the history of the ARF effort, which started at the Messa= ging Anti-Abuse Working Group (MAAWG) several years ago. The focus was dat= a sharing among ISPs, and the current format developed after some collabora= tion among the membership there. This produced draft-shafranovich-feedback= -report, which is now draft-ietf-marf-base. Working Group Last Call for the base draft will begin April 2nd after Barry= Leiba goes over it once to ensure the proposed payload is in a format easi= ly adapted to other transport mechanisms. WGLC will run for two weeks, and= then the base draft will be passed to the IESG. There was some discussion about the MAAWG Feedback Loop BCP document, which= might be used as a basis for the working group's informational documents, = per our charter. There will be more liaison about that effort between now = and Maastricht; Barry is the IETF's liaison to MAAWG. There was some discu= ssion about the value of doing an IETF BCP if MAAWG does a BCP; JD points o= ut that BCPs from the IETF undergo more technical rigor, and Barry mentione= d that this would increase the general exposure of the material. Murray Kucherawy presented about parallel activities in the mobile space, n= amely efforts by both the GSM Association (GSMA) and the Open Mobile Allian= ce (OMA), as we are chartered to track those. The "short code" abuse repor= ting experiment conducted in France was summarized, as well as a brief over= view of the OMA's current "SpamRep" project. The IETF already has an OMA l= iaison position, so this will be useful to the working group going forward.= There was some discussion about things like where to send reports, which = currently neither SpamRep nor ARF specify (though that's a charter item for= us); might be something we could work on with the OMA since they need it a= s well. Murray also introduced the DKIM Reporting draft (draft-kucherawy-dkim-repor= ting), which is among our chartered items. There was a brief discussion about ARF extensions. The group was reminded = that we are not currently chartered to discuss extensions, but rechartering= can easily be done once we're finished with our current work. --_000_BB012BD379D7B046ABE1472D8093C61C01CF9473A9EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The MARF Working Group met at IETF 77 in Anah= eim, California.  Approximately 25 people attended in person.

 

JD Falk presented the history of the ARF effo= rt, which started at the Messaging Anti-Abuse Working Group (MAAWG) several yea= rs ago.  The focus was data sharing among ISPs, and the current format de= veloped after some collaboration among the membership there.  This produced draft-shafranovich-feedback-report, which is now draft-ietf-marf-base.=

 

Working Group Last Call for the base draft wi= ll begin April 2nd after Barry Leiba goes over it once to ensure the proposed payload is in a format easily adapted to other transport mechanisms.  = WGLC will run for two weeks, and then the base draft will be passed to the IESG.=

 

There was some discussion about the MAAWG Feedback Loop BCP document, which might be used as a basis for the working group’s informational documents, per our charter.  There will be= more liaison about that effort between now and Maastricht; Barry is the IETFR= 17;s liaison to MAAWG.  There was some discussion about the value of doing = an IETF BCP if MAAWG does a BCP; JD points out that BCPs from the IETF undergo more technical rigor, and Barry mentioned that this would increase the general exposure of the material.

 

Murray Kucherawy presented about parallel activities in the mobile space, namely efforts by both the GSM Association (GSMA) and the Open Mobile Alliance (OMA), as we are chartered to track tho= se.  The “short code” abuse reporting experiment conducted in France= was summarized, as well as a brief overview of the OMA’s current “SpamRep” project.  The IETF already has an OMA liaison po= sition, so this will be useful to the working group going forward.  There was = some discussion about things like where to send reports, which currently neither SpamRep nor ARF specify (though that’s a charter item for us); might = be something we could work on with the OMA since they need it as well.

 

Murray also introduced the DKIM Reporting dra= ft (draft-kucherawy-dkim-reporting), which is among our chartered items.<= /o:p>

 

There was a brief discussion about ARF extensions.  The group was reminded t= hat we are not currently chartered to discuss extensions, but rechartering can eas= ily be done once we’re finished with our current work.<= /p>

--_000_BB012BD379D7B046ABE1472D8093C61C01CF9473A9EXCHC2corpclo_-- From msk@cloudmark.com Tue Apr 6 12:14:02 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5453A6994 for ; Tue, 6 Apr 2010 12:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji9S5yjyhaYc for ; Tue, 6 Apr 2010 12:13:59 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 2548D3A6AE8 for ; Tue, 6 Apr 2010 12:11:33 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Tue, 6 Apr 2010 12:11:30 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 6 Apr 2010 12:11:27 -0700 Thread-Topic: WGLC starting for draft-ietf-marf-base-01 Thread-Index: AcrVvPUnnR9Chg9vTPqXOLrgSwPoQQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: C3Kt EP5C FLaa FUwk FgZ3 GJBh GmfA G3Gz HTyV HcO7 IH4L IMnL JUGy KJWo K/34 LHXz; 1; bQBhAHIAZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {13546EAB-86C3-4557-BF8A-ECAF8E1B0F5F}; bQBzAGsAQABjAGwAbwB1AGQAbQBhAHIAawAuAGMAbwBtAA==; Tue, 06 Apr 2010 19:11:27 GMT; VwBHAEwAQwAgAHMAdABhAHIAdABpAG4AZwAgAGYAbwByACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAG0AYQByAGYALQBiAGEAcwBlAC0AMAAxAA== x-cr-puzzleid: {13546EAB-86C3-4557-BF8A-ECAF8E1B0F5F} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01CF9478A6EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:14:02 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01CF9478A6EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for the delay starting this, but let's get it underway! I've just posted draft-ietf-marf-base-02, containing minor changes since -0= 1 having to do with Reported-Domain and Reported-URI as discussed on the li= st. Working Group Last Call for draft-ietf-marf-base-02 is now in effect, lasti= ng for two weeks and thus ending on April 20th. Please review it and submi= t comments by then. A new revision will be produced (if needed) and then w= e will submit it to the IESG for IETF-wide last call and evaluation. -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01CF9478A6EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for the delay starting this, but let’s get= it underway!

 

I’ve just posted draft-ietf-marf-base-02, contai= ning minor changes since -01 having to do with Reported-Domain and Reported-URI = as discussed on the list.

 

Working Group Last Call for draft-ietf-marf-base-02 is= now in effect, lasting for two weeks and thus ending on April 20th.&= nbsp; Please review it and submit comments by then.  A new revision will be produced (if needed) and then we will submit it to the IESG for IETF-wide l= ast call and evaluation.

 

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C01CF9478A6EXCHC2corpclo_-- From root@core3.amsl.com Tue Apr 6 12:15:09 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 88D893A6AD3; Tue, 6 Apr 2010 12:15:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100406191508.88D893A6AD3@core3.amsl.com> Date: Tue, 6 Apr 2010 12:15:04 -0700 (PDT) Cc: marf@ietf.org Subject: [marf] I-D Action:draft-ietf-marf-base-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:15:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF. Title : An Extensible Format for Email Feedback Reports Author(s) : Y. Shafranovich, et al. Filename : draft-ietf-marf-base-02.txt Pages : 33 Date : 2010-04-06 This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-base-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-marf-base-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-06120856.I-D@ietf.org> --NextPart-- From vesely@tana.it Fri Apr 9 11:02:05 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401E83A6862 for ; Fri, 9 Apr 2010 11:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SbQ5fG6oeM1 for ; Fri, 9 Apr 2010 11:02:03 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 84F203A6890 for ; Fri, 9 Apr 2010 11:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1270836110; bh=blxqXEjNX2VPaHCpk4HpNFAyx9tK3QuHITOi9N/vxf4=; l=1398; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=U54Z9/rXHlHuUJXamchHJdGz6h63cY3YbYeK4YaUkvyo5ltUZ8gKa3n0dDLXhmiBX q+PxE9Mste5M2RTJQKcZzp+Dh+DMkxdDrqf3nRzAOCoUjvKLt5LDBwkLIEdsHnGKen QMDvQuZ34SgOVfRXOlcdE4t/PgCGX64T5ppdoMjk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 09 Apr 2010 20:01:50 +0200 id 00000000005DC035.000000004BBF6B8E.0000139F Message-ID: <4BBF6B8D.1030901@tana.it> Date: Fri, 09 Apr 2010 20:01:49 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 18:02:05 -0000 "Reported-Domain" is unspecified by design. Fine :-( However, it is not clear whether it may appear multiple times even if the report covers a single incident. As for using "Reported-URI" for the spamvertized mailbox, I just note that IODEF's draft-cain-post-inch-phishingextns (now in LC) calls that "Collection Site". The phrase "a URI to which the report recipient can go for further details", instead, suggests something like http://example.com/arf-generators/XYZ-v1.04b/meaning-of-fields.html I propose to replace that phrase with just "See next Section 3.4". (Will there be an applicability statement to clarify how meanings may be negotiated, eventually?) Section 7.3 still says "MAIL FROM:<>". See the end of http://www.ietf.org/mail-archive/web/marf/current/msg00641.html Should the security section mention that automatically forwarding an abuse report to the wrong party may leak sensible information, especially if the report had been inadvertently generated by a user? (The intro says something about supporting mail clients.) Should "http://www.mipassoc.org/arf/" in the examples be replaced with something with like the first http link above? (Should the spec RECOMMEND that the meaning of fields is stated that way?) In appendix B2, the Authentication-Results looks bogus. In addition, the caption says "Example 3" rather than 2. From jdfalk-lists@cybernothing.org Mon Apr 12 12:28:38 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433FE3A6A49 for ; Mon, 12 Apr 2010 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndrSbD9gfAXl for ; Mon, 12 Apr 2010 12:28:37 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 0A76E3A6AAC for ; Mon, 12 Apr 2010 12:28:34 -0700 (PDT) Received: from rpco-bhill.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3CJSR8t017110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Apr 2010 13:28:29 -0600 References: <4BBF6B8D.1030901@tana.it> In-Reply-To: <4BBF6B8D.1030901@tana.it> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <4FA3A0BB-560E-4382-9326-F5D9F6FE7CEA@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Mon, 12 Apr 2010 13:28:21 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 19:28:38 -0000 On Apr 9, 2010, at 12:01 PM, Alessandro Vesely wrote: > As for using "Reported-URI" for the spamvertized mailbox, I just note = that IODEF's draft-cain-post-inch-phishingextns (now in LC) calls that = "Collection Site". The phrase "a URI to which the report recipient can = go for further details", instead, suggests something like >=20 > http://example.com/arf-generators/XYZ-v1.04b/meaning-of-fields.html Reported-URI should be a URI copied from (or perhaps derived from) the = message being reported. It's not intended for documentation about the = report itself. -- J.D. Falk Return Path Inc From yakov@shaftek.org Mon Apr 12 18:39:34 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E133A3A67E6 for ; Mon, 12 Apr 2010 18:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGoaauH3ku57 for ; Mon, 12 Apr 2010 18:39:29 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 819743A67AE for ; Mon, 12 Apr 2010 18:39:29 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so569979fgb.13 for ; Mon, 12 Apr 2010 18:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.49.7 with HTTP; Mon, 12 Apr 2010 18:38:59 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Mon, 12 Apr 2010 21:38:59 -0400 Received: by 10.87.63.21 with SMTP id q21mr4485375fgk.52.1271122760082; Mon, 12 Apr 2010 18:39:20 -0700 (PDT) Message-ID: To: "marf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 01:39:35 -0000 (Thanks to all for shepherding this along) Here are my comments: In section 1.1: Do we need to add something about end-user clients and their ISPs communicating about spam as mentioned in the introduction? Kind of like the "Report Spam" button in the MUA In section 1.2: Are we using "must" in its [KEYWORDS] context? In section 3.1: "The following report header fields MUST appear exactly once:" should we add "...exactly once in no particular order" or "...exactly once with no particular order dictated by this specifiction" Same for sections 3.2 and 3.3 Section 3.1, "Version": Should we change to "1" or "1.0" like MIME? Section 3.2, "Incidents": The spec mentions several times before that multiple or aggregate reports are not covered. Yet this field covers that. We need to insert some text addressing that Section 3.2, "Received-Date": Provisions needs to be made in the IANA registry that fields can be marked as historic. Section 3.3, "Reported-Domain": Should Reported-URI be encouraged instead, as per RFC 4501 and "Reported-Domain" be historic Section 3.3, "Reported-URI": Same text for the "Reported-Domain" field should apply to "URI" Section 3.5: Are we mandating an specific order for fields? Section 5: Isn't calling for experimental codes to be rejected a bit harsh? Also, by "experimental result codes" - do you mean feedback types or experimental fields? Sections 6-7: Should we add some sort of status field that indicates whether a given field or feedback type is historic, obsolete or in current use as per above regarding "Received-Date"? Section 7: This conflicts with what we wrote above regarding leaving <> usage to the operator discretion Section 7.5: - I would even add that people may attach viruses or malware to ARF reports, but at the same time, since ARF messages may be used to report viruses, they may contain them by design. We might want to say that viruses and malware may be carried in ARF reports, so people should exercise caution. On the other hand, they should not reject reports containing viruses since they may be legit. Thanks From sm@resistor.net Tue Apr 13 01:10:57 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80DC3A69E5 for ; Tue, 13 Apr 2010 01:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZNHlbwxMyQh for ; Tue, 13 Apr 2010 01:10:55 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 57D9D3A693A for ; Tue, 13 Apr 2010 01:10:19 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o3D89Xdl022624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 01:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1271146209; x=1271232609; bh=pio6YMvdWdnEScn3jZeWRyg4haBnVribLlgBKxxqptg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=nq5vRfIgQ3TnQvgCZKSiL2bCRz+GKHA+u2IYblBjwe0YjjNsJU+6SYal6aexb3zwx 6vP9fYiWR6lrSB32oxBPmSvSBh+iSa68oBbBygKyLRTSTV0bfJUrG3tWurzjk9HhAV Ibc4nwPPw5hqzuHwC/urucJHJ56JmDcZJDaoffIA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1271146209; x=1271232609; bh=pio6YMvdWdnEScn3jZeWRyg4haBnVribLlgBKxxqptg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Rpi+1ajE+fS5kUPnP7m759aoV0QCjCZKXGBYFC5Igd65NGIhYOli/rjMQPleexvDZ tqFCTzUV4GrpR92yK5iOa0R8rZ85dDqEXcluFZ6noSTsfbRJqbKFI619moN6FOykpJ V4mA7XUWhjSRkSA0ktPLguAoQlUKQGi09a5v2F2I= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ddAZnmTfwyLkMP93Av7ozeUZMe5GIc2aPjErwyG73C6aHPxCwS5HVweLlLlK+A8fl AEdOnpjINR1YZy+rxYownet34KvpBfyJ4WzIlHiSSQkjLMuVC1cobRIGjhiIlhdsLtD KfKoapR49km+japbML5CK5rQKo5++ABfH+Y7Jc4= Message-Id: <6.2.5.6.2.20100412232912.09587f80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Apr 2010 01:08:24 -0700 To: marf@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alessandro Vesely Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 08:10:57 -0000 At 12:11 06-04-10, Murray S. Kucherawy wrote: >Working Group Last Call for draft-ietf-marf-base-02 is now in >effect, lasting for two There is a typo for "original" in Section 2, Item d. In Section 5: Result codes not beginning with "x-" MUST be registered as described above and appropriately published. Is that for feedback report types? What is the meaning of "appropriately published"? The example in B.1 has the "From:" before the "Received:" header field. At 11:01 09-04-10, Alessandro Vesely wrote: >"Reported-Domain" is unspecified by design. Fine :-( However, it is >not clear whether it may appear multiple times even if the report >covers a single incident. According to Section 3.3, it may appear more than once. >Section 7.3 still says "MAIL FROM:<>". See the end of >http://www.ietf.org/mail-archive/web/marf/current/msg00641.html > >Should the security section mention that automatically forwarding an >abuse report to the wrong party may leak sensible information, >especially if the report had been inadvertently generated by a user? >(The intro says something about supporting mail clients.) The above seems to relate to information disclosure to third-parties. >Should "http://www.mipassoc.org/arf/" in the examples be replaced >with something with like the first http link above? (Should the spec >RECOMMEND that the meaning of fields is stated that way?) It could be replaced with the RFC number. >In appendix B2, the Authentication-Results looks bogus. In addition, >the caption says "Example 3" rather than 2. The text about the example could precede the example to stand out. At 18:38 12-04-10, Yakov Shafranovich wrote: >In section 1.1: >Do we need to add something about end-user clients and their ISPs >communicating about spam as mentioned in the introduction? Kind of >like the "Report Spam" button in the MUA I don't think so. >In section 1.2: >Are we using "must" in its [KEYWORDS] context? No. The requirements are as from Section 2. >Section 3.1, "Version": >Should we change to "1" or "1.0" like MIME? It's not a good idea for this specification to take the same road as the MIME version. :-) According to the text, the version follows the specification, i.e. the integer is incremented. >Section 3.2, "Incidents": >The spec mentions several times before that multiple or aggregate >reports are not covered. Yet this field covers that. We need to insert >some text addressing that Item e in Section 2 defines that as out of scope. >Section 3.3, "Reported-Domain": >Should Reported-URI be encouraged instead, as per RFC 4501 and >"Reported-Domain" be historic > >Section 3.3, "Reported-URI": >Same text for the "Reported-Domain" field should apply to "URI" "Reported-Domain" could be dropped and "Reported-URI" used instead. >Section 3.5: >Are we mandating an specific order for fields? I don't see any mention of ordering in the draft. Would implementers assume that on reading the draft? >Section 5: >Isn't calling for experimental codes to be rejected a bit harsh? Also, >by "experimental result codes" - do you mean feedback types or >experimental fields? If extension types can only be used between consenting parties, I assume that the receiver of the ARF got an invalid or misdirected report. The sentence could be rewritten as: Extension report types beginning with "x-" MUST only be used between ADMDs that have explicitly consented to use them. >Sections 6-7: >Should we add some sort of status field that indicates whether a given >field or feedback type is historic, obsolete or in current use as per >above regarding "Received-Date"? The type would be marked as Obsolete. >Section 7: >This conflicts with what we wrote above regarding leaving <> usage to >the operator discretion Yes. The "must" may be misinterpreted. >Section 7.5: - I would even add that people may attach viruses or >malware to ARF reports, but at the same time, since ARF messages may >be used to report viruses, they may contain them by design. We might >want to say that viruses and malware may be carried in ARF reports, so >people should exercise caution. On the other hand, they should not >reject reports containing viruses since they may be legit. It may fit under a new sub-section that discusses about payload. Regards, -sm From vesely@tana.it Tue Apr 13 02:49:23 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67AFC3A67A6 for ; Tue, 13 Apr 2010 02:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM6dhxYy-IMt for ; Tue, 13 Apr 2010 02:49:22 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 487893A6939 for ; Tue, 13 Apr 2010 02:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1271152147; bh=/nMa1v1RyECxClZM6mJJge/+V/TVhTCyvg6HdYsUJhc=; l=1001; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Wbq9kDzb01cnc2EVfO0xWXYwD2hUFT1dBFFcr5Uo9ftb/I3ZcYn3615B/zhr+T0dR Rkqe3MRN1rkTR+y+CPcVnJT5F66PizMd/HiP3DwiOQGy7vHX0nvs6UXeYquAozhgUh X9M8MH0+4AsoUG2rehv1EmGqhZt8/xY6V8cCGrs4= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 13 Apr 2010 11:49:07 +0200 id 00000000005DC038.000000004BC43E13.000019B4 Message-ID: <4BC43E13.2050508@tana.it> Date: Tue, 13 Apr 2010 11:49:07 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <6.2.5.6.2.20100412232912.09587f80@resistor.net> In-Reply-To: <6.2.5.6.2.20100412232912.09587f80@resistor.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 09:49:23 -0000 On 13/Apr/10 10:08, SM wrote: >> Should "http://www.mipassoc.org/arf/" in the examples be replaced with >> something with like the first http link above? (Should the spec >> RECOMMEND that the meaning of fields is stated that way?) > > It could be replaced with the RFC number. However, for some field it "is unspecified how the report generator determines this information, and thus the report receiver cannot be certain how it was chosen." It may be helpful if each implementation gives full details on fields that the RFC describes as implementation-defined behavior. >> Section 3.5: >> Are we mandating an specific order for fields? > > I don't see any mention of ordering in the draft. Would implementers > assume that on reading the draft? Section 3.5 says A set of fields satisfying this ABNF may appear in the transmitted message in any order. I agree the spec would be more readable if a similar sentence appeared also near the beginning of section 3. From shmuel+gen@patriot.net Tue Apr 13 06:02:26 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614793A6A2B for ; Tue, 13 Apr 2010 06:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_60=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSFyMWygLe8R for ; Tue, 13 Apr 2010 06:02:25 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 5DB783A6B16 for ; Tue, 13 Apr 2010 06:02:13 -0700 (PDT) Received: from ECS35455305 (core-dc-1-240.dynamic-dialup.coretel.net [69.72.26.240]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id BF2D5F580A7 for ; Tue, 13 Apr 2010 09:00:47 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Tue, 13 Apr 2010 08:21:53 -0400 To: Message Abuse Report Format working group Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100413130048.BF2D5F580A7@smtp.patriot.net> Subject: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 13:02:26 -0000 If MARF is used to report a drop box, then the receiver will probably need to see the body of the original message before taking action. Should there be something like "MUST use message/rfc822 when reporting drop boxes."? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Tue Apr 13 10:19:54 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A80A3A6A4A for ; Tue, 13 Apr 2010 10:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF+g4iWpULJj for ; Tue, 13 Apr 2010 10:19:51 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 8D7833A67FF for ; Tue, 13 Apr 2010 10:19:46 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Tue, 13 Apr 2010 10:19:30 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Tue, 13 Apr 2010 10:19:29 -0700 Thread-Topic: [marf] WGLC starting for draft-ietf-marf-base-01 Thread-Index: AcrYDsK9cwut91S2TrOy21OY7u2tHADHWI/w Message-ID: References: <4BBF6B8D.1030901@tana.it> In-Reply-To: <4BBF6B8D.1030901@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:19:54 -0000 [as participant] > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Friday, April 09, 2010 11:02 AM > To: marf@ietf.org > Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 >=20 > "Reported-Domain" is unspecified by design. Fine :-( However, it is > not clear whether it may appear multiple times even if the report > covers a single incident. I disagree. It's clearly in the "Optional Fields Appearing Multiple Times"= section. > As for using "Reported-URI" for the spamvertized mailbox, I just note > that IODEF's draft-cain-post-inch-phishingextns (now in LC) calls that > "Collection Site". The phrase "a URI to which the report recipient can > go for further details", instead, suggests something like >=20 > http://example.com/arf-generators/XYZ-v1.04b/meaning-of-fields.html I think I agree that this is somewhat ambiguous. To those who are using AR= F now: How do you use this field? Is it a URI found in the offending messa= ge, or is it a reference URI for further action by the ARF recipient? If t= he latter, it is probably mis-named. If it could be either, I suspect the = text should indicate that the provided URI might and might not be taken fro= m the message. > I propose to replace that phrase with just "See next Section 3.4". > (Will there be an applicability statement to clarify how meanings may > be negotiated, eventually?) Do you have text to propose? :-) > Section 7.3 still says "MAIL FROM:<>". See the end of > http://www.ietf.org/mail-archive/web/marf/current/msg00641.html Ah right. I'll remove 7.3. > Should the security section mention that automatically forwarding an > abuse report to the wrong party may leak sensible information, > especially if the report had been inadvertently generated by a user? > (The intro says something about supporting mail clients.) Isn't that true of any email? > Should "http://www.mipassoc.org/arf/" in the examples be replaced with > something with like the first http link above? (Should the spec > RECOMMEND that the meaning of fields is stated that way?) As it's just an example, I don't think this is a critical change. What mig= ht be useful would be something in an earlier section RECOMMENDing the lead= ing text/plain section include a reference to a document decoding ARF messa= ges, at least during a rollout period. > In appendix B2, the Authentication-Results looks bogus. In addition, > the caption says "Example 3" rather than 2. Fixed. From msk@cloudmark.com Tue Apr 13 10:22:16 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429FE3A6A87 for ; Tue, 13 Apr 2010 10:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+lgaYRhgxNH for ; Tue, 13 Apr 2010 10:22:13 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 86D053A6A83 for ; Tue, 13 Apr 2010 10:21:55 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Tue, 13 Apr 2010 10:21:49 -0700 From: "Murray S. Kucherawy" To: "J.D. Falk" , Message Abuse Report Format working group Date: Tue, 13 Apr 2010 10:21:49 -0700 Thread-Topic: [marf] WGLC starting for draft-ietf-marf-base-01 Thread-Index: AcradliLMckKsQW1QdiK+wn1drT7wAAt2Fiw Message-ID: References: <4BBF6B8D.1030901@tana.it> <4FA3A0BB-560E-4382-9326-F5D9F6FE7CEA@cybernothing.org> In-Reply-To: <4FA3A0BB-560E-4382-9326-F5D9F6FE7CEA@cybernothing.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:22:16 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > J.D. Falk > Sent: Monday, April 12, 2010 12:28 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 >=20 > Reported-URI should be a URI copied from (or perhaps derived from) the > message being reported. It's not intended for documentation about the > report itself. How about this (pardon the XML and indenting)? "Reported-URI" indicates a URI that the report generator believes to be relevan= t to the report, e.g. a suspect URI that = was found in the message that caused the re= port to be generated. URI format is defined in . From msk@cloudmark.com Tue Apr 13 10:50:32 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C7B3A6A26 for ; Tue, 13 Apr 2010 10:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtKCt11lAqhU for ; Tue, 13 Apr 2010 10:50:31 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 65CA53A69BE for ; Tue, 13 Apr 2010 10:50:31 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Tue, 13 Apr 2010 10:50:25 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich , "marf@ietf.org" Date: Tue, 13 Apr 2010 10:50:24 -0700 Thread-Topic: [marf] WGLC starting for draft-ietf-marf-base-01 Thread-Index: AcraqipGhhWhSjxMRSqjdEKHU+7+zAAg9r/A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:50:32 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Monday, April 12, 2010 6:39 PM > To: marf@ietf.org > Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 >=20 > In section 1.1: > Do we need to add something about end-user clients and their ISPs > communicating about spam as mentioned in the introduction? Kind of > like the "Report Spam" button in the MUA I think that's generally included in the second bullet point of 1.1, but I = wouldn't mind being more explicit about it, especially the "Report Spam" bu= tton idea. The ASRG recently had a huge thread about that specific topic. > In section 1.2: > Are we using "must" in its [KEYWORDS] context? Not at that point. We're just describing the impetus for the work, not est= ablishing normative compliance requirements. > In section 3.1: > "The following report header fields MUST appear exactly once:" >=20 > should we add >=20 > "...exactly once in no particular order" or "...exactly once with no > particular order dictated by this specifiction" >=20 > Same for sections 3.2 and 3.3 The absence of an order seems to say both of those things to me anyway, but= if people feel it should be explicitly stated, we can add it. > Section 3.1, "Version": > Should we change to "1" or "1.0" like MIME? I don't think it's necessary. DKIM and Authentication-Results use integer = versions. Do people have a preference? > Section 3.2, "Incidents": > The spec mentions several times before that multiple or aggregate > reports are not covered. Yet this field covers that. We need to insert > some text addressing that ...or remove the text that conflicts with this field. I'd prefer to do th= e latter; there's some drive in industry to have this capability. Section 2 point e says "Except as noted below...", which allows for Inciden= ts as defined. Are there other references to this issue that need to be "s= moothed"? > Section 3.2, "Received-Date": > Provisions needs to be made in the IANA registry that fields can be > marked as historic. How about this in the IANA section describing the field registry? An update may make a notation on an existing registration indicating that a registered field is historic or deprecated if appropriate. > Section 3.3, "Reported-Domain": > Should Reported-URI be encouraged instead, as per RFC 4501 and > "Reported-Domain" be historic I think both are still in use. What's consensus here? > Section 3.3, "Reported-URI": > Same text for the "Reported-Domain" field should apply to "URI" Done. > Section 3.5: > Are we mandating an specific order for fields? I don't think so. > Section 5: > Isn't calling for experimental codes to be rejected a bit harsh? Also, > by "experimental result codes" - do you mean feedback types or > experimental fields? The text that's there was required by the SECDIR review of RFC5451. I'm ju= st heading them off at the pass. > Section 7.5: - I would even add that people may attach viruses or > malware to ARF reports, but at the same time, since ARF messages may > be used to report viruses, they may contain them by design. We might > want to say that viruses and malware may be carried in ARF reports, so > people should exercise caution. On the other hand, they should not > reject reports containing viruses since they may be legit. How's this?
As this format is sometimes used to automatical= ly report malware, ARF processors (human or otherw= ise) should be cautious about unpacking and executin= g any attachments that are part of the message being reported.
From msk@cloudmark.com Tue Apr 13 11:06:07 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9333A6A61 for ; Tue, 13 Apr 2010 11:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-nNhZ44Bnom for ; Tue, 13 Apr 2010 11:06:06 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 7849F3A6A64 for ; Tue, 13 Apr 2010 11:06:06 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Tue, 13 Apr 2010 11:06:00 -0700 From: "Murray S. Kucherawy" To: SM , "marf@ietf.org" Date: Tue, 13 Apr 2010 11:05:59 -0700 Thread-Topic: [marf] WGLC starting for draft-ietf-marf-base-01 Thread-Index: Acra4L6+AYnQOGxFQLWW6KraxSwwvQAUhsZg Message-ID: References: <6.2.5.6.2.20100412232912.09587f80@resistor.net> In-Reply-To: <6.2.5.6.2.20100412232912.09587f80@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:06:08 -0000 > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Tuesday, April 13, 2010 1:08 AM > To: marf@ietf.org > Cc: Murray S. Kucherawy; Alessandro Vesely; Yakov Shafranovich > Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 >=20 > At 12:11 06-04-10, Murray S. Kucherawy wrote: > >Working Group Last Call for draft-ietf-marf-base-02 is now in > >effect, lasting for two >=20 > There is a typo for "original" in Section 2, Item d. Fixed. > In Section 5: >=20 > Result codes not beginning with "x-" MUST be registered as > described above and appropriately published. >=20 > Is that for feedback report types? What is the meaning of > "appropriately published"? I've reworked that section a little now. The new text is: Like many other formats and protocols, this format may need to be extended over time to fit the ever changing landscape of the Internet. Therefore, extensibility is provided via two IANA registries: one for feedback type= s and a second for report header fields. The feedback ty= pe registry is to be used in conjunction with the "Feedback-Type" field above. The header name registry = is intended for registration of new meta-data fields to be used in the machine readable portion (part 2) of this format. Please note that version numbers do not change with new field registrations unless a new specification of this format is published. Also note t= hat all new field registrations may only be registered as optional fields. Any new required fields REQUIRE a new version of this specification to be published. In order to encourage extensibility and interoperabilit= y of this format, implementors MUST ignore any fields or report types they do not explicitly support. Additional report types (extension report types) or report header fields might be defined in the future by later revisions to this specification, or by registrations as described above. Extension report typ= es and report header field names beginning with "x-" will never be defined as standard; such names are reserved f= or experimental use. Report types and report header field names not beginning with "x-" MUST be registered as described above and published in an RFC. Implementations using new report types or new report header fields MUST use the "x-" prefix until such time = as the new name is registered by IANA. Extension report types and report header fields MUST on= ly be used between ADMDs that have explicitly consented to use them. These names and the parameters associated wi= th them are not documented in RFCs. Therefore, they are subject to change at any time and not suitable for gene= ral use. Any MTA, MUA or filter intended for production us= e MUST ignore or reject any ARF report that uses an extension name. > The example in B.1 has the "From:" before the "Received:" header field. That's not technically illegal, is it? But I'll swap them. From msk@cloudmark.com Tue Apr 13 11:08:31 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08DC3A69F3 for ; Tue, 13 Apr 2010 11:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRrIQjRNKUVp for ; Tue, 13 Apr 2010 11:08:30 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 4BD063A67FB for ; Tue, 13 Apr 2010 11:08:30 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Tue, 13 Apr 2010 11:08:24 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Tue, 13 Apr 2010 11:08:23 -0700 Thread-Topic: [marf] WGLC starting for draft-ietf-marf-base-01 Thread-Index: Acra7pc8LCoKNLunQ2qvz+yDkrMNxgARXMIg Message-ID: References: <6.2.5.6.2.20100412232912.09587f80@resistor.net> <4BC43E13.2050508@tana.it> In-Reply-To: <4BC43E13.2050508@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:08:32 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Tuesday, April 13, 2010 2:49 AM > To: marf@ietf.org > Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 >=20 > On 13/Apr/10 10:08, SM wrote: > >> Should "http://www.mipassoc.org/arf/" in the examples be replaced > with > >> something with like the first http link above? (Should the spec > >> RECOMMEND that the meaning of fields is stated that way?) > > > > It could be replaced with the RFC number. >=20 > However, for some field it "is unspecified how the report generator > determines this information, and thus the report receiver cannot be > certain how it was chosen." It may be helpful if each implementation > gives full details on fields that the RFC describes as > implementation-defined behavior. The field you're talking about here is the first MIME part, which is text/p= lain and free-form. We can't mandate its content, but can make suggestions= about it. > >> Section 3.5: > >> Are we mandating an specific order for fields? > > > > I don't see any mention of ordering in the draft. Would implementers > > assume that on reading the draft? >=20 > Section 3.5 says >=20 > A set of fields satisfying this ABNF may appear in the transmitted > message in any order. >=20 > I agree the spec would be more readable if a similar sentence appeared > also near the beginning of section 3. The absence of a specification of order to me is an implicit statement that= order is not important. Do others feel that this needs to be explicit? From sm@resistor.net Tue Apr 13 11:56:55 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD17A3A68F3 for ; Tue, 13 Apr 2010 11:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlUbFkpjRvMZ for ; Tue, 13 Apr 2010 11:56:54 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 099F63A68C8 for ; Tue, 13 Apr 2010 11:56:53 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o3DIuM7K025422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 11:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1271185006; x=1271271406; bh=T9cWkfae5zdWknet2t0kyi6C+O40nfcPFoEJ6t3ezc0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ETtxSyWdWMDqq6SN5usfplnHjomjcoK18AW+90O0oiDn4Z98y9mqIvUadu3AL7uPk 1c9EXS3DvO1heQa27l8IE1ngKiD9hhsQ/2PJtfZSUZ7HaQc738iIREa+Kz22fzV9UL aDumGfrOsg1E0uob3RTQAL9uuEDre0g4Kkokj0VU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1271185006; x=1271271406; bh=T9cWkfae5zdWknet2t0kyi6C+O40nfcPFoEJ6t3ezc0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=NZwPOTX2vcqCO2DbyMb3Oqks24jkhG6KXDE+0YBypjjwIIIY0zTe8cwvz4tVvypQn g1JzK/RzgCHG0F53w0ID1QGstdNhhGa4+XDQzPQutuUdaNg5ChADOa29VsvnPn0vSN 3Utp5dlvmuKTVhvuuZmrGVpKOZ0UcDbUVPcj2qYI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=FEYzfapB/OV3xLWcLW8cK9zsiFRF80/xGe0yOisHv2IQ9UXJCbhJDTlz6qOhx9DvI Qxgtu6YZNQ8GzDzg14/RkqxT+LMNgiIXuUlFGhaTmG3zc9lxOfDuOy0jxAzBxC2O3n0 nuPz2JYPPLJpoZvYBQ4JFRLtL/SxD1ZVnApN0wY= Message-Id: <6.2.5.6.2.20100413111240.08c9ed40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Apr 2010 11:28:11 -0700 To: Alessandro Vesely From: SM In-Reply-To: <4BC43E13.2050508@tana.it> References: <6.2.5.6.2.20100412232912.09587f80@resistor.net> <4BC43E13.2050508@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:56:55 -0000 Hi Alessandro, At 02:49 13-04-10, Alessandro Vesely wrote: >Section 3.5 says > > A set of fields satisfying this ABNF may appear in the transmitted > message in any order. I missed that. :-) >I agree the spec would be more readable if a similar sentence >appeared also near the beginning of section 3. "The body of this content type consists of multiple "fields" formatted according to the ABNF of [MAIL] header fields. The header fields may appear in the transmitted message in any order." The "A set of fields satisfying this ABNF may appear in the transmitted message in any order." could be removed. BTW, even without this, I would not presume that the fields should be in any order. Regards, -sm From sm@resistor.net Tue Apr 13 11:57:02 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E5E28C145 for ; Tue, 13 Apr 2010 11:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hWzcbMkHUvw for ; Tue, 13 Apr 2010 11:57:01 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 5839228C11A for ; Tue, 13 Apr 2010 11:57:01 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o3DIuM7M025422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 11:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1271185014; x=1271271414; bh=YCIdbtPw6JKD1tDUSsC2k00P02wbg5hKaW6uPRSaRc8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=h6BwO/1FhJlMfGIrGWyGG/Ipu6zLBUycFwEEQdbGLNWAWLG5kdEi2btySGB6KEnSF HCFysZDy1KXKjUG1cNkKVrOWQBbwVfqlZl70/pTTGOOS/AdCT6wmBF5EiOixSntbV/ /fjUNWz/8NttXbXDnBc0uT3rKT2DT5er6J1MgRbw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1271185014; x=1271271414; bh=YCIdbtPw6JKD1tDUSsC2k00P02wbg5hKaW6uPRSaRc8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=4GOBWe8NRrZfY3JoJD8hBBK76oX2URPJZ/cVJudlDzhWCXf48IrUaCOKBio24Z1A1 68LMzmkXr264DSFmn7sh1pZFPhqQ1Mou/qUFHmU7G7Ll85ds0DFkM3gwBD90+Ll6O3 sMhfTojRFnn1FU1yZAJwRRdch3UOrO7XgG8m8Rm0= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=Mcz0yj1QYCW0xNATf3cPB5Ey8HytcPuCrPDcSJWdWl1kYJvQCgXOtUFlItS83hkJl WYAJP2ytsPIMqLRs/T/aseI64euny+27+4Khnf7o2sWC6zwt7Jw17MHbKd9kYoJhsIg 0LHnkvMvGzFHU93NqDV7In7jvlNWxxx7K5fDY4U= Message-Id: <6.2.5.6.2.20100413113000.08c9f718@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Apr 2010 11:52:57 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:57:02 -0000 At 10:50 13-04-10, Murray S. Kucherawy wrote: > > Section 3.3, "Reported-Domain": > > Should Reported-URI be encouraged instead, as per RFC 4501 and > > "Reported-Domain" be historic > >I think both are still in use. What's consensus here? Choose one and avoid getting into historic as it's difficult to get rid of. > > Section 7.5: - I would even add that people may attach viruses or > > malware to ARF reports, but at the same time, since ARF messages may > > be used to report viruses, they may contain them by design. We might > > want to say that viruses and malware may be carried in ARF reports, so > > people should exercise caution. On the other hand, they should not > > reject reports containing viruses since they may be legit. > >How's this? > >
> As this format is sometimes used to automatically > report malware, ARF processors (human > or otherwise) > should be cautious about unpacking and executing > any attachments that are part of the message > being reported. >
How about: Malware ARF processors (human or otherwise) should be cautious about executing any content when the original message is included in its entirety. Regards, -sm From msk@cloudmark.com Tue Apr 13 12:02:54 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14063A6A69 for ; Tue, 13 Apr 2010 12:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EepMprzopRbZ for ; Tue, 13 Apr 2010 12:02:51 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 733223A6A4F for ; Tue, 13 Apr 2010 12:02:48 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Tue, 13 Apr 2010 12:02:42 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 13 Apr 2010 12:02:41 -0700 Thread-Topic: [marf] Require body? Thread-Index: AcrbCY6qRrGHMHRMSbOHfpXXE+ReyAAMjuMw Message-ID: References: <20100413130048.BF2D5F580A7@smtp.patriot.net> In-Reply-To: <20100413130048.BF2D5F580A7@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 19:02:55 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Shmuel Metz > Sent: Tuesday, April 13, 2010 5:22 AM > To: Message Abuse Report Format working group > Subject: [marf] Require body? >=20 > If MARF is used to report a drop box, then the receiver will probably > need > to see the body of the original message before taking action. Should > there > be something like "MUST use message/rfc822 when reporting drop boxes."? I'm unclear on how this would fit into the current ARF specification. Isn'= t drop box reporting out of scope for the base draft? From johnl@iecc.com Tue Apr 13 12:35:48 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BCA28C141 for ; Tue, 13 Apr 2010 12:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.199 X-Spam-Level: X-Spam-Status: No, score=-11.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6ZRJ+exjih6 for ; Tue, 13 Apr 2010 12:35:47 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 0BFFC28C131 for ; Tue, 13 Apr 2010 12:35:46 -0700 (PDT) Received: (qmail 46038 invoked from network); 13 Apr 2010 19:35:39 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 13 Apr 2010 19:35:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1004; olt=johnl@user.iecc.com; bh=cY90cnAzgfeJZtP5OqRg1na7YskyM+BNocXLnv+wJX8=; b=Ra2EqZRU/aqeqRKOtwQqZ+DVoslTyGASG1JEQpNOp5M4Yp6HH4UaSL7bmz1UTqjouM16wiyPGdfe8r+GmDM2bwgsk/iA1SgtJwGlH5qSu9QP6m0xsvBMSUnu9XWH2BpFjVw3qgYyfRHV1KNr+S/pbOh3prn+3+KLZaySSnViC0M= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1004; bh=cY90cnAzgfeJZtP5OqRg1na7YskyM+BNocXLnv+wJX8=; b=k7O22vED5RJS0eiyqWmugTcCA7M1PcJdRMiu+9uM7UkCHxB7W9ZWPJoVqRQvOx7cOo203i4+2rbX9oM26MSVQDGTWW2nkpSj1N/55K0114w4R/yqS6SZ7G1g0twGeIMbfHYH8xWQ9MxcILo6vD8dqDrX3Q4Pm/OYkyLDJtCNBmQ= Date: 13 Apr 2010 19:35:38 -0000 Message-ID: <20100413193538.70842.qmail@simone.iecc.com> From: John Levine To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 19:35:48 -0000 >> be something like "MUST use message/rfc822 when reporting drop boxes."? >I'm unclear on how this would fit into the current ARF specification. >Isn't drop box reporting out of scope for the base draft? You could send an ARF report with the reported URL being mailto:drop@box. But a MUST puts us back into King Canute land. ISPs will redact what they want to redact, and there's nothing we can do about it. This suggests that no changes are needed to handle drop boxes. R's, John From sm@resistor.net Tue Apr 13 14:03:14 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE853A6ABF for ; Tue, 13 Apr 2010 14:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SAWD5F4qMvt for ; Tue, 13 Apr 2010 14:03:13 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 39A9B3A67F0 for ; Tue, 13 Apr 2010 14:03:12 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o3DL2tUB019866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 14:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1271192584; x=1271278984; bh=SJQeADhVXY8sMAD4cflUMQB0z8ni/l1q9WeeqDOGjds=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=lJMP8ZJ+08YZ4MOCpb+SQi0gA3XA8f3joe4f75Pk6dDULIJiC8icTdQgbImK3rYuL PQBF9zOZ0xZiUY9pcQ9r3LekU5vx554JNzksIVrWQ5f+IsekZsF3UVC/FLUtWqgaUy z4laSEGS74K9MFrzJUU8srugkGDfmGGq39Jn7u8A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1271192584; x=1271278984; bh=SJQeADhVXY8sMAD4cflUMQB0z8ni/l1q9WeeqDOGjds=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=igw4ulReXe6ArT15sMcMBXEhjtX5sBC9r+rJwzlqgM9l+7BdYjBXPDF4lRMF/yhQ3 Cypayz+PjfslqwqgOv0VKx6BmzFO5VwP2z1EEKh93G/x57wSPlzbYy7lPUauEfdav5 WejH5Sa7lF8ChJTVnbJ2dqQXYu6Btmku9ZT9lkac= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=mxx1Ds5WD8PkgswhYX8hT7vvOrUtor5ipoAGDB9QS3Q2qGDFj2V4141/Dzoi9lI5G ySou2/en/ktfcNa+KeWj8Hh/pSqLAfX9Fw3EYJdwSOJeswrJIhJFwRRoqIsIm7acj2M gGwIkjo992eXMT7QRtwNbs7KfL/9CBlxwNYSdI8= Message-Id: <6.2.5.6.2.20100413124425.08802cb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Apr 2010 13:56:21 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <6.2.5.6.2.20100412232912.09587f80@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 21:03:14 -0000 Hi Murray, At 11:05 13-04-10, Murray S. Kucherawy wrote: >I've reworked that section a little now. The new text is: > > Like many other formats and protocols, this format may > need to be extended over time to fit the ever changing > landscape of the Internet. Therefore, extensibility is > provided via two IANA registries: one for feedback types > and a second for report header fields. The feedback type > registry is to be used in conjunction with the > "Feedback-Type" field above. The header name registry is > intended for registration of new meta-data fields to be > used in the machine readable portion (part 2) of this > format. Please note that version numbers do not > change with new field registrations unless a new > specification of this format is > published. Also note that > all new field registrations may only be registered as > optional fields. Any new required fields REQUIRE a new > version of this specification to be published. This is more of a comment to get a clearer view. We have two types of Report Header Fields, those that are required and those that are optional. The optional header fields can be used to extend ARF. The Version number is incremented if we change the list of required header fields or if we define new feedback types. This required a revision of this specification. > In order to encourage extensibility and interoperability > of this format, implementors MUST ignore any fields or > report types they do not explicitly support. Ok. > Additional report types (extension report types) or > report header fields might be defined in the future by > later revisions to this specification, or by > registrations as described above. Extension report types > and report header field names beginning with "x-" will > never be defined as standard; such names are reserved for > experimental use. Report types and report header field > names not beginning with "x-" MUST be registered as > described above and published in an RFC. > > Implementations using new report types or new report > header fields MUST use the "x-" prefix until such time as > the new name is registered by IANA. You already reserved "x-" for experimental use. I suggest dropping the requirement that implementations must use "x-". You could change the end of the previous paragraph to: Extension report types and report header field names beginning with "x-" will never be registered in the "Feedback Report Header Fields" registry or the "Feedback Report Type Values" registry; such names are reserved for experimental use. Report types and report header field names must be registered as described in this memo and published in an RFC. This does not IETF review; it's only a "RFC Required". This leaves it to implementors to extend ARF without setting the bar too high. > Extension report types and report header fields MUST only > be used between ADMDs that have explicitly consented to > use them. These names and the parameters associated with > them are not documented in RFCs. Therefore, they are > subject to change at any time and not suitable > for general > use. Any MTA, MUA or filter intended for production use > MUST ignore or reject any ARF report that uses an > extension name. We are interpreting extensibility differently. The above seems to refer to "x-". That can be used between ADMDs that have explicitly consented to it. I suggest dropping this paragraph as it has already been covered by other text. >That's not technically illegal, is it? But I'll swap them. It is not compliant with the RFC 5321. Regards, -sm From yakov@shaftek.org Tue Apr 13 14:50:07 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5492D3A6A2E for ; Tue, 13 Apr 2010 14:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeF8Xo7Tu5fN for ; Tue, 13 Apr 2010 14:50:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2ED433A685B for ; Tue, 13 Apr 2010 14:50:06 -0700 (PDT) Received: by wwb24 with SMTP id 24so888829wwb.31 for ; Tue, 13 Apr 2010 14:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.7.1 with HTTP; Tue, 13 Apr 2010 14:49:36 -0700 (PDT) In-Reply-To: <20100413193538.70842.qmail@simone.iecc.com> References: <20100413193538.70842.qmail@simone.iecc.com> From: Yakov Shafranovich Date: Tue, 13 Apr 2010 17:49:36 -0400 Received: by 10.216.86.7 with SMTP id v7mr3915735wee.191.1271195396152; Tue, 13 Apr 2010 14:49:56 -0700 (PDT) Message-ID: To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 21:50:07 -0000 I would add that this may be something more suitable for a followup RFC discussing best practices. On Tue, Apr 13, 2010 at 3:35 PM, John Levine wrote: >>> be something like "MUST use message/rfc822 when reporting drop boxes."? > >>I'm unclear on how this would fit into the current ARF specification. >>Isn't drop box reporting out of scope for the base draft? > > You could send an ARF report with the reported URL being mailto:drop@box. > > But a MUST puts us back into King Canute land. =A0ISPs will redact what > they want to redact, and there's nothing we can do about it. =A0This > suggests that no changes are needed to handle drop boxes. > > R's, > John > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From msk@cloudmark.com Tue Apr 13 14:55:37 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE6928C1DA for ; Tue, 13 Apr 2010 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY+aOrIQbhRz for ; Tue, 13 Apr 2010 14:55:36 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id F0FAA28C1F6 for ; Tue, 13 Apr 2010 14:54:16 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Tue, 13 Apr 2010 14:54:11 -0700 From: "Murray S. Kucherawy" To: SM Date: Tue, 13 Apr 2010 14:54:09 -0700 Thread-Topic: [marf] WGLC starting for draft-ietf-marf-base-01 Thread-Index: AcrbTLdo/suLA8KtTde4YCAC5hwaBwABnj5A Message-ID: References: <6.2.5.6.2.20100412232912.09587f80@resistor.net> <6.2.5.6.2.20100413124425.08802cb8@resistor.net> In-Reply-To: <6.2.5.6.2.20100413124425.08802cb8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 21:55:37 -0000 > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Tuesday, April 13, 2010 1:56 PM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: RE: [marf] WGLC starting for draft-ietf-marf-base-01 >=20 > > Additional report types (extension report types) > or > > report header fields might be defined in the > future by > > later revisions to this specification, or by > > registrations as described above. Extension > report types > > and report header field names beginning with "x-" > will > > never be defined as standard; such names are > reserved for > > experimental use. Report types and report header > field > > names not beginning with "x-" MUST be registered > as > > described above and published in an RFC. > > > > Implementations using new report types or new > report > > header fields MUST use the "x-" prefix until such > time as > > the new name is registered by IANA. >=20 > You already reserved "x-" for experimental use. I suggest dropping > the requirement that implementations must use "x-". SECDIR had a concern in the past that this text be required, even though el= sewhere there's guidance that unknown fields should be ignored. I'm hesita= nt to remove it as they might push to have it re-added anyway, and I don't = think it's harmful to have it there. I hear your point about making it a barrier to entry though. What do others think? From jdfalk-lists@cybernothing.org Tue Apr 13 15:00:42 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7825428C135 for ; Tue, 13 Apr 2010 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duBsMT6PAR5j for ; Tue, 13 Apr 2010 15:00:41 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 4685D28C203 for ; Tue, 13 Apr 2010 14:59:58 -0700 (PDT) Received: from [10.0.2.94] (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3DLxoth007622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Apr 2010 15:59:51 -0600 References: <4BBF6B8D.1030901@tana.it> <4FA3A0BB-560E-4382-9326-F5D9F6FE7CEA@cybernothing.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <6D1084C1-BBE2-4721-B5BD-FC20D288986F@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 13 Apr 2010 15:59:44 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 22:00:42 -0000 On Apr 13, 2010, at 11:21 AM, Murray S. Kucherawy wrote: >> Reported-URI should be a URI copied from (or perhaps derived from) = the >> message being reported. It's not intended for documentation about = the >> report itself. >=20 > How about this (pardon the XML and indenting)? >=20 > "Reported-URI" indicates a URI that = the > report generator believes to be = relevant > to the report, e.g. a suspect URI = that was > found in the message that caused = the report > to be generated. URI format is = defined > in . Yup, works for me. Good catch, Alessandro -- I hadn't considered that = "relevant to the report" might be interpreted as a link to help text. On Apr 13, 2010, at 2:08 AM, SM wrote: >> Section 3.2, "Incidents": >> The spec mentions several times before that multiple or aggregate >> reports are not covered. Yet this field covers that. We need to = insert >> some text addressing that >=20 > Item e in Section 2 defines that as out of scope. The intention, IIRC, was to avoid having to deal with multiple = message/rfc822 attachments. >> Section 3.5: >> Are we mandating an specific order for fields? >=20 > I don't see any mention of ordering in the draft. Would implementers = assume that on reading the draft? Some have, but they quickly discover their mistake. On Apr 13, 2010, at 3:54 PM, Murray S. Kucherawy wrote: >> You already reserved "x-" for experimental use. I suggest dropping >> the requirement that implementations must use "x-". >=20 > SECDIR had a concern in the past that this text be required, even = though elsewhere there's guidance that unknown fields should be ignored. = I'm hesitant to remove it as they might push to have it re-added = anyway, and I don't think it's harmful to have it there. >=20 > I hear your point about making it a barrier to entry though. >=20 > What do others think? There's enough precedent for X- from other standards that I'd prefer to = keep it, even if it isn't strictly necessary. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Tue Apr 13 15:04:19 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF1B3A67B4 for ; Tue, 13 Apr 2010 15:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67Mbjr-wPX1C for ; Tue, 13 Apr 2010 15:04:19 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id B10A828C145 for ; Tue, 13 Apr 2010 15:04:17 -0700 (PDT) Received: from [10.0.2.94] (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3DM49b3007864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Apr 2010 16:04:11 -0600 References: <20100413130048.BF2D5F580A7@smtp.patriot.net> In-Reply-To: <20100413130048.BF2D5F580A7@smtp.patriot.net> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <15BD52CB-6F1B-494A-ACE9-CDA1276AAEB9@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 13 Apr 2010 16:04:04 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 22:04:19 -0000 On Apr 13, 2010, at 6:21 AM, Shmuel (Seymour J.) Metz wrote: > If MARF is used to report a drop box, then the receiver will probably = need > to see the body of the original message before taking action. Should = there > be something like "MUST use message/rfc822 when reporting drop = boxes."? This is getting awfully close to dictating how the report recipient = manages their network. The format -- which is all we're defining here = -- doesn't care if they want to disable an account based on flimsy = evidence. I wouldn't argue too vociferously against a SHOULD, but I think it's = unnecessary. -- J.D. Falk Return Path Inc From shmuel+gen@patriot.net Thu Apr 15 03:07:40 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9540F3A6B7A for ; Thu, 15 Apr 2010 03:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_50=0.001, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNAqN8+2QnHL for ; Thu, 15 Apr 2010 03:07:39 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 99D823A6A85 for ; Thu, 15 Apr 2010 03:07:39 -0700 (PDT) Received: from ECS35455305 (core-dc-1-189.dynamic-dialup.coretel.net [69.72.26.189]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 18372F5808A for ; Thu, 15 Apr 2010 06:06:09 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 14 Apr 2010 05:46:02 -0400 To: marf@ietf.org In-Reply-To: <15BD52CB-6F1B-494A-ACE9-CDA1276AAEB9@cybernothing.org> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100415100610.18372F5808A@smtp.patriot.net> Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 10:07:40 -0000 In <15BD52CB-6F1B-494A-ACE9-CDA1276AAEB9@cybernothing.org>, on 04/13/2010 at 04:04 PM, "J.D. Falk" said: >This is getting awfully close to dictating how the report recipient >manages their network. It would be a requirement on the sender, not on the recipient. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Thu Apr 15 03:07:43 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8140828C10A for ; Thu, 15 Apr 2010 03:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_50=0.001, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6oOlDx2rPkF for ; Thu, 15 Apr 2010 03:07:42 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id B7D5228C105 for ; Thu, 15 Apr 2010 03:07:42 -0700 (PDT) Received: from ECS35455305 (core-dc-1-189.dynamic-dialup.coretel.net [69.72.26.189]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id A6665F5808A for ; Thu, 15 Apr 2010 06:06:12 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 14 Apr 2010 05:41:30 -0400 To: marf@ietf.org In-Reply-To: <6.2.5.6.2.20100413124425.08802cb8@resistor.net> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100415100613.A6665F5808A@smtp.patriot.net> Subject: Re: [marf] WGLC starting for draft-ietf-marf-base-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 10:07:43 -0000 In <6.2.5.6.2.20100413124425.08802cb8@resistor.net>, on 04/13/2010 at 01:56 PM, SM said: >It is not compliant with the RFC 5321. Technically it is not a violation for a message to have a From: prior to the first Received: line. As a practical matter, the message will almost always have passed through at least one SMTP server, in which case 4.4 of RFC 5321 would apply. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Thu Apr 15 03:07:48 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A9728C153 for ; Thu, 15 Apr 2010 03:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.183 X-Spam-Level: * X-Spam-Status: No, score=1.183 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_50=0.001, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWha9LjD5vNh for ; Thu, 15 Apr 2010 03:07:47 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 135F128C15B for ; Thu, 15 Apr 2010 03:07:46 -0700 (PDT) Received: from ECS35455305 (core-dc-1-189.dynamic-dialup.coretel.net [69.72.26.189]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 18680F5808A for ; Thu, 15 Apr 2010 06:06:15 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 14 Apr 2010 05:32:21 -0400 To: marf@ietf.org In-Reply-To: <20100413193538.70842.qmail@simone.iecc.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100415100617.18680F5808A@smtp.patriot.net> Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 10:07:48 -0000 In <20100413193538.70842.qmail@simone.iecc.com>, on 04/13/2010 at 07:35 PM, John Levine said: >You could send an ARF report with the reported URL being mailto:drop@box. Yes, but would an ISP pay attention to it if it did not contain the message body with that URL? >But a MUST puts us back into King Canute land. Doesn't that describe sending a complaint without supporting evidence? >ISPs will redact what they want to redact, Sure, but an RFC can describe what is compliant with that RFC. Would an ISP be willing to act on a drop-box complaint if it were unable to see the drop box in the context of the message purportedly containing it? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Thu Apr 15 03:07:50 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8833628C175 for ; Thu, 15 Apr 2010 03:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.192 X-Spam-Level: * X-Spam-Status: No, score=1.192 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_50=0.001, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id surUkFBWAsTA for ; Thu, 15 Apr 2010 03:07:49 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id A07B628C171 for ; Thu, 15 Apr 2010 03:07:49 -0700 (PDT) Received: from ECS35455305 (core-dc-1-189.dynamic-dialup.coretel.net [69.72.26.189]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 9A85AF5808A for ; Thu, 15 Apr 2010 06:06:19 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 14 Apr 2010 05:26:44 -0400 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100415100620.9A85AF5808A@smtp.patriot.net> Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 10:07:50 -0000 In , on 04/13/2010 at 12:02 PM, "Murray S. Kucherawy" said: >I'm unclear on how this would fit into the current ARF specification. >Isn't drop box reporting out of scope for the base draft? 1.1. Purpose includes the text "or related to"; that would appear to apply to drop boxes. If drop boxes are out of scope then 1.1 should be reworded to make the scope clearer. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Thu Apr 15 10:56:41 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64D13A6BC4 for ; Thu, 15 Apr 2010 10:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.241 X-Spam-Level: X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzTevDb20+B4 for ; Thu, 15 Apr 2010 10:56:41 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id F103F3A69B8 for ; Thu, 15 Apr 2010 10:56:40 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 15 Apr 2010 10:56:34 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 15 Apr 2010 10:56:33 -0700 Thread-Topic: [marf] Require body? Thread-Index: Acrcg37HpXdEPnY+QK+YEGOIOIk7aAAQVs9Q Message-ID: References: <20100415100620.9A85AF5808A@smtp.patriot.net> In-Reply-To: <20100415100620.9A85AF5808A@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 17:56:42 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Shmuel Metz > Sent: Wednesday, April 14, 2010 2:27 AM > To: marf@ietf.org > Subject: Re: [marf] Require body? >=20 > In > C2.corp.cloudmark.com>, > on 04/13/2010 > at 12:02 PM, "Murray S. Kucherawy" said: >=20 > >I'm unclear on how this would fit into the current ARF specification. > >Isn't drop box reporting out of scope for the base draft? >=20 > 1.1. Purpose includes the text "or related to"; that would appear to > apply to drop boxes. If drop boxes are out of scope then 1.1 should be > reworded to make the scope clearer. Actually I don't like the current format of 1.1, now that you mention it. How's this? The reports defined in this document are intend= ed to inform operators about: email abuse originating from their networks; potential issues with the perceived quality of outbound mail, such as email service providers sending mail in a for= mat that causes automated abuse detection systems to consider it suspect. From msk@cloudmark.com Thu Apr 15 11:37:42 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CABA3A6BC4 for ; Thu, 15 Apr 2010 11:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJaa6IG4N+NL for ; Thu, 15 Apr 2010 11:37:38 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id DA4873A6BD3 for ; Thu, 15 Apr 2010 11:37:36 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 15 Apr 2010 11:37:30 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 15 Apr 2010 11:37:28 -0700 Thread-Topic: DKIM reporting ARF extensions Thread-Index: AcrcyrNMBUndHjRQTzCLxWBJ1L2DtQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: A9uk B+h3 CGQF CZCQ Cmf6 Dk2p FI9X FT1i GzGc G/SR I/Ua JI0b JbJb JzF2 KOpa Ki8y; 1; bQBhAHIAZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {708342B7-9E56-43C4-9500-740C497DFA41}; bQBzAGsAQABjAGwAbwB1AGQAbQBhAHIAawAuAGMAbwBtAA==; Thu, 15 Apr 2010 18:37:28 GMT; RABLAEkATQAgAHIAZQBwAG8AcgB0AGkAbgBnACAAQQBSAEYAIABlAHgAdABlAG4AcwBpAG8AbgBzAA== x-cr-puzzleid: {708342B7-9E56-43C4-9500-740C497DFA41} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01CFEA4D3AEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 18:37:42 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01CFEA4D3AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One of our chartered items is to begin working on extensions to ARF to supp= ort reporting of DKIM and ADSP failures to senders. The basis for this wor= k will be draft-kucherawy-dkim-reporting, a new version of which I just pos= ted since it was about to expire (thanks to JD Falk for his review help!). Unless there's any objection, I'll soon ask the IESG to make it a document = of the MARF WG so we can get busy working on it. --_000_BB012BD379D7B046ABE1472D8093C61C01CFEA4D3AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One of our chartered items is to begin working on exte= nsions to ARF to support reporting of DKIM and ADSP failures to senders.  The= basis for this work will be draft-kucherawy-dkim-reporting, a new version of whic= h I just posted since it was about to expire (thanks to JD Falk for his review = help!).

 

Unless there’s any objection, I’ll soon as= k the IESG to make it a document of the MARF WG so we can get busy working on it.=

--_000_BB012BD379D7B046ABE1472D8093C61C01CFEA4D3AEXCHC2corpclo_-- From yakov@shaftek.org Thu Apr 15 14:22:38 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D713A6A87 for ; Thu, 15 Apr 2010 14:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48j45MzUw1Bx for ; Thu, 15 Apr 2010 14:22:35 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 596D93A6A98 for ; Thu, 15 Apr 2010 14:20:48 -0700 (PDT) Received: by wwi18 with SMTP id 18so795150wwi.31 for ; Thu, 15 Apr 2010 14:20:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.7.1 with HTTP; Thu, 15 Apr 2010 14:20:18 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Thu, 15 Apr 2010 17:20:18 -0400 Received: by 10.216.89.213 with SMTP id c63mr708130wef.8.1271366438630; Thu, 15 Apr 2010 14:20:38 -0700 (PDT) Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 21:22:38 -0000 I am not sure how this fits in with ARF since ARF is for abuse reporting specifically, and authentication failure seems to be a more generic "multipart/report" extension. On Thu, Apr 15, 2010 at 2:37 PM, Murray S. Kucherawy wr= ote: > One of our chartered items is to begin working on extensions to ARF to > support reporting of DKIM and ADSP failures to senders.=A0 The basis for = this > work will be draft-kucherawy-dkim-reporting, a new version of which I jus= t > posted since it was about to expire (thanks to JD Falk for his review > help!). > > > > Unless there=92s any objection, I=92ll soon ask the IESG to make it a doc= ument > of the MARF WG so we can get busy working on it. > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > From msk@cloudmark.com Thu Apr 15 15:38:12 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14B63A6A93 for ; Thu, 15 Apr 2010 15:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wziFGAercK3i for ; Thu, 15 Apr 2010 15:38:12 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 1BE553A69C1 for ; Thu, 15 Apr 2010 15:38:12 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 15 Apr 2010 15:38:05 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich Date: Thu, 15 Apr 2010 15:38:04 -0700 Thread-Topic: [marf] DKIM reporting ARF extensions Thread-Index: Acrc4YAWxG8v+7hKTWmbuH8f/cR4XAACsSqQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Message Abuse Report Format working group Subject: Re: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 22:38:12 -0000 > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Thursday, April 15, 2010 2:20 PM > To: Murray S. Kucherawy > Cc: Message Abuse Report Format working group > Subject: Re: [marf] DKIM reporting ARF extensions >=20 > I am not sure how this fits in with ARF since ARF is for abuse > reporting specifically, and authentication failure seems to be a more > generic "multipart/report" extension. The original impetus was phishing reporting, which clearly falls under the = "abuse" category. From shmuel+gen@patriot.net Fri Apr 16 03:29:25 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440383A69F8 for ; Fri, 16 Apr 2010 03:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ6pdqunrqOz for ; Fri, 16 Apr 2010 03:29:24 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 284A23A68A8 for ; Fri, 16 Apr 2010 03:29:23 -0700 (PDT) Received: from ECS35455305 (core-dc-1-104.dynamic-dialup.coretel.net [69.72.26.104]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id ACDC6F5808C for ; Fri, 16 Apr 2010 06:27:51 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Fri, 16 Apr 2010 05:43:07 -0400 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100416102751.ACDC6F5808C@smtp.patriot.net> Subject: Re: [marf] Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 10:29:25 -0000 In , on 04/15/2010 at 10:56 AM, "Murray S. Kucherawy" said: >How's this? Unambiguous. If it really reflects the intent of MARF then I'd say go for it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Fri Apr 16 03:53:38 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3D128C107 for ; Fri, 16 Apr 2010 03:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAVrqQqcpMQB for ; Fri, 16 Apr 2010 03:53:37 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 37E443A6932 for ; Fri, 16 Apr 2010 03:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1271415208; bh=OEAnuqA8TIl4aQ1DU7shIm5tLrP2BVJAJomJ4VRxMr0=; l=1850; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ZdX84y/4QIezKLl56oj3W92YlLZMvCId4gme20XoUcyPIE+cDidgBrhbuh1V9v3PM Ascym2CtbBGrlaNAKFWyMY8hZynImk2nvcRgLWMgID6m7bUTKGKsPgGAAHzYQwcnLF ULtApb+jp8rtkchafErZB5HuEA7jZg8I+ROx07Vc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 16 Apr 2010 12:53:28 +0200 id 00000000005DC035.000000004BC841A8.000069F7 Message-ID: <4BC841A7.1060704@tana.it> Date: Fri, 16 Apr 2010 12:53:27 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <20100415100620.9A85AF5808A@smtp.patriot.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [marf] Section 1.1 (was: Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 10:53:38 -0000 On 15/Apr/10 19:56, Murray S. Kucherawy wrote: > Actually I don't like the current format of 1.1, now that you mention it. > > How's this? > > The reports defined in this document are intended > to inform operators about: Since the previous section is fairly generic, IMHO this should be more specific, e.g. "mail operators", or "mailbox providers and email service providers". > > > email abuse originating from their > networks; > > potential issues with the perceived > quality of outbound mail, such as email > service providers sending mail in a format > that causes automated abuse detection > systems to consider it suspect. IMHO this may be less specific, so as to broaden the class of exemplified uses; e.g. "such as email service providers sending mail that causes problems with abuse detection systems." > Do you mean to drop the last paragraph ("Please note [...] and SHOULD NOT be used for other reports.")? It is still unclear whether this section is meant to also cover future extensions. I don't think we want to limit possible uses of ARF. However, we may inform about alternative formats for reporting email messages: rfc3462 for end users, and the upcoming draft-cain-post-inch-phishingextns for network providers. Adding such information may identify by exclusion our niche of treatable abuses that are neither delivery errors nor manifest attacks. From vesely@tana.it Fri Apr 16 04:57:50 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875263A6C41 for ; Fri, 16 Apr 2010 04:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaanPydiQEo8 for ; Fri, 16 Apr 2010 04:57:49 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 3FFDD28C12C for ; Fri, 16 Apr 2010 04:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1271418676; bh=DKzr+vge0naUbBTgV8O/wB5ToN/z1IBCddNBD5qlK7Y=; l=1145; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WymYHPgTmbLuX1ToC/UW4+Bs3Rf10T0m38zCj5611I2l7qHOyL2ADpHPgZsUjD1lM 3rY75GEWKENttA98TwcXQlcsVNE9++WesCWd+glR/HBfFrPGobSnOo2d9KULz79Nmp t6SGUY3i695q15nVUMDNkr5j2oz2CCCl6ndwsdFo= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 16 Apr 2010 13:51:16 +0200 id 00000000005DC02B.000000004BC84F34.0000759A Message-ID: <4BC84F34.7020407@tana.it> Date: Fri, 16 Apr 2010 13:51:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 11:57:50 -0000 On 15/Apr/10 20:37, Murray S. Kucherawy wrote: > One of our chartered items is to begin working on extensions to ARF to support reporting of DKIM and ADSP failures to senders. The basis for this work will be draft-kucherawy-dkim-reporting, a new version of which I just posted since it was about to expire (thanks to JD Falk for his review help!). Neither your dkim-reporting draft nor rfc 5617 include SMTP as a normative reference. In facts, it is not clear how ADSP discarding and reporting should work, SMTP-wise. To wit, assuming a server rejects a discardable message, the transmitting client is held responsible for reporting such failure. Isn't it so? If it is, the server should supply a machine-readable textstring in its rejecting reply, possibly using a special reply code after DATA. That would lead the transmitter into preparing an ARF rather than a regular DSN. This case is difficult, as it requires changes on both sides. If it is not, the server should accept the message, silently discard it, and submit an ARF according to the specs. This case is easier, but less appealing from a server's POV. From bmcdowell@paypal.com Fri Apr 16 06:53:07 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096F23A6B97 for ; Fri, 16 Apr 2010 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FORGED_PAYPAL_C=1.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhcJUnmJOEG8 for ; Fri, 16 Apr 2010 06:53:06 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 0995828C136 for ; Fri, 16 Apr 2010 06:47:31 -0700 (PDT) DomainKey-Signature: s=ppcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=Fd77V8lHTimI6pZVodIULCcYtNVwCuARWWzwY6nlJk9FZBt0eWvdtaCy tpOGAtz5zlhkPvSPHa2kqlzWi9tATf5gZFu/7bXo/P/9nZG+aWkIQqmkm ql4IXBrBnf2k7Q7; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=bmcdowell@paypal.com; q=dns/txt; s=ppcorp; t=1271425645; x=1302961645; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"McDowell,=20Brett"=20 |Subject:=20Re:=20[marf]=20DKIM=20reporting=20ARF=20exten sions|Date:=20Fri,=2016=20Apr=202010=2007:47:15=20-0600 |Message-ID:=20<21BCE04C-29AA-41B3-9EC9-CFD08F8ED3A5@payp al.com>|To:=20"Murray=20S.=20Kucherawy"=20|CC:=20Yakov=20Shafranovich=20,=20 Message=20Abuse=20Report=20Format=0D=0A=20working=20group =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20=0D=0A=20=0D=0A=20; bh=N8Kh2TzL4FlvaA+Gydf6vaoQlkkjbGGPgPlGQJyXSrY=; b=dpbbLWKzEU+sYPf5jBxketlyLvbssD2a9payqyuJRhJkWgu0kWPUbhie 8iGpE4hORr0NKWgWAoJ7LZOejC4Daaq7vneYXEiroPrgNAE2uzw63G12S xFVoVMWyc5zFtRA; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.52,219,1270450800"; d="scan'208";a="70317880" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 16 Apr 2010 06:47:24 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.228]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Fri, 16 Apr 2010 07:47:24 -0600 From: "McDowell, Brett" To: "Murray S. Kucherawy" Date: Fri, 16 Apr 2010 07:47:15 -0600 Thread-Topic: [marf] DKIM reporting ARF extensions Thread-Index: Acrda1ej6O+2Iv4zQT+NbEl1e3suUw== Message-ID: <21BCE04C-29AA-41B3-9EC9-CFD08F8ED3A5@paypal.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: SGZtEUsF/mul9iMkQ0HDyw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: Message, working group Subject: Re: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 13:53:07 -0000 On Apr 15, 2010, at 6:38 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Yakov Shafranovich [mailto:yakov@shaftek.org] >> Sent: Thursday, April 15, 2010 2:20 PM >> To: Murray S. Kucherawy >> Cc: Message Abuse Report Format working group >> Subject: Re: [marf] DKIM reporting ARF extensions >>=20 >> I am not sure how this fits in with ARF since ARF is for abuse >> reporting specifically, and authentication failure seems to be a more >> generic "multipart/report" extension. >=20 > The original impetus was phishing reporting, which clearly falls under th= e "abuse" category. I agree. It seems appropriate to the MARF charter and is certainly needed.= There is a lot of immediate interest in this spec. From msk@cloudmark.com Fri Apr 16 10:18:01 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5506A3A693F for ; Fri, 16 Apr 2010 10:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIbN7i0dfrSn for ; Fri, 16 Apr 2010 10:18:00 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 0CEC93A683E for ; Fri, 16 Apr 2010 10:18:00 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Fri, 16 Apr 2010 10:17:53 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Fri, 16 Apr 2010 10:17:52 -0700 Thread-Topic: [marf] DKIM reporting ARF extensions Thread-Index: AcrdXAagJeqMTNheSiKcxPvyYyq6ewAK8Vdw Message-ID: References: <4BC84F34.7020407@tana.it> In-Reply-To: <4BC84F34.7020407@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 17:18:01 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Friday, April 16, 2010 4:51 AM > To: marf@ietf.org > Subject: Re: [marf] DKIM reporting ARF extensions >=20 > Neither your dkim-reporting draft nor rfc 5617 include SMTP as a > normative reference. Quite right, and easily fixed. > In facts, it is not clear how ADSP discarding and > reporting should work, SMTP-wise. To wit, assuming a server rejects a > discardable message, the transmitting client is held responsible for > reporting such failure. Isn't it so? Yes, the sending SMTP client would be responsible for handling the rejectio= n according to specifications. > If it is, the server should supply a machine-readable textstring in > its rejecting reply, possibly using a special reply code after DATA. > That would lead the transmitter into preparing an ARF rather than a > regular DSN. This case is difficult, as it requires changes on both > sides. I'm not sure that's a MUST, but I'd go for a SHOULD. One could argue that = the reason for the rejection might reveal to an attacker what has to be adj= usted to get through the filter. > If it is not, the server should accept the message, silently discard > it, and submit an ARF according to the specs. This case is easier, but > less appealing from a server's POV. The spec allows the "victim" domain to specify what action it would like re= ceivers to take when an ADSP violation occurs. This can include whether or= not the receiver is requested to do either of the two things you suggest a= nd can even request a specific SMTP reply string. The receiver isn't compe= lled to do either; it's a request from the ADMD posting the ADSP record. The one thing I think I could add based on your remarks is more affirmative= text that the extensions proposed are optional for the receiver; they are = requests from whoever used the extension, but the receiver is free to take = whatever action is operationally appropriate in its environment. From msk@cloudmark.com Fri Apr 16 10:34:05 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38043A6A1B for ; Fri, 16 Apr 2010 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaZM2xr0QrAn for ; Fri, 16 Apr 2010 10:34:04 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id E22F73A68BD for ; Fri, 16 Apr 2010 10:34:04 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Fri, 16 Apr 2010 10:33:58 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Fri, 16 Apr 2010 10:33:57 -0700 Thread-Topic: [marf] Section 1.1 (was: Require body? Thread-Index: AcrdUw9un7N0IoDFS9u0QV4DN6i8HAANytHQ Message-ID: References: <20100415100620.9A85AF5808A@smtp.patriot.net> <4BC841A7.1060704@tana.it> In-Reply-To: <4BC841A7.1060704@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Section 1.1 (was: Require body? X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 17:34:05 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Friday, April 16, 2010 3:53 AM > To: marf@ietf.org > Subject: [marf] Section 1.1 (was: Require body? >=20 > Since the previous section is fairly generic, IMHO this should be more > specific, e.g. "mail operators", or "mailbox providers and email > service providers". +1 > IMHO this may be less specific, so as to broaden the class of > exemplified uses; e.g. "such as email service providers sending mail > that causes problems with abuse detection systems." How about: potential issues with the perceived quality of outbound mail, such as email service providers sending mail that attracts the attention of automated abu= s detection systems. > Do you mean to drop the last paragraph ("Please note [...] and SHOULD > NOT be used for other reports.")? Nope, that hasn't been removed. I just didn't cite it. > It is still unclear whether this section is meant to also cover future > extensions. I don't think we want to limit possible uses of ARF. > However, we may inform about alternative formats for reporting email > messages: rfc3462 for end users, and the upcoming > draft-cain-post-inch-phishingextns for network providers. Adding such > information may identify by exclusion our niche of treatable abuses > that are neither delivery errors nor manifest attacks. The abstract says that the format is extensible, and I think that's obvious= once one looks down at the IANA stuff. And ARF is based on RFC3462 (it's = a normative reference), so I'm a little confused as to your intent here. C= an you propose some text? I think the focus is clearly on reporting about objectionable mail and not = generic questionable network activity. That said, we might want to make a = reference to the INCH work early on and explain why all the sites that have= gone with ARF did so instead of using INCH. Some text about that (from su= ch an operator on this list) would be really helpful, even if it's a statem= ent that INCH was found to be too hard, or ARF was ready before INCH was, o= r such. From vesely@tana.it Sat Apr 17 08:00:30 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08713A68BF for ; Sat, 17 Apr 2010 08:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q+I17dIg5dU for ; Sat, 17 Apr 2010 08:00:29 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 2640E3A692F for ; Sat, 17 Apr 2010 08:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1271516417; bh=/aQ+kfH/EG5out2yf/UENOERO0lJ/kqHiC9rwTlb4F0=; l=2174; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gWUmVq3KMf3YbB/0nZj+HWobeqveAD5s/jFczmQNR8p2F+OuVmV3aHN+dSZQhNAy5 EcmlD4xRoaszhpHZsVQE0u/JMBSKc4hUZWQTwhuvekHCeBWhDngt3n26qeTbzyNG2P gNcmHbhfpDIUl1R22XBnZTeb8gn4Y62oQ2zqkUSU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 17 Apr 2010 17:00:17 +0200 id 00000000005DC035.000000004BC9CD01.00000631 Message-ID: <4BC9CD00.6010703@tana.it> Date: Sat, 17 Apr 2010 17:00:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <4BC84F34.7020407@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 15:00:30 -0000 On 16/Apr/10 19:17, Murray S. Kucherawy wrote: >> If it is, the server should supply a machine-readable textstring in its rejecting reply, possibly using a special reply code after DATA. That would lead the transmitter into preparing an ARF rather than a regular DSN. This case is difficult, as it requires changes on both sides. > > I'm not sure that's a MUST, but I'd go for a SHOULD. Or even a MAY. The server has no way to know whether the client supports the special formatting required. However, the format of the textstring has to be spelled out. (It might be something similar to Reply-line = *( Reply-code "-" [ textstring ] CRLF ) Reply-code [ SP textstring ] CRLF Reply-code = "556" ; say textstring = dkim-hdr-name ":" dkim-hdr-value dkim-hdr-name = "DKIM-ADSP-DNS" / ; ... "DKIM-Selector-DNS" dkim-hdr-value = token) More importantly, the server has no way to know whether the client will send a report to the domain name owner. An attacker obviously won't. For security-critical applications (B below), it may make sense to ask that a server sends an abuse report even if it is going to reject (or has just rejected) the reported message. The following are two different scenarios: A: The domain owner wants to know where signatures get broken in order to fix their sending policies. They rely on forwarders and receivers cooperation for the common advantage of having reliable email services. B: A bank or similar institution wants to know the IPs of attackers who use their domain name in order to catch and prosecute them. Here, the advantage of the bank is the disadvantage of the attacker, and no cooperation is possible. Could a server infer which case to apply, from the ADSP record? > One could argue that the reason for the rejection might reveal to an attacker what has to be adjusted to get through the filter. In ordinary conditions, adjusting the content until the hash matches would require a huge number of attempts. Anyway, attackers can test their forgeries on their own, before attempting to send them. From jdfalk-lists@cybernothing.org Mon Apr 19 12:36:28 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF803A68F1 for ; Mon, 19 Apr 2010 12:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RksgF46sGDu for ; Mon, 19 Apr 2010 12:36:27 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 183FD3A68BA for ; Mon, 19 Apr 2010 12:36:27 -0700 (PDT) Received: from [192.168.0.7] (97-122-145-61.hlrn.qwest.net [97.122.145.61]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3JJaFAf027004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 19 Apr 2010 13:36:17 -0600 References: <4BC84F34.7020407@tana.it> <4BC9CD00.6010703@tana.it> In-Reply-To: <4BC9CD00.6010703@tana.it> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Mon, 19 Apr 2010 13:36:10 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 19:36:28 -0000 On Apr 17, 2010, at 9:00 AM, Alessandro Vesely wrote: > More importantly, the server has no way to know whether the client = will send a report to the domain name owner. An attacker obviously = won't. For security-critical applications (B below), it may make sense = to ask that a server sends an abuse report even if it is going to reject = (or has just rejected) the reported message. I'd expect that the most common scenario will be that the message is = rejected AND a report is sent -- but we'll see. Unlike the original ARF effort, the community appears to be asking for a = standard format /before/ they start exchanging data -- which makes it = difficult to guess all the possible use cases at this stage. One use case which isn't addressed in the current draft is where a set = of signers ask a third party to collect & aggregate authentication = success/failure data on their behalf, and the third party has = relationships with verifiers who've agreed to provide that data. For = this, the DKIM reporting extensions to ARF are applied, but the policy = and discovery parts of the draft are not -- instead it's an out-of-band = agreement, just like marf-base. I suppose we should mention that in the draft, but I'm not sure how to = word it. > The following are two different scenarios: >=20 > A: The domain owner wants to know where signatures get broken in order = to fix their sending policies. They rely on forwarders and receivers = cooperation for the common advantage of having reliable email services. >=20 > B: A bank or similar institution wants to know the IPs of attackers = who use their domain name in order to catch and prosecute them. Here, = the advantage of the bank is the disadvantage of the attacker, and no = cooperation is possible. >=20 > Could a server infer which case to apply, from the ADSP record? How would it change their response if they knew? -- J.D. Falk Return Path Inc From vesely@tana.it Tue Apr 20 00:52:44 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD753A697B for ; Tue, 20 Apr 2010 00:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLhGfmn8mCri for ; Tue, 20 Apr 2010 00:52:43 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id D306F3A6A92 for ; Tue, 20 Apr 2010 00:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1271749947; bh=2OUvuvkpnEwfw/6FWfhOsC4T3bbC6K6Lv9J6boSxbjc=; l=2641; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SmySr9buvkraXF4f1QmC9w+W8kYDJLWQZxd7FtnId/+XAGoPCMFJY6lC0YjldZ2mE giF0JlOJd86tWfzSpC5S+Kv3je+KiZXsE+FKbrIFBl2UBZ1IZQtBuSsb3ADIPDh+Yn Mz8q0XsfKxTTBEHVo7ZnhgYqTESPmlslHc0kUMDk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 20 Apr 2010 09:52:27 +0200 id 00000000005DC02B.000000004BCD5D3B.000007F1 Message-ID: <4BCD5D3B.60809@tana.it> Date: Tue, 20 Apr 2010 09:52:27 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <4BC84F34.7020407@tana.it> <4BC9CD00.6010703@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] DKIM reporting ARF extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 07:52:45 -0000 On 19/Apr/10 21:36, J.D. Falk wrote: > On Apr 17, 2010, at 9:00 AM, Alessandro Vesely wrote: > >> More importantly, the server has no way to know whether the client will send a report to the domain name owner. An attacker obviously won't. For security-critical applications (B below), it may make sense to ask that a server sends an abuse report even if it is going to reject (or has just rejected) the reported message. > > I'd expect that the most common scenario will be that the message is rejected AND a report is sent -- but we'll see. That behavior makes lots of sense. However, it is different from traditional SMTP behavior. I think the spec should explicitly ask that servers take such action in the relevant circumstances. IMHO, the likelihood that it will emerge spontaneously is negligible. > Unlike the original ARF effort, the community appears to be asking for a standard format /before/ they start exchanging data -- which makes it difficult to guess all the possible use cases at this stage. Possibly, if paypal launched an appeal to report any rejected phishing attempt, someone would do so. Its format has to be specified, though. > One use case which isn't addressed in the current draft is where a set of signers ask a third party to collect& aggregate authentication success/failure data on their behalf, and the third party has relationships with verifiers who've agreed to provide that data. For this, the DKIM reporting extensions to ARF are applied, but the policy and discovery parts of the draft are not -- instead it's an out-of-band agreement, just like marf-base. > > I suppose we should mention that in the draft, but I'm not sure how to word it. Marf-base doesn't word out very well that state of affairs either. >> The following are two different scenarios: >> >> A: The domain owner wants to know where signatures get broken in order to fix their sending policies. They rely on forwarders and receivers cooperation for the common advantage of having reliable email services. >> >> B: A bank or similar institution wants to know the IPs of attackers who use their domain name in order to catch and prosecute them. Here, the advantage of the bank is the disadvantage of the attacker, and no cooperation is possible. >> >> Could a server infer which case to apply, from the ADSP record? > > How would it change their response if they knew? Case B is similar to the paypal appeal hypothesized above. I wouldn't take the burden to write (or enable) software that sends such stuff upon rejection, unless the would-be recipients say they'll appreciate it. From root@core3.amsl.com Wed Apr 21 10:30:02 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4BAEE3A6CA2; Wed, 21 Apr 2010 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100421173002.4BAEE3A6CA2@core3.amsl.com> Date: Wed, 21 Apr 2010 10:30:02 -0700 (PDT) Cc: marf@ietf.org Subject: [marf] I-D Action:draft-ietf-marf-base-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF. Title : An Extensible Format for Email Feedback Reports Author(s) : Y. Shafranovich, et al. Filename : draft-ietf-marf-base-03.txt Pages : 33 Date : 2010-04-21 This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-base-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-marf-base-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-21102258.I-D@ietf.org> --NextPart-- From msk@cloudmark.com Wed Apr 21 10:33:09 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7F13A6D47 for ; Wed, 21 Apr 2010 10:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqSscd6u6zz0 for ; Wed, 21 Apr 2010 10:33:06 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 21EC83A6B88 for ; Wed, 21 Apr 2010 10:21:45 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 21 Apr 2010 10:21:34 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 21 Apr 2010 10:21:31 -0700 Thread-Topic: draft-ietf-marf-base WGLC completed Thread-Index: AcrhdxXBO9h40PHFRKqOhH1JSHXecA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Psk= AIkm ALYk BHBR BTnY CDyx DUZt Dk0r DssN Eb4T Ec3m EnAL GM3a GQtZ Gsfa Kz1x; 1; bQBhAHIAZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {F8F6CE28-DA05-4652-9A53-C96A9E086FAB}; bQBzAGsAQABjAGwAbwB1AGQAbQBhAHIAawAuAGMAbwBtAA==; Wed, 21 Apr 2010 17:21:31 GMT; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAG0AYQByAGYALQBiAGEAcwBlACAAVwBHAEwAQwAgAGMAbwBtAHAAbABlAHQAZQBkAA== x-cr-puzzleid: {F8F6CE28-DA05-4652-9A53-C96A9E086FAB} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01D0508B62EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] draft-ietf-marf-base WGLC completed X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:33:09 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01D0508B62EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group Last Call on the base draft has completed. Thanks to all tha= t provided feedback. I'm about to send through the -03 version. As I've been acting as editor, = I'll leave it to Barry to rule on consensus being reached on the resulting = edits and then refer it to the IESG to start IETF-wide last call. Thanks t= o JD Falk for offering to act as document shepherd for base. I'll be importing the DKIM reporting extensions draft shortly as a WG docum= ent. With the base draft entering the formal publication phase, now would also b= e a good time to begin discussing any extension drafts people may wish to p= ropose. We're awaiting some conversations at MAAWG about adopting their BCP documen= t into the working group for publication as an IETF document. JD will let = us know when that's progressed. -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01D0508B62EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group Last Call on the base draft has complete= d.  Thanks to all that provided feedback.

 

I’m about to send through the -03 version. = As I’ve been acting as editor, I’ll leave it to Barry to rule on consensus be= ing reached on the resulting edits and then refer it to the IESG to start IETF-= wide last call.  Thanks to JD Falk for offering to act as document shepherd= for base.

 

I’ll be importing the DKIM reporting extensions = draft shortly as a WG document.

 

With the base draft entering the formal publication ph= ase, now would also be a good time to begin discussing any extension drafts peop= le may wish to propose.

 

We’re awaiting some conversations at MAAWG about adopting their BCP document into the working group for publication as an IE= TF document.  JD will let us know when that’s progressed.

 

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C01D0508B62EXCHC2corpclo_-- From root@core3.amsl.com Wed Apr 21 11:30:05 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A06203A6CF7; Wed, 21 Apr 2010 11:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100421183005.A06203A6CF7@core3.amsl.com> Date: Wed, 21 Apr 2010 11:30:02 -0700 (PDT) Cc: marf@ietf.org Subject: [marf] I-D Action:draft-ietf-marf-dkim-reporting-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 18:30:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF. Title : Reporting of DKIM Verification Failures Author(s) : M. Kucherawy Filename : draft-ietf-marf-dkim-reporting-00.txt Pages : 24 Date : 2010-04-21 This memo presents an extension to the DomainKeys Identified Mail (DKIM) specifications to allow public keys for verification to include a reporting address to be used to report message verification issues, and extends an Internet Message reporting format to be followed when generating such reports. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-marf-dkim-reporting-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-21112453.I-D@ietf.org> --NextPart-- From yakov@shaftek.org Wed Apr 21 13:48:13 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D84F3A6AD0 for ; Wed, 21 Apr 2010 13:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzizYp4+YpiN for ; Wed, 21 Apr 2010 13:48:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 01F2D3A6AF3 for ; Wed, 21 Apr 2010 13:48:09 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so25146fga.13 for ; Wed, 21 Apr 2010 13:47:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.57.4 with HTTP; Wed, 21 Apr 2010 13:47:35 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Wed, 21 Apr 2010 16:47:35 -0400 Received: by 10.86.126.33 with SMTP id y33mr7344076fgc.51.1271882875632; Wed, 21 Apr 2010 13:47:55 -0700 (PDT) Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] draft-ietf-marf-base WGLC completed X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 20:48:13 -0000 Which BCP document is it? On Wed, Apr 21, 2010 at 1:21 PM, Murray S. Kucherawy wr= ote: > Working Group Last Call on the base draft has completed.=A0 Thanks to all= that > provided feedback. > > > > I=92m about to send through the -03 version.=A0 As I=92ve been acting as = editor, > I=92ll leave it to Barry to rule on consensus being reached on the result= ing > edits and then refer it to the IESG to start IETF-wide last call.=A0 Than= ks to > JD Falk for offering to act as document shepherd for base. > > > > I=92ll be importing the DKIM reporting extensions draft shortly as a WG > document. > > > > With the base draft entering the formal publication phase, now would also= be > a good time to begin discussing any extension drafts people may wish to > propose. > > > > We=92re awaiting some conversations at MAAWG about adopting their BCP doc= ument > into the working group for publication as an IETF document.=A0 JD will le= t us > know when that=92s progressed. > > > > -MSK > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > From jdfalk-lists@cybernothing.org Wed Apr 21 15:02:59 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2172C3A6ACA for ; Wed, 21 Apr 2010 15:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz9zlmdGcTQr for ; Wed, 21 Apr 2010 15:02:57 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id C5AA03A69D9 for ; Wed, 21 Apr 2010 15:02:56 -0700 (PDT) Received: from [10.0.3.48] (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3LM2ijL006704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 21 Apr 2010 16:02:46 -0600 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <8EFA6E40-9242-4C25-8365-22CA18C16E65@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 21 Apr 2010 16:02:39 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] draft-ietf-marf-base WGLC completed X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 22:02:59 -0000 On Apr 21, 2010, at 2:47 PM, Yakov Shafranovich wrote: > Which BCP document is it? There's a MAAWG (maawg.org) Complaint Feedback BCP which ihasn't yet = been published. MAAWG needs to decide whether to submit it to the IETF = MARF WG for further refinement. -- J.D. Falk Return Path Inc From yakov@shaftek.org Wed Apr 21 19:44:18 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8603A69CA for ; Wed, 21 Apr 2010 19:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.345 X-Spam-Level: X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJB2wGC22doI for ; Wed, 21 Apr 2010 19:44:17 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 417563A697D for ; Wed, 21 Apr 2010 19:44:14 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so55053fge.13 for ; Wed, 21 Apr 2010 19:44:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.57.4 with HTTP; Wed, 21 Apr 2010 19:43:40 -0700 (PDT) From: Yakov Shafranovich Date: Wed, 21 Apr 2010 22:43:40 -0400 Received: by 10.87.47.3 with SMTP id z3mr7571881fgj.74.1271904240133; Wed, 21 Apr 2010 19:44:00 -0700 (PDT) Message-ID: To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [marf] Updated ARF document repository X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 02:44:18 -0000 I have updated the document repository and ARF page that I host on my site with some more background information on ARF, and links to all of the marf-base drafts. Since this URL is referenced in the draft, I felt the need to keep it current. The updated page is here: http://www.shaftek.org/publications/drafts/abuse-report/ Keep in mind that this page is primarily for historical purposes, it is probably interesting only for those who wish to see how the draft developed over time. Also, since it predates the development of the current IETF document tracker, it also includes diffs for all the drafts. PLEASE NOTE: that this is NOT an official IETF page, it is something I personally maintain. IETF's official information on the current ARF draft including diffs and full history, can be found here: https://datatracker.ietf.org/doc/draft-ietf-marf-base/#history https://datatracker.ietf.org/doc/draft-shafranovich-feedback-report/#history Yakov From yakov@shaftek.org Wed Apr 21 19:58:37 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FCE3A6A9F for ; Wed, 21 Apr 2010 19:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.345 X-Spam-Level: X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HV64Zbj3VOa for ; Wed, 21 Apr 2010 19:58:36 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 6B4B43A6A96 for ; Wed, 21 Apr 2010 19:58:36 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so134224fga.13 for ; Wed, 21 Apr 2010 19:58:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.57.4 with HTTP; Wed, 21 Apr 2010 19:47:10 -0700 (PDT) From: Yakov Shafranovich Date: Wed, 21 Apr 2010 22:47:10 -0400 Received: by 10.223.127.212 with SMTP id h20mr239726fas.89.1271904450169; Wed, 21 Apr 2010 19:47:30 -0700 (PDT) Message-ID: To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [marf] Minor nit on marf-base-03 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 02:58:37 -0000 Section 1.1: "automated abus" - missing an "e", should read "automated abuse" From msk@cloudmark.com Wed Apr 21 21:16:30 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C05E3A6AE3 for ; Wed, 21 Apr 2010 21:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4adPdroqrorr for ; Wed, 21 Apr 2010 21:16:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id BAEA63A6ABB for ; Wed, 21 Apr 2010 21:16:27 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 21 Apr 2010 21:16:18 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich , "marf@ietf.org" Date: Wed, 21 Apr 2010 21:15:50 -0700 Thread-Topic: [marf] Minor nit on marf-base-03 Thread-Index: Acrhx6+dfFNoWU5RRZOxy9prOmEkMwACs6Aa Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Minor nit on marf-base-03 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:16:30 -0000 Thanks; I've fixed it for whenever -04 comes out (probably will need one af= ter IETF-wide last call and/or IESG review). ________________________________________ From: marf-bounces@ietf.org [marf-bounces@ietf.org] On Behalf Of Yakov Shaf= ranovich [yakov@shaftek.org] Sent: Wednesday, April 21, 2010 7:47 PM To: marf@ietf.org Subject: [marf] Minor nit on marf-base-03 Section 1.1: "automated abus" - missing an "e", should read "automated abuse" _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From sm@resistor.net Thu Apr 22 02:50:36 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D86628C0F9 for ; Thu, 22 Apr 2010 02:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TQWH34wIJ3T for ; Thu, 22 Apr 2010 02:50:34 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 90C7B3A6A73 for ; Thu, 22 Apr 2010 02:50:34 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o3M9nvrb028178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 02:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1271929822; x=1272016222; bh=GzzeGCsH0roIdcKSMZhJnn3QnOhJ356srxbS34CxVcc=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type:Cc; b=VeHwpmeLSR4XfM+fQ9D4hNtQQt5/wKR/7rBubJInxAOvu3xbq34W13kRh6rTt2YDb YMCcvfCyiZOk8k7isW6Gnobut6xpG4oWCYPZMOY6X5sOi68BIxyFe0ywgOSt+NNDJq EZqrIhOVI7vNaC1nc8fzQk3XVSsn9Kdvl+A6bBt4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1271929822; x=1272016222; bh=GzzeGCsH0roIdcKSMZhJnn3QnOhJ356srxbS34CxVcc=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type:Cc; b=EhSyKmWwAe+ue1X9v7Wxuy3DOAcAVM4I+8/MdTOzQxSqTLWTHPMcrVCRMvsK1qBbA K9j7nXZQGp0PD0p+V6AvSmIuX+s8AaVCLsK2AQn05u+Gx6V6opVMK97q0CLP8XlX75 sX5tHQ3u5MtySuzK+4qPu54bQvIIJVG9+A7SovBI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=YKIyNaoEyntXVMaYVNtnVD1PVkyK5NUhrJxqNYrlK6dKk2RxpTTKDz4vSOk0LIhJV mTFhkG8QoSAT9P3V1WBss1AHn52L7H1PyhZtxd1i/ItjdXMNx01k5eJAw2YPlEGNNuy S269snakzcJ49CRYRJj6OO8TIUFNuaph9FL88vk= Message-Id: <6.2.5.6.2.20100422015959.0a1140b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Apr 2010 02:47:56 -0700 To: marf@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [marf] draft-ietf-marf-dkim-reporting-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:50:36 -0000 Hi Murray, These comments are for draft-ietf-marf-dkim-reporting-00. In Section 1: "[DKIM] introduced a standard for digital signing of messages for the purposes of sender authentication." I suggest avoiding the word "standard" in there. Reusing some text from RFC 4871: DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. In Section 5.2: "u Reports are requested for messages that have no valid [DKIM] signature but do not match the published [ADSP] policy." I suggest replacing the "but" with "and". In Section 6: "smtp: An [SMTP] error with a string descriptive of the problem that caused the DKIM verification to fail." Do you mean SMTP error code? Would the descriptive string be a redefinition of existing strings used for these error codes? In Section 7.3: "For example, "Failure: asp" could be augmented by a" There is a typo for "adsp". The [MAIL] reference should be RFC 5322. In Appendix B.1: "Reports about signature evaluation failures should be send to the address "dkim-errors" at the sender's domain;" That should be "the domain found in the "d=" tag of the signature" instead of the sender's domain. In Appendix B.2: "The sending domain (i.e. the one that is advertising this policy) signs all mail it sends;" That should be Author Domain. There are other occurrences of "sender's domain" that should be fixed. BTW, Appendix C should point to this mailing list. Regards, -sm From barryleiba.mailing.lists@gmail.com Thu Apr 22 12:25:15 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789A23A6A94 for ; Thu, 22 Apr 2010 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYKWWNhBo0kj for ; Thu, 22 Apr 2010 12:25:13 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 34F7B3A6AE1 for ; Thu, 22 Apr 2010 12:07:21 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so511332fga.13 for ; Thu, 22 Apr 2010 12:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H/2/z8O3Hqa60ceI/OddXKtjHwADobphK03JlJ0bXUI=; b=s71/IOFnQQH80BJ2FE6sF+Fr/FsmDY6jwGbmPMs/Tz5b42RhT1qkIqLZqW62zvmGw6 Dzkz3n3etvGX+D1tE4QlzAOM19ni1boJTvVX2g6oqnKDm7dY4MtQkv6AgVj9s7t154NW GcSIbXfJnwDsTnFGvIo2OV8NmVjnAx8F3OpTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=BadJ0HfKBuGOVJ6lT2TGMJvh0sp9E4gWZd0GE2ZBpHQsXXqD9f8n4IulfW9jV/ECZK 2MThmhvN5d5f+4iJ6/jdj0huMOuslnpHnTpyWG0g3QpWoQyyA9gQ/zlghlZ1TIbPpHJW 1B0GX+haGBoJYxwVmQHy2RRsyfeds0p8bD2wk= MIME-Version: 1.0 Received: by 10.223.112.15 with HTTP; Thu, 22 Apr 2010 12:01:44 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20100422015959.0a1140b0@elandnews.com> References: <6.2.5.6.2.20100422015959.0a1140b0@elandnews.com> Date: Thu, 22 Apr 2010 15:01:44 -0400 Received: by 10.223.144.84 with SMTP id y20mr492815fau.78.1271962904765; Thu, 22 Apr 2010 12:01:44 -0700 (PDT) Message-ID: From: Barry Leiba To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] draft-ietf-marf-dkim-reporting-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:25:15 -0000 > In Section 1: > > =A0"[DKIM] introduced a standard for digital signing of messages for the > =A0 purposes of sender authentication." > > I suggest avoiding the word "standard" in there. =A0Reusing some text fro= m RFC > 4871: RFC 4871 is on the Standards Track, and there's no reason to avoid referring to it as a "standard". Why do you object to that? That said, I'd rather avoid the "sender authentication" phrasing, and suggest the "claim responsibility" wording that SM quotes. Barry From bmcdowell@paypal.com Thu Apr 22 13:26:09 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740E53A696B for ; Thu, 22 Apr 2010 13:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FORGED_PAYPAL_C=1.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF5jCEkddsjg for ; Thu, 22 Apr 2010 13:26:08 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 018673A68C3 for ; Thu, 22 Apr 2010 13:26:07 -0700 (PDT) DomainKey-Signature: s=ppcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=DpG/HHu1+utXcub+6dLfa+q1FkZbc8/VYblp8hLVKiOrOVnCeXk3ms/A wv2nN5VJ3YNVZQNoJ3JxfvQ/KlGtZ6cRqCkODgQj8CccAzZCI//IEN+Is XW/0XMoG/Bzu6Q7; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=bmcdowell@paypal.com; q=dns/txt; s=ppcorp; t=1271967958; x=1303503958; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"McDowell,=20Brett"=20 |Subject:=20Re:=20[marf]=20draft-ietf-marf-dkim-reporting -00|Date:=20Thu,=2022=20Apr=202010=2014:25:56=20-0600 |Message-ID:=20|To:=20"barryleiba@computer.org"=20|CC:=20SM=20,=20"marf@ietf.org "=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20<6.2.5.6.2.20100422 015959.0a1140b0@elandnews.com>=0D=0A=20; bh=HvX/5FRkK9eVlN69d7exCyfNRZalcS3DUoOu8qHhUyE=; b=b5+vQ/M9goPDBMGeji60vH/3FVDSPkHnznT7+qga+9Qf1GGfimYDwrOP urfgmNYiEdKKb06JxMT3J0yyhPPMnlXUl/jYuYX4LBWFUjdxwNz92R6tV j+8Ish7C0rmtGLQ; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.52,258,1270450800"; d="scan'208";a="70445889" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 22 Apr 2010 13:25:57 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.228]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Thu, 22 Apr 2010 14:25:57 -0600 From: "McDowell, Brett" To: "barryleiba@computer.org" Date: Thu, 22 Apr 2010 14:25:56 -0600 Thread-Topic: [marf] draft-ietf-marf-dkim-reporting-00 Thread-Index: AcriWgORWSvBBd3WQpe7o0gaXdl/xQ== Message-ID: References: <6.2.5.6.2.20100422015959.0a1140b0@elandnews.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: rFBfLZM/T6PjMukpjWqVsQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "marf@ietf.org" Subject: Re: [marf] draft-ietf-marf-dkim-reporting-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 20:26:09 -0000 On Apr 22, 2010, at 3:01 PM, Barry Leiba wrote: >> In Section 1: >>=20 >> "[DKIM] introduced a standard for digital signing of messages for the >> purposes of sender authentication." >>=20 >> I suggest avoiding the word "standard" in there. Reusing some text from= RFC >> 4871: >=20 > RFC 4871 is on the Standards Track, and there's no reason to avoid > referring to it as a "standard". Why do you object to that? How about we take the best of both suggestions and use "standard mechanism"= instead of just "standard" or just "mechanism"? From sm@resistor.net Thu Apr 22 13:52:49 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062AF3A68E4 for ; Thu, 22 Apr 2010 13:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi8LT0+KoGUz for ; Thu, 22 Apr 2010 13:52:47 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id E15573A684F for ; Thu, 22 Apr 2010 13:52:44 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o3MKnNag025851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 13:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1271969514; x=1272055914; bh=7dLVUv5llwM9tINw94kdvoCbAwMPN78X/AhngY4fyHs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=RCqTaieyd/hsTVmD3U96gpqgSO9W/EFpxQCyPImHuTRnVHOO53NGf3QJ44Ker2PpN D7hcJKMZVSgr4u4Pl2ROwxoMqmZ+nbWFNhE6qPPE2C6pJyeHpMy7cl78eU+SEvSV3D HSFffHGD2I/rcqIZVsy7/egIwbmnF4g+cScPMYxs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1271969514; x=1272055914; bh=7dLVUv5llwM9tINw94kdvoCbAwMPN78X/AhngY4fyHs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=HryOTRTJLbY32pmhUEVXaRwWujJlT2GJfy5NwIpL1PXoeOlyzDRiAK5t7YIkS++YP pNf6fp/yXRdX7G5+XAhEIGSIJJ4QxshGD76AfVdqHrgAAAoDTjl8oJsWPR++wY886o PDCUTtrebYlToRUqWN98ro15dWH/+j1yfPtUsGqA= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=kFjzhmq6xJ0Dcrl65EFiSLwLsqClsesYWj85DsNC3CXSi1Xf3AC5qtBuMhe1LJEwc TzU6GGasWOkQ7BvgxfPW93ymj4t1rszSciW71O/jzVRaDWe3owTkj/86eUvB/X/kniz ZIxzfkU2do8+dy05nPFp+EDANQQV4vD/Yr/iP9Q= Message-Id: <6.2.5.6.2.20100422131404.09aa72b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Apr 2010 13:36:26 -0700 To: barryleiba@computer.org From: SM In-Reply-To: References: <6.2.5.6.2.20100422015959.0a1140b0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] draft-ietf-marf-dkim-reporting-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 20:52:49 -0000 Hi Barry, At 12:01 22-04-10, Barry Leiba wrote: >RFC 4871 is on the Standards Track, and there's no reason to avoid >referring to it as a "standard". Why do you object to that? RFC 4871 may be on the Standards Track but it's not an Internet Standard. I don't think it's a good idea to refer to it as a standard in a WG document. Regards, -sm From barryleiba.mailing.lists@gmail.com Thu Apr 22 13:57:34 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6343A68DF for ; Thu, 22 Apr 2010 13:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7YFqO2HvnVk for ; Thu, 22 Apr 2010 13:57:33 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 44BD13A68E4 for ; Thu, 22 Apr 2010 13:57:27 -0700 (PDT) Received: by bwz25 with SMTP id 25so10177800bwz.28 for ; Thu, 22 Apr 2010 13:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YOYYsv4Go8NEi6QXAwLhQlp5PdEeEh3SkEElDdmf4Rk=; b=oSH33evdrNGqjFQlUlslfQVByJHp2EIn/OD85Jb4N7iLU8SgqGBaTgTcoZNQ3T7TDC +W2NEgLLu4b9COZIOz7K+QfCtm2LvxKSJHlXchnZvE46Y19BksB84zoL63K9/Xf50J/9 Lo0ea99wSjO7mQZOLQEvnnr2UNBBZDyKiox5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=enBjBwn8ASy6vMuwQBEAcpqFKWFlRivaUNCLsi7higVczcCvF3l1fKLKvhJBTPyEvn HD/W5r2SO6qqc0EUtHBomivopg1g/4vvR7vqvWsrR2IjpL+ALcR/bem1uvrqz7DnpRP4 lWlBtPA8lwe1QDfiSOxC0JwWYLTe0wJRJtrPk= MIME-Version: 1.0 Received: by 10.223.112.15 with HTTP; Thu, 22 Apr 2010 13:57:13 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20100422131404.09aa72b8@resistor.net> References: <6.2.5.6.2.20100422015959.0a1140b0@elandnews.com> <6.2.5.6.2.20100422131404.09aa72b8@resistor.net> Date: Thu, 22 Apr 2010 16:57:13 -0400 Received: by 10.87.48.26 with SMTP id a26mr365312fgk.5.1271969833710; Thu, 22 Apr 2010 13:57:13 -0700 (PDT) Message-ID: From: Barry Leiba To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] draft-ietf-marf-dkim-reporting-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 20:57:34 -0000 > RFC 4871 may be on the Standards Track but it's not an Internet Standard.= =A0I > don't think it's a good idea to refer to it as a standard in a WG documen= t. I think that's a very odd objection. It's "Proposed Standard", yes. We refer to standards-track documents as "standards" (as opposed to "Full Standard", or "STD 17", or whatever) all the time. Barry From sm@resistor.net Thu Apr 22 15:28:51 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2083A683E for ; Thu, 22 Apr 2010 15:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1SMErAgqqaf for ; Thu, 22 Apr 2010 15:28:49 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 6D3B73A67B2 for ; Thu, 22 Apr 2010 15:28:49 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o3MMSN35029017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 15:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1271975314; x=1272061714; bh=xl8Uq/Xx4YwOq7mYEIheMro7lRGX1gq4/+ifYyVjuEI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ZbUc82r4eQxQGzZzbp69y2l9ptOW6pIWd/4Tr6WOlny7yfiszaO/7Q7WEHEChf4+t Yg0vtOdTyxQ6yQDDqpkWj1MnWn6ZCrLyHY2ZF902uLkIFi9Ylj9xAWcCXMWsRcPKAU X4vulobC/gTQbdrpFiovsCwACg0FgAJl4aMIaZsw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1271975314; x=1272061714; bh=xl8Uq/Xx4YwOq7mYEIheMro7lRGX1gq4/+ifYyVjuEI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=vTEwyT4slQfRzp5GWjmAxpTt4piE7eO1p5Qs1VgD1Mu8i81OLV/UTVpujlAk+MqmN XdC5htufYEW5FNDKN76vsspOcUnZE3NYTHiga06wP8cSTrfZMUgq61rRN4imWXlAWm EzKCGLUO356SCa8sX4LgdcJvWEHjF1Awddi2e17s= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=XIFJvVx1HsTpEmBpngLbdyQfEGyTE5uRFWV1WBLWes9Gi49J5AcSPIrdcFWvLv+3k oKzdM19i7e6ybOKprCrcE9PUoywx/jmjLavbKsashdCGbSyD3izLCuk6oE2pI3d3zAD BQ0wK0BVK3hoWu/wGqCn8vTkSrjXqWTNqbQsApM= Message-Id: <6.2.5.6.2.20100422151708.0a208c70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 Apr 2010 15:28:04 -0700 To: marf@ietf.org From: SM In-Reply-To: References: <6.2.5.6.2.20100422015959.0a1140b0@elandnews.com> <6.2.5.6.2.20100422131404.09aa72b8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: barryleiba@computer.org Subject: Re: [marf] draft-ietf-marf-dkim-reporting-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 22:28:51 -0000 At 13:57 22-04-10, Barry Leiba wrote: >I think that's a very odd objection. It's "Proposed Standard", yes. It's probably odd. As the comment doesn't materially affect the document, I would not classify it as an objection. >We refer to standards-track documents as "standards" (as opposed to >"Full Standard", or "STD 17", or whatever) all the time. It depends on how we read RFC 2026. :-) At 13:25 22-04-10, McDowell, Brett wrote: >How about we take the best of both suggestions and use "standard >mechanism" instead of just "standard" or just "mechanism"? That works for me. Regards, -sm From dhc@dcrocker.net Thu Apr 22 15:43:47 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB6B3A68D1 for ; Thu, 22 Apr 2010 15:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.02 X-Spam-Level: X-Spam-Status: No, score=-4.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz4TyqLsV4kj for ; Thu, 22 Apr 2010 15:43:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 5800B3A680D for ; Thu, 22 Apr 2010 15:43:46 -0700 (PDT) Received: from localhost.localdomain (m470536d0.tmodns.net [208.54.5.71]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o3MMhLgR020215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 15:43:32 -0700 X-User-Agent: K-9 Mail for Android Content-Type: multipart/mixed; boundary="----ERDG9JV9YYBW8Y9RJNIY952EHV4Y1R" MIME-Version: 1.0 From: Dave Crocker Date: Thu, 22 Apr 2010 15:43:16 -0700 To: SM , barryleiba@computer.org Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 22 Apr 2010 15:43:33 -0700 (PDT) Cc: marf@ietf.org Subject: Re: [marf] draft-ietf-marf-dkim-reporting-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 22:43:47 -0000 ------ERDG9JV9YYBW8Y9RJNIY952EHV4Y1R Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWxtb3N0IG5vdGhpbmcgaXMgYXQgZnVsbCBzdGFuZGFyZC4gIEFueXRoaW5nIGFwcHJvdmVkIG9u IHRoZSB0cmFjayBpcyBjb25zaWRlcmVkIHZhbGlkIHRvIGNhbGwgYSBzdGFuZGFyZC4KCiJTTSIg PHNtQHJlc2lzdG9yLm5ldD4gd3JvdGU6Cgo+SGkgQmFycnksCj5BdCAxMjowMSAyMi0wNC0xMCwg QmFycnkgTGVpYmEgd3JvdGU6Cj4+UkZDIDQ4NzEgaXMgb24gdGhlIFN0YW5kYXJkcyBUcmFjaywg YW5kIHRoZXJlJ3Mgbm8gcmVhc29uIHRvIGF2b2lkCj4+cmVmZXJyaW5nIHRvIGl0IGFzIGEgInN0 YW5kYXJkIi4gIFdoeSBkbyB5b3Ugb2JqZWN0IHRvIHRoYXQ/Cj4KPlJGQyA0ODcxIG1heSBiZSBv biB0aGUgU3RhbmRhcmRzIFRyYWNrIGJ1dCBpdCdzIG5vdCBhbiBJbnRlcm5ldCAKPlN0YW5kYXJk LiAgSSBkb24ndCB0aGluayBpdCdzIGEgZ29vZCBpZGVhIHRvIHJlZmVyIHRvIGl0IGFzIGEgCj5z dGFuZGFyZCBpbiBhIFdHIGRvY3VtZW50Lgo+Cj5SZWdhcmRzLAo+LXNtIAo+Cj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+bWFyZiBtYWlsaW5nIGxpc3QK Pm1hcmZAaWV0Zi5vcmcKPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFy ZgoKLS0gClNlbnQgZnJvbSBteSBBbmRyb2lkIHBob25lIHdpdGggSy05IE1haWwuIFBsZWFzZSBl eGN1c2UgbXkgYnJldml0eS4= ------ERDG9JV9YYBW8Y9RJNIY952EHV4Y1R-- From msk@cloudmark.com Mon Apr 26 10:56:08 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DEEA28C1BD for ; Mon, 26 Apr 2010 10:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-1.572, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5xVYMvaVqHh for ; Mon, 26 Apr 2010 10:56:05 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 59B5528C10D for ; Mon, 26 Apr 2010 10:56:05 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 26 Apr 2010 10:55:53 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 26 Apr 2010 10:55:53 -0700 Thread-Topic: Proposed base-04 changes based on AD feedback Thread-Index: AcrlabauN+lRXs8iSb2NhTY8v9bLXA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01D050916EEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:56:08 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01D050916EEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We got a review back from our Area Director about base-03 prior to him send= ing it out for IETF-wide last call. Nearly all of the changes are ABNF hou= sekeeping and the like, but a few issues of some substance did come up. I = made a preliminary guess at what would fly with the working group, so here = are the major points and my proposed responses. "Incidents" as defined has no upper bound. Should it? I suspect Sections = 7.2 and 7.4 make enough of a point that implementers should be wary of sill= y or garbage input, but we can be more explicit about it if needed, or even= impose a limit on the size of the number in this field. "Version" had no ABNF (actually we just had "token" there, which is mighty = generic). I've gone with the "x.y" version format. DKIM went with a singl= e integer. I'm not partial to either; I just picked one. Our "Reporting-MTA" differs noticeably from the one defined in RFC3464 (DSN= ) in that the "mta-name-type;" prefix is missing. Do we want to conform (r= educing possible confusion) or do we want to push to leave it as-is (docume= nting current practice), perhaps amending the draft to acknowledge the disc= repancy? The "Designated Experts" requirement for the IANA registrations conflicts w= ith the registry fields we name since we also require a specification docum= ent be stated in the registry. It seems simpler to just change to "Specif= ication Required" so that's what I've done. I've also added a "Status" fie= ld to both registries allowing each item to be "current", "deprecated" or "= historic", which was recommended. I can generate a full copy of what I have for base-04 if anyone wants to se= e it. Please reply with a +1 or other suggestions in each case. I'd like to get = this turned around without any apathy-induced delay. :) -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01D050916EEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We got a review back from our Area Director about base= -03 prior to him sending it out for IETF-wide last call.  Nearly all of th= e changes are ABNF housekeeping and the like, but a few issues of some substa= nce did come up.  I made a preliminary guess at what would fly with the workin= g group, so here are the major points and my proposed responses.

 

“Incidents” as defined has no upper bound.=   Should it?  I suspect Sections 7.2 and 7.4 make enough of a point that= implementers should be wary of silly or garbage input, but we can be more explicit about= it if needed, or even impose a limit on the size of the number in this field.<= o:p>

 

“Version” had no ABNF (actually we just ha= d “token” there, which is mighty generic).  I’ve gone with the “x.y&= #8221; version format.  DKIM went with a single integer.  I’m not partial to either; I just picked one.

 

Our “Reporting-MTA” differs noticeably fro= m the one defined in RFC3464 (DSN) in that the “mta-name-type;” prefi= x is missing.  Do we want to conform (reducing possible confusion) or do we want to push to leave it as-is (documenting current practice), perhaps amen= ding the draft to acknowledge the discrepancy?

 

The “Designated Experts” requirement for t= he IANA registrations conflicts with the registry fields we name since we also require a specification document be stated in the registry.   It seems simpler to just change to “Specification Required” so tha= t’s what I’ve done.  I’ve also added a “Status” fi= eld to both registries allowing each item to be “current”, “d= eprecated” or “historic”, which was recommended.

 

I can generate a full copy of what I have for base-04 = if anyone wants to see it.

 

Please reply with a +1 or other suggestions in each case.  I’d like to get this turned around without any apathy-ind= uced delay.  J

 

-MSK

 

--_000_BB012BD379D7B046ABE1472D8093C61C01D050916EEXCHC2corpclo_-- From sm@resistor.net Mon Apr 26 11:39:30 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75583A6AC3 for ; Mon, 26 Apr 2010 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAyzdNoVqCA1 for ; Mon, 26 Apr 2010 11:39:19 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 18CC33A6AC2 for ; Mon, 26 Apr 2010 11:39:18 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o3QIcgl5022104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 11:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1272307144; x=1272393544; bh=59S6rM2l6/OLmwwoRO1uO0VrFBX7ijaO3wpjWJPiJ9U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=E2DG8hvdehYpxjxPDb121NrgCkXoV/zUOjUrNjPMeDlNJXwwHQS3k2fAuRdXXDI4E mxxUEIf1V+6JODOktJbsbKUK7lajcy9nq40tQhG5qJICrFrYqWyzm3CLS0g7qsdkHK UHzGa8xRxBt/pHWB02pTgN83hOHyxZBuSPZLMyrs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1272307144; x=1272393544; bh=59S6rM2l6/OLmwwoRO1uO0VrFBX7ijaO3wpjWJPiJ9U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=PoNHTHpGF1vYMsyPJGXbZlP/Y05S5ot6QjLDivu0NfscarlQEue0paxAHrTuvSx/2 lUncHhcCpSc9TyEt7BiOgO16SOxlMLAVj+v0pgeLfK9IUrHJbZiGbgK83x/Ys7fARN vjiO2BoSarKP10x18G851xvbh3+I8ezI5k2taBT0= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=Oa7GoG2ShQFRaAb/xzuxAog1eYfsYRLzR3pAxZQqSP1GgUs+lo/5xAAy+DCFdbVH8 uC8tPK9jLL54/kCTYWOzAY3ECHiGf5b6cmJ2SkiSKCep8K6WJOGcMtsrfa9rtG2LFxa rVxMSS8LnVS/qLVulw62PA0eWjTsoOOk1CRqk3E= Message-Id: <6.2.5.6.2.20100426111739.0a5c9c88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Apr 2010 11:38:09 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:39:31 -0000 Hi Murray, At 10:55 26-04-10, Murray S. Kucherawy wrote: >"Incidents" as defined has no upper bound. Should it? I suspect >Sections 7.2 and 7.4 make enough of a point that implementers should >be wary of silly or garbage input, but we can be more explicit about >it if needed, or even impose a limit on the size of the number in this field. In Section 3.2, you could have: "Incidents" contains an unsigned 32-bit integer. >Our "Reporting-MTA" differs noticeably from the one defined in >RFC3464 (DSN) in that the "mta-name-type;" prefix is missing. Do we >want to conform (reducing possible confusion) or do we want to push >to leave it as-is (documenting current practice), perhaps amending >the draft to acknowledge the discrepancy? I suggest following RFC 3464 on that. Regards, -sm From msk@cloudmark.com Mon Apr 26 12:30:17 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B443A6ADD for ; Mon, 26 Apr 2010 12:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s9pFXWGfcDc for ; Mon, 26 Apr 2010 12:30:16 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 536D73A6AD3 for ; Mon, 26 Apr 2010 12:30:16 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 26 Apr 2010 12:30:04 -0700 From: "Murray S. Kucherawy" To: SM Date: Mon, 26 Apr 2010 12:30:03 -0700 Thread-Topic: [marf] Proposed base-04 changes based on AD feedback Thread-Index: Acrlb8CkMX67Lc5ZQB+TZhPISgTQ4AABvQeA Message-ID: References: <6.2.5.6.2.20100426111739.0a5c9c88@resistor.net> In-Reply-To: <6.2.5.6.2.20100426111739.0a5c9c88@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 19:30:17 -0000 > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Monday, April 26, 2010 11:38 AM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] Proposed base-04 changes based on AD feedback >=20 > Hi Murray, > At 10:55 26-04-10, Murray S. Kucherawy wrote: > >"Incidents" as defined has no upper bound. Should it? I suspect > >Sections 7.2 and 7.4 make enough of a point that implementers should > >be wary of silly or garbage input, but we can be more explicit about > >it if needed, or even impose a limit on the size of the number in this > field. >=20 > In Section 3.2, you could have: >=20 > "Incidents" contains an unsigned 32-bit integer. Alexey suggested that as well, so I'll include that text. > >Our "Reporting-MTA" differs noticeably from the one defined in > >RFC3464 (DSN) in that the "mta-name-type;" prefix is missing. Do we > >want to conform (reducing possible confusion) or do we want to push > >to leave it as-is (documenting current practice), perhaps amending > >the draft to acknowledge the discrepancy? >=20 > I suggest following RFC 3464 on that. I think that would be my personal preference just because I would expect so= me resistance to having two different formats for something called "Reporti= ng-MTA", but I'm not an implementer so I'd like to hear from those folks. From jdfalk-lists@cybernothing.org Mon Apr 26 13:31:12 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7966B28C0DD for ; Mon, 26 Apr 2010 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_BSP_OTHER=-0.1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfzFjKGKw4EB for ; Mon, 26 Apr 2010 13:31:11 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 8150F3A68F6 for ; Mon, 26 Apr 2010 13:31:10 -0700 (PDT) Received: from [10.0.2.90] (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3QKUsiD005516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Apr 2010 14:30:57 -0600 References: <6.2.5.6.2.20100426111739.0a5c9c88@resistor.net> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <14C13FAD-7206-4B0C-87B6-5AFE2175B404@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Mon, 26 Apr 2010 14:30:49 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 20:31:12 -0000 On Apr 26, 2010, at 1:30 PM, Murray S. Kucherawy wrote: >>> Our "Reporting-MTA" differs noticeably from the one defined in >>> RFC3464 (DSN) in that the "mta-name-type;" prefix is missing. Do we >>> want to conform (reducing possible confusion) or do we want to push >>> to leave it as-is (documenting current practice), perhaps amending >>> the draft to acknowledge the discrepancy? >>=20 >> I suggest following RFC 3464 on that. >=20 > I think that would be my personal preference just because I would = expect some resistance to having two different formats for something = called "Reporting-MTA", but I'm not an implementer so I'd like to hear = from those folks. As an implementer: we don't include that field, so no strong opinion = either way. As a WG participant: I'm wary of depreciating current practice without a = really strong rationale. But, maybe it's okay, since we're also = updating the version number: ARF metadata parsers could reliably assume = that version 1 has the new format, and version 0.1 has the old. -- J.D. Falk Return Path Inc From msk@cloudmark.com Mon Apr 26 16:06:11 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7053A6BEA for ; Mon, 26 Apr 2010 16:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-1.567, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bURpLDAuF61h for ; Mon, 26 Apr 2010 16:05:55 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id E77EE3A6BF1 for ; Mon, 26 Apr 2010 16:05:51 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 26 Apr 2010 16:05:39 -0700 From: "Murray S. Kucherawy" To: "Murray S. Kucherawy" , "marf@ietf.org" Date: Mon, 26 Apr 2010 16:05:39 -0700 Thread-Topic: Proposed base-04 changes based on AD feedback Thread-Index: AcrlabauN+lRXs8iSb2NhTY8v9bLXAAKx6rQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01D0509273EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 23:06:11 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01D0509273EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After further off-list chatter, I've changed the version to a single-digit = form instead of "x.y", and "Incidents" is bound to be an unsigned 32-bit in= teger. Feedback from implementers about "Reporting-MTA" is probably the most impor= tant one. From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Monday, April 26, 2010 10:56 AM To: marf@ietf.org Subject: [marf] Proposed base-04 changes based on AD feedback We got a review back from our Area Director about base-03 prior to him send= ing it out for IETF-wide last call. Nearly all of the changes are ABNF hou= sekeeping and the like, but a few issues of some substance did come up. I = made a preliminary guess at what would fly with the working group, so here = are the major points and my proposed responses. "Incidents" as defined has no upper bound. Should it? I suspect Sections = 7.2 and 7.4 make enough of a point that implementers should be wary of sill= y or garbage input, but we can be more explicit about it if needed, or even= impose a limit on the size of the number in this field. "Version" had no ABNF (actually we just had "token" there, which is mighty = generic). I've gone with the "x.y" version format. DKIM went with a singl= e integer. I'm not partial to either; I just picked one. Our "Reporting-MTA" differs noticeably from the one defined in RFC3464 (DSN= ) in that the "mta-name-type;" prefix is missing. Do we want to conform (r= educing possible confusion) or do we want to push to leave it as-is (docume= nting current practice), perhaps amending the draft to acknowledge the disc= repancy? The "Designated Experts" requirement for the IANA registrations conflicts w= ith the registry fields we name since we also require a specification docum= ent be stated in the registry. It seems simpler to just change to "Specif= ication Required" so that's what I've done. I've also added a "Status" fie= ld to both registries allowing each item to be "current", "deprecated" or "= historic", which was recommended. I can generate a full copy of what I have for base-04 if anyone wants to se= e it. Please reply with a +1 or other suggestions in each case. I'd like to get = this turned around without any apathy-induced delay. :) -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01D0509273EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After further off-list c= hatter, I’ve changed the version to a single-digit form instead of “x.y= ”, and “Incidents” is bound to be an unsigned 32-bit integer.

 =

Feedback from implemente= rs about “Reporting-MTA” is probably the most important one.<= /span>

 =

From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mu= rray S. Kucherawy
Sent: Monday, April 26, 2010 10:56 AM
To: marf@ietf.org
Subject: [marf] Proposed base-04 changes based on AD feedback

 

We got a review back from our Area Director about base= -03 prior to him sending it out for IETF-wide last call.  Nearly all of th= e changes are ABNF housekeeping and the like, but a few issues of some substa= nce did come up.  I made a preliminary guess at what would fly with the working group, so here are the major points and my proposed responses.=

 

“Incidents” as defined has no upper bound.=   Should it?  I suspect Sections 7.2 and 7.4 make enough of a point that implementers should be wary of silly or garbage input, but we can be more explicit about it if needed, or even impose a limit on the size of the numb= er in this field.

 

“Version” had no ABNF (actually we just ha= d “token” there, which is mighty generic).  I’ve gone with the “x.y” = version format.  DKIM went with a single integer.  I’m not partial to either; I j= ust picked one.

 

Our “Reporting-MTA” differs noticeably fro= m the one defined in RFC3464 (DSN) in that the “mta-name-type;” prefix is missing= .  Do we want to conform (reducing possible confusion) or do we want to push to leav= e it as-is (documenting current practice), perhaps amending the draft to acknowl= edge the discrepancy?

 

The “Designated Experts” requirement for t= he IANA registrations conflicts with the registry fields we name since we also requ= ire a specification document be stated in the registry.   It seems simpler to just change to “Specification Required” so that̵= 7;s what I’ve done.  I’ve also added a “Status” field to both regi= stries allowing each item to be “current”, “deprecated” or “histor= ic”, which was recommended.

 

I can generate a full copy of what I have for base-04 = if anyone wants to see it.

 

Please reply with a +1 or other suggestions in each case.  I’d like to get this turned around without any apathy-ind= uced delay.  J

 

-MSK

 

--_000_BB012BD379D7B046ABE1472D8093C61C01D0509273EXCHC2corpclo_-- From yakov@shaftek.org Mon Apr 26 18:44:00 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA2C3A6C05 for ; Mon, 26 Apr 2010 18:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIW2srCQsSh5 for ; Mon, 26 Apr 2010 18:43:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6B5873A6765 for ; Mon, 26 Apr 2010 18:43:59 -0700 (PDT) Received: by wwe15 with SMTP id 15so681712wwe.31 for ; Mon, 26 Apr 2010 18:43:44 -0700 (PDT) Received: by 10.216.88.134 with SMTP id a6mr975951wef.66.1272332624066; Mon, 26 Apr 2010 18:43:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.21.143 with HTTP; Mon, 26 Apr 2010 18:43:23 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Mon, 26 Apr 2010 21:43:23 -0400 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 01:44:00 -0000 On Mon, Apr 26, 2010 at 7:05 PM, Murray S. Kucherawy wr= ote: > After further off-list chatter, I=92ve changed the version to a single-di= git > form instead of =93x.y=94, and =93Incidents=94 is bound to be an unsigned= 32-bit > integer. > ... Will switching from x.y to a single digit cause problems with current implementations? Yakov From yakov@shaftek.org Mon Apr 26 19:01:30 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E3628C1D0 for ; Mon, 26 Apr 2010 19:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd0CG9YgMlaX for ; Mon, 26 Apr 2010 19:01:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3F5223A6C05 for ; Mon, 26 Apr 2010 19:01:28 -0700 (PDT) Received: by wwe15 with SMTP id 15so688182wwe.31 for ; Mon, 26 Apr 2010 19:01:12 -0700 (PDT) Received: by 10.216.168.8 with SMTP id j8mr1102123wel.192.1272333672181; Mon, 26 Apr 2010 19:01:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.21.143 with HTTP; Mon, 26 Apr 2010 19:00:52 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Mon, 26 Apr 2010 22:00:52 -0400 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 02:01:30 -0000 On Mon, Apr 26, 2010 at 1:55 PM, Murray S. Kucherawy wr= ote: > We got a review back from our Area Director about base-03 prior to him > sending it out for IETF-wide last call.=A0 Nearly all of the changes are = ABNF > housekeeping and the like, but a few issues of some substance did come up= . > I made a preliminary guess at what would fly with the working group, so h= ere > are the major points and my proposed responses. > ... > > > Our =93Reporting-MTA=94 differs noticeably from the one defined in RFC346= 4 (DSN) > in that the =93mta-name-type;=94 prefix is missing.=A0 Do we want to conf= orm > (reducing possible confusion) or do we want to push to leave it as-is > (documenting current practice), perhaps amending the draft to acknowledge > the discrepancy? > > Since we are referencing the RFC 3464, it needs to match that document. Any existing implementations should have been following RFC 3464 format anyway, since that is how it was always defined in the ARF drafts even though the ABNF did not match. It is also interesting to note that this field was only present since version "-04" / March 2008: http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-= feedback-report-04.txt It was prompted by this email: http://mipassoc.org/pipermail/abuse-feedback-report/2007q4/000209.html There may be a larger question of whether it is wise to tie this draft to RFC 3464's IANA registries, but that may be a discussion for a different time. > > The =93Designated Experts=94 requirement for the IANA registrations confl= icts > with the registry fields we name since we also require a specification > document be stated in the registry.=A0 =A0It seems simpler to just change= to > =93Specification Required=94 so that=92s what I=92ve done.=A0 I=92ve also= added a > =93Status=94 field to both registries allowing each item to be =93current= =94, > =93deprecated=94 or =93historic=94, which was recommended. > I am a bit vary of allowing only Specification Required without a designated expert, Why can't we have a procedure similar to MIME types where a specification and an expert review is needed? On the other hand, if "specification required" means that the RFC Editor will ask the IESG for their opinion, that may be sufficient. Also, what is the difference between deprecated and historic? Should we just have one of them ("deprecated")? Yakov From msk@cloudmark.com Mon Apr 26 21:36:35 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E373A6883 for ; Mon, 26 Apr 2010 21:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pyhgERT69Rp for ; Mon, 26 Apr 2010 21:36:35 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id EC44F3A682F for ; Mon, 26 Apr 2010 21:36:34 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 26 Apr 2010 21:36:22 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich Date: Mon, 26 Apr 2010 21:36:21 -0700 Thread-Topic: [marf] Proposed base-04 changes based on AD feedback Thread-Index: AcrlqxO42amaMVRLTP+XOOrVsQ+8ywAGAx9g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 04:36:36 -0000 > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Monday, April 26, 2010 6:43 PM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] Proposed base-04 changes based on AD feedback >=20 > On Mon, Apr 26, 2010 at 7:05 PM, Murray S. Kucherawy > wrote: > > After further off-list chatter, I've changed the version to a single- > digit > > form instead of "x.y", and "Incidents" is bound to be an unsigned 32- > bit > > integer. > > > ... >=20 > Will switching from x.y to a single digit cause problems with current > implementations? I suspect not, since there's only been one version so far. But the impleme= nters are being awfully quiet... From msk@cloudmark.com Mon Apr 26 21:40:11 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFCE028C1CC for ; Mon, 26 Apr 2010 21:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18E7BYNNj3GO for ; Mon, 26 Apr 2010 21:40:10 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id D8C113A67F3 for ; Mon, 26 Apr 2010 21:40:10 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 26 Apr 2010 21:39:58 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich Date: Mon, 26 Apr 2010 21:39:57 -0700 Thread-Topic: [marf] Proposed base-04 changes based on AD feedback Thread-Index: AcrlrYRsc3Q5vKNWRryTn15C45SsPQAFa0jg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 04:40:11 -0000 > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Monday, April 26, 2010 7:01 PM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] Proposed base-04 changes based on AD feedback >=20 > Since we are referencing the RFC 3464, it needs to match that > document. Any existing implementations should have been following RFC > 3464 format anyway, since that is how it was always defined in the ARF > drafts even though the ABNF did not match. The ABNF should probably be changed to match RFC3464's then, if that's been= the intent all along. I'll dig that up and make the change. I was the one that added the ABNF to the spec, but I seem to recall was doi= ng so based on an example and not on the basis RFCs. So there's at least o= ne broken implementation out there. :-) > > The "Designated Experts" requirement for the IANA registrations > conflicts > > with the registry fields we name since we also require a > specification > > document be stated in the registry.=A0 =A0It seems simpler to just chan= ge > to > > "Specification Required" so that's what I've done.=A0 I've also added a > > "Status" field to both registries allowing each item to be "current", > > "deprecated" or "historic", which was recommended. >=20 > I am a bit vary of allowing only Specification Required without a > designated expert, Why can't we have a procedure similar to MIME types > where a specification and an expert review is needed? According to RFC5226, Specification Required includes a Designated Expert, = selected by the IESG. Where the publication is an RFC, I believe the IESG = has the discretion to declare that the working group (if there was one) cou= nts as the Expert. =20 > Also, what is the difference between deprecated and historic? Should > we just have one of them ("deprecated")? I would say "deprecated" is "still supported, but use discouraged [in favou= r of something else that's newer]," while "historic" is "no longer supporte= d, but still documented for informational purposes." From root@core3.amsl.com Fri Apr 30 09:15:01 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 717AA28C111; Fri, 30 Apr 2010 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100430161501.717AA28C111@core3.amsl.com> Date: Fri, 30 Apr 2010 09:15:01 -0700 (PDT) Cc: marf@ietf.org Subject: [marf] I-D Action:draft-ietf-marf-base-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 16:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF. Title : An Extensible Format for Email Feedback Reports Author(s) : Y. Shafranovich, et al. Filename : draft-ietf-marf-base-04.txt Pages : 34 Date : 2010-04-30 This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-base-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-marf-base-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-30090524.I-D@ietf.org> --NextPart-- From jdfalk-lists@cybernothing.org Fri Apr 30 11:21:59 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE383A6A2C for ; Fri, 30 Apr 2010 11:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.306 X-Spam-Level: X-Spam-Status: No, score=-5.306 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_40=-0.185, RCVD_IN_BSP_OTHER=-0.1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StN45au+A86A for ; Fri, 30 Apr 2010 11:21:58 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 1DBED28C270 for ; Fri, 30 Apr 2010 11:20:32 -0700 (PDT) Received: from [10.0.2.22] (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3UIKFuS020263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 30 Apr 2010 12:20:17 -0600 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Fri, 30 Apr 2010 12:20:09 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 18:21:59 -0000 On Apr 26, 2010, at 10:36 PM, Murray S. Kucherawy wrote: > I suspect not, since there's only been one version so far. But the = implementers are being awfully quiet... I believe our ARF parsing code ignores the version number, because (as = you say) there's been only one so far. And so long as the differences = between 0.1 and 1 are minimal, we'll probably continue ignoring the = version number. -- J.D. Falk Return Path Inc From wwwrun@core3.amsl.com Fri Apr 30 11:46:29 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CE38A3A6B90; Fri, 30 Apr 2010 11:46:29 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100430184629.CE38A3A6B90@core3.amsl.com> Date: Fri, 30 Apr 2010 11:46:29 -0700 (PDT) Cc: marf@ietf.org Subject: [marf] Last Call: draft-ietf-marf-base (An Extensible Format for Email Feedback Reports) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 18:46:29 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'An Extensible Format for Email Feedback Reports ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-marf-base-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19559&rfc_flag=0