From jdfalk-lists@cybernothing.org Fri Jul 2 07:42: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 34B7D3A67B2 for ; Fri, 2 Jul 2010 07:42:25 -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 1bKKC0M0bnTr for ; Fri, 2 Jul 2010 07:42:24 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id BC8493A67A4 for ; Fri, 2 Jul 2010 07:42:23 -0700 (PDT) Received: from [192.168.0.5] (174-29-215-223.hlrn.qwest.net [174.29.215.223]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o62EgXKG005633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 2 Jul 2010 08:42:35 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o62EgXKG005633 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1278081755; bh=UQ9TzI7hN9nnhL2SPt0ISdp2WtPcjF476bZsvPDv8 80=; h=Subject:From:Content-Type:Message-Id:Date:To: Content-Transfer-Encoding:Mime-Version; b=Euva4LHVGGWRObRG0Auor3cL 5wrFkeTOEE1BqErCPyI2Pea07FOLKbP0Y3lZxOfsjc3TK2V4g4ztImbrJeLHfAuXQhy 0Sk4za/7U+frWqGOhp/9vz4LMxsa/EoffcbEvnJLYu97xKbcKAwxwXwR8Vxi0mgV6dh w2oxjIYkv8NeI= From: "J.D. Falk" Content-Type: text/plain; charset=us-ascii Message-Id: <19367E84-CF27-4B2F-B088-99914D3C8200@cybernothing.org> Date: Fri, 2 Jul 2010 08:42:27 -0600 To: Message Abuse Report Format working group Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [marf] reporting-discovery updates 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, 02 Jul 2010 14:42:25 -0000 I'd hoped to have an update finished before this (U.S.) holiday weekend, = but instead it should be uploaded around the middle of next week. = This'll incorporate comments from Alessandro & others. I'll also work on a review of current FBL subscriber acceptance = criteria, as Mike Adkins suggested (unless someone else wants to jump on = that sooner.) -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Sun Jul 4 14:31:22 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 5CBCD3A67B1 for ; Sun, 4 Jul 2010 14:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 psUau3BPYn0T for ; Sun, 4 Jul 2010 14:31:21 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 29DEE3A6781 for ; Sun, 4 Jul 2010 14:31:21 -0700 (PDT) Received: from [192.168.0.5] (174-29-215-223.hlrn.qwest.net [174.29.215.223]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o64LVJVF017618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 4 Jul 2010 15:31:21 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o64LVJVF017618 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1278279081; bh=YsGXwUPV5TUkIunCZ7dunRfYQfMnXi1tesykH+xTK DY=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=VSq1RoCDQxJDcl9b P3/j48JNkKVPd6mSwbGP5qFr5Z/kJ8OGI4jSUi2uuBf5d1mmogJ6u/wX6SWCxLIekyK 4X5eMhSbF8yatHZ5iLgGKrXMDRaWA2iBIrrXRj/AX7H8LL95Dmn+fihpQ/+kLQRv3Md AYJUW8WO3p39VIrTrajhU= References: <20100622040625.97472.qmail@joyce.lan><22377F8C-4BFB-4F4D-AC57-B81A7531D86E@cybernothing.org><6.2.5.6.2.20100622114236.07390908@resistor.net> <8CCE2028D7A01BF-9A8-2DF3@Webmail-m105.sysops.aol.com> In-Reply-To: <8CCE2028D7A01BF-9A8-2DF3@Webmail-m105.sysops.aol.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <4776BFF0-87B0-499A-A4C6-4DFA2D8C0E01@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Sun, 4 Jul 2010 15:31:09 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1081) Subject: [marf] list of current approval criteria (was Re: Poll: Importing draft-jdfalk-marf-reporting-discovery) 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: Sun, 04 Jul 2010 21:31:22 -0000 On Jun 24, 2010, at 4:20 PM, madkins05@aol.com wrote: > If you are going to put together a list of potential discovery = options, you might want to start by collecting a list of current = approval criteria. That would give you an idea of how acceptable the = various discovery options would be. A fine idea...but unfortunately, most feedback generators don't publish = their criteria. I collected what I could find into the following = document: http://www.ietf.org/id/draft-jdfalk-marf-acceptance-criteria-00.txt (In many cases I have personal knowledge which goes far beyond the = published information, but I didn't want to include anything non-public = here without asking permission first.) -- J.D. Falk Return Path Inc From vesely@tana.it Mon Jul 5 03:52: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 676103A687D for ; Mon, 5 Jul 2010 03:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[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 NzosrYOWbAHX for ; Mon, 5 Jul 2010 03:52:56 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 39C423A63EC for ; Mon, 5 Jul 2010 03:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1278327175; bh=32Wx3unzvGW/5Flce9k+UOkp/PNSxnlBawaMfN8YpY8=; l=1364; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=LxuHIlGlUOoNvEuQMTDS7yIUF0NR768kZKWI3dJAlrxTi9AAEGxwSuxVsFuB1qxs8 bFEPiih/rcTPhsEcTdbIY8P4f0n2thh5en+vHpKO+VA96FO5FzTR/w5pViEdEZL3ch GTkcdnbmtUK+DciQODs0zeIRN23GCdnR6vOnw9xw= 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; Mon, 05 Jul 2010 12:52:55 +0200 id 00000000005DC02B.000000004C31B987.00001D16 Message-ID: <4C31B987.8070601@tana.it> Date: Mon, 05 Jul 2010 12:52:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Message Abuse Report Format working group References: <20100622040625.97472.qmail@joyce.lan><22377F8C-4BFB-4F4D-AC57-B81A7531D86E@cybernothing.org><6.2.5.6.2.20100622114236.07390908@resistor.net> <8CCE2028D7A01BF-9A8-2DF3@Webmail-m105.sysops.aol.com> <4776BFF0-87B0-499A-A4C6-4DFA2D8C0E01@cybernothing.org> In-Reply-To: <4776BFF0-87B0-499A-A4C6-4DFA2D8C0E01@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] list of current approval criteria 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, 05 Jul 2010 10:52:57 -0000 On 04/Jul/10 23:31, J.D. Falk wrote: > unfortunately, most feedback generators don't publish their criteria. I collected what I could find into the following document: > > http://www.ietf.org/id/draft-jdfalk-marf-acceptance-criteria-00.txt A nice starting point, although it is difficult to deduce the nature of FBLs from their approval criteria. In section 4 (Comcast) the line "IPs with a Sender Score of 30 to 60 cannot appear on any DNSBLs" is worded badly. They probably mean the same of the corresponding point in section 5 (Cox), which is worded much better. However, the 3rd point in the latter policy explicitly states that FBL access will be denied for small senders who have no SS score. Statistical relevance has been discussed before, but this kind of requirement may also reveal some difficulties within the approval process. Unfortunately, SS doesn't publish much about the actual meaning of "a sufficient volume of email". Besides size, it is striking that the reviewed operators are all US-based, with the exception of OpenSRS which is located in Toronto, and possibly Yahoo!. I'd guess that high volume Japanese local senders may get a missing SS score as well. Is it so? One final nit, section 2 misses AOL's 2nd requirement (The domain WHOIS for each IP's RDNS contains the FBL email domain). From jdfalk-lists@cybernothing.org Mon Jul 5 05:40: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 E5B7C3A690A for ; Mon, 5 Jul 2010 05:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, 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 Rf8fsvO8ftLD for ; Mon, 5 Jul 2010 05:40:14 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id B4DC73A693A for ; Mon, 5 Jul 2010 05:40:14 -0700 (PDT) Received: from [192.168.0.5] (174-29-215-223.hlrn.qwest.net [174.29.215.223]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o65CeCnW030238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 5 Jul 2010 06:40:15 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o65CeCnW030238 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1278333615; bh=382Q3EdNspVq5+HF0s+u23RPRh5f8tpXNVBb1trsS +8=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=Scm8/449ne6bmMZi gK/Yxi0VTRB9ln1H8Ss6OpNFMjNt7vqPCDFChoMasRhpT4VB6Ex68OcbgV1+I3hyZP4 6fqYnbbxOG0P1Uuk/YWx/V41py+MuUFAepgs5vS03CxaKh2NENp3oeThBNRFAZXkzkW OU6q5QuawgccXW/9+KUnw= References: <20100622040625.97472.qmail@joyce.lan><22377F8C-4BFB-4F4D-AC57-B81A7531D86E@cybernothing.org><6.2.5.6.2.20100622114236.07390908@resistor.net> <8CCE2028D7A01BF-9A8-2DF3@Webmail-m105.sysops.aol.com> <4776BFF0-87B0-499A-A4C6-4DFA2D8C0E01@cybernothing.org> <4C31B987.8070601@tana.it> In-Reply-To: <4C31B987.8070601@tana.it> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <39E5378D-CC99-4800-ABA4-EC1CB42AAA3C@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Mon, 5 Jul 2010 06:40:02 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1081) Subject: Re: [marf] list of current approval criteria 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, 05 Jul 2010 12:40:16 -0000 On Jul 5, 2010, at 4:52 AM, Alessandro Vesely wrote: > On 04/Jul/10 23:31, J.D. Falk wrote: >> unfortunately, most feedback generators don't publish their criteria. = I collected what I could find into the following document: >>=20 >> http://www.ietf.org/id/draft-jdfalk-marf-acceptance-criteria-00.txt >=20 > A nice starting point, although it is difficult to deduce the nature = of FBLs from their approval criteria. Yeah, it's not intended as a descriptive or BCP document. > In section 4 (Comcast) the line "IPs with a Sender Score of 30 to 60 = cannot appear on any DNSBLs" is worded badly. They probably mean the = same of the corresponding point in section 5 (Cox), which is worded much = better. However, the 3rd point in the latter policy explicitly states = that FBL access will be denied for small senders who have no SS score. = Statistical relevance has been discussed before, but this kind of = requirement may also reveal some difficulties within the approval = process. >=20 > Unfortunately, SS doesn't publish much about the actual meaning of "a = sufficient volume of email". Besides size, it is striking that the = reviewed operators are all US-based, with the exception of OpenSRS which = is located in Toronto, and possibly Yahoo!. I'd guess that high volume = Japanese local senders may get a missing SS score as well. Is it so? Like any reputation system, Sender Score is based on the data available. = That includes data contributed by both Comcast and Cox (among others), = so it's relevant for their systems -- if they've seen sufficient traffic = from an IP, there'll be a score calculated. But this document only = lists what the published criteria currently are; it's not an attempt to = say what the criteria could be, or should be. The one nearly-universal thing is that they try to correlate the request = with ownership of the domain and IPs, and they do this out of band by = sending a confirmation email containing a (presumably) unique HTTP URL. = I believe that an advertisement in DNS could provide an equal (or = better) level of authentication, and speed up the subscription process = because a prospective subscriber could be approved or denied immediately = rather than waiting for their abuse@/postmaster@ staff to respond. After that, I don't see much opportunity for standardization -- though = I'd certainly support a BCP calling for Feedback Generators to make more = of their criteria public. -- J.D. Falk Return Path Inc From zachary.zeltsan@alcatel-lucent.com Mon Jul 5 06:31: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 545FD3A67F9 for ; Mon, 5 Jul 2010 06:31:37 -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 CQp6DlsQfqwE for ; Mon, 5 Jul 2010 06:31:36 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 8A4C33A698D for ; Mon, 5 Jul 2010 06:31:33 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o65DVYsv006945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Jul 2010 08:31:34 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o65DVYfe029383 for ; Mon, 5 Jul 2010 08:31:34 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 5 Jul 2010 08:31:34 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'marf@ietf.org'" Date: Mon, 5 Jul 2010 08:31:33 -0500 Thread-Topic: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 Thread-Index: AcscRGjg1uHn6/O0T/+tybWI2qMghAAARjXA Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Mon, 05 Jul 2010 13:31:37 -0000 Please review this new draft http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt=20 Zachary -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Monday, July 05, 2010 9:17 AM To: Zeltsan, Zachary (Zachary) Cc: Cai, Yigang (Yigang); Shanker, Gyan (Gyan); Torabi, Mohammad (Moh) Subject: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00= =20 A new version of I-D, draft-cai-smsc-mmsc-reporting-marf-00.txt has been su= ccessfully submitted by Zachary Zeltsan and posted to the IETF repository. Filename: draft-cai-smsc-mmsc-reporting-marf Revision: 00 Title: An Extensible Format for SMSC/MMSC Feedback Reports Creation_date: 2010-07-05 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document defines an extensible format and MIME type that may be used by SMSC or MMSC to report feedback about received SMS/MMS with message abuses. = =20 The IETF Secretariat. From sm@resistor.net Mon Jul 5 22:47:53 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 C41983A6A15 for ; Mon, 5 Jul 2010 22:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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 mgjeT4rrXeuO for ; Mon, 5 Jul 2010 22:47:50 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id EDD843A68BD for ; Mon, 5 Jul 2010 22:47:46 -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 o665lEon021468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jul 2010 22:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1278395252; x=1278481652; bh=WeL23EWHN30oKFoNY4XyCZIUoh6lrqLqUkznbdAII7Q=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=AE5cPInaFxB/R0I4JjRThjywzlUs3dEiGu3e2Y2MJjQtLMMXblmjlxzg4+Rzg8ozq Eqm4pZS+L/JWmzpWQYVeAMgHjsFnwEYI+Lci9dBZ85IRi5wVIKXziZaK+vGiVR0NMc rgmt7L1kZH1+x967pTd9ZiYajFNrVwrFnoxIoFw0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1278395252; x=1278481652; bh=WeL23EWHN30oKFoNY4XyCZIUoh6lrqLqUkznbdAII7Q=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=pjhyAdGLrYhfRbQITyqZ2FUeXpI9lcBCSOCgAamnMgV6fQW36T9/8vbJbayjLT54M TWJWT6tIAXfxdkupJbQhIrhvCiAjTpeC1DHGG+cc7yiL38d/y+zCPv5bNNExA8CTWP 1YdzCkShCfcTAvYRVpLI+HH7RjTM78DdBSfT9HXE= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=aHm6jZ0c3z6Da0XaGzTllnQuYEivMrM2IT2yrTaamH++/sjqp7BwTNTp8QihZA4Bw eHYC1Yx7O2RAC6XTTRWgV6/YkDGfv9ZRmI5acXDyOEjyxnLROp7peqzJorU0wVBDuuC CYJG6ITWUnp7S0YwaPt6LT5LvEXA9XiArBFLHx0= Message-Id: <6.2.5.6.2.20100705223859.06275830@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 05 Jul 2010 22:46:42 -0700 To: "Zeltsan, Zachary (Zachary)" From: SM In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3. ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Tue, 06 Jul 2010 05:47:53 -0000 Hi Zachary, At 06:31 05-07-10, Zeltsan, Zachary (Zachary) wrote: >Please review this new draft >http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt In the Introduction Section: "This document introduces a SMS/MMS message abuse report and defines the content and report format; therefore, extends [draft-ietf-marf-base] to add features required for SMSC/MMSC reporting." What format is used for SMS/MMS messages? In Section 3: "The following is a non-exhaustive list of the specific parameters that SHOULD be included as optional fields in the base reporting MIME feedback reports, but are RECOMMENDED for SMS/MMS message reporting:" Is the list of parameters correct? How should they be included as optional fields? The authors in the Normative References Section for draft-ietf-marf-base is incorrect. Regards, -sm From msk@cloudmark.com Mon Jul 5 23:25: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 63CE73A6A24 for ; Mon, 5 Jul 2010 23:25:40 -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 ikYszbbiwGtN for ; Mon, 5 Jul 2010 23:25:39 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id C4BCC3A6A20 for ; Mon, 5 Jul 2010 23:25:39 -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, 5 Jul 2010 23:25:41 -0700 From: "Murray S. Kucherawy" To: "Zeltsan, Zachary (Zachary)" , "'marf@ietf.org'" Date: Mon, 5 Jul 2010 23:25:40 -0700 Thread-Topic: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 Thread-Index: AcscRGjg1uHn6/O0T/+tybWI2qMghAAARjXAACOb5oA= Message-ID: References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Tue, 06 Jul 2010 06:25:40 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Zeltsan, Zachary (Zachary) > Sent: Monday, July 05, 2010 6:32 AM > To: 'marf@ietf.org' > Subject: [marf] FW: New Version Notification for draft-cai-smsc-mmsc- > reporting-marf-00 >=20 > Please review this new draft > http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt >=20 > Zachary Hi Zachary, The MARF working group is chartered to keep its work in parallel with what = the Open Mobile Alliance is up to in the area of mobile spam reporting. Ar= e you familiar with their SpamRep proposal? -MSK From alex@bobotek.net Tue Jul 6 00:16: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 A94B83A68D5 for ; Tue, 6 Jul 2010 00:16:18 -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 NSljj4brxDax for ; Tue, 6 Jul 2010 00:16:17 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 788223A68C2 for ; Tue, 6 Jul 2010 00:16:17 -0700 (PDT) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta10.emeryville.ca.mail.comcast.net with comcast id eXFd1e0011vN32cAAXGKtw; Tue, 06 Jul 2010 07:16:19 +0000 Received: from bobo1.bobotek.net ([71.227.197.27]) by omta22.emeryville.ca.mail.comcast.net with comcast id eXGJ1e0010bxBZT8iXGJoE; Tue, 06 Jul 2010 07:16:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jul 2010 00:15:49 -0700 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 Thread-Index: AcscRGjg1uHn6/O0T/+tybWI2qMghAAARjXAACOb5oAAADtHMA== References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "Alex Bobotek" To: "Murray S. Kucherawy" , "Zeltsan, Zachary (Zachary)" , Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Tue, 06 Jul 2010 07:16:18 -0000 I think it would make a lot of sense for OMA SpamRep and IETF MARF to either converge on SMS/MMS, or clearly identify reasons why they should be kept separate. =20 There seems to be difference in scope. SpamRep is intended to support SMS/MMS feedback from both device-based applications such as user agents (e.g., 'this is spam' buttons in phones), and network nodes such as SMSCs inside carrier networks. This is significantly different from the scope defined (or at least alluded to) in the introduction to draft-cai-smsc-mmsc-reporting-marf-00: receiving reports from SMSCs and MMSCs. One of the challenges I faced in drafting the SMS portion of the OMA spec is accommodating the SMS gateway functions (e.g., OTA-->GSM MAP, GSM MAP-->SMPP) that transform a message as it passes through a network and is finally stored in a device in an implementation-dependent format; it is challenging to provide a uniform abuse report format which is useful at all points in the message flow. However, IMHO an abuse-reporting format can be made flexible enough to accommodate all of these cases by incorporating a sufficient number of optional parameters. The SpamRep v1.0 specification is now largely complete, with consistency review coming in the near future. So comments are welcome. While only OMA member companies may submit change requests, many member companies are receptive to input from individuals and non-members. =20 Draft OMA SpamRep specs are available at: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/Permanent_documents/, including the latest 6/24/2010 draft. =20 Change requests (the vehicle by which the draft spec is modified) are at: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/2010/=20 Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Monday, July 05, 2010 11:26 PM To: Zeltsan, Zachary (Zachary); 'marf@ietf.org' Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Zeltsan, Zachary (Zachary) > Sent: Monday, July 05, 2010 6:32 AM > To: 'marf@ietf.org' > Subject: [marf] FW: New Version Notification for draft-cai-smsc-mmsc- > reporting-marf-00 >=20 > Please review this new draft > http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt >=20 > Zachary Hi Zachary, The MARF working group is chartered to keep its work in parallel with what the Open Mobile Alliance is up to in the area of mobile spam reporting. Are you familiar with their SpamRep proposal? -MSK _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From vesely@tana.it Tue Jul 6 04:01: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 383CF3A686A for ; Tue, 6 Jul 2010 04:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[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 tJaAUw8yCONM for ; Tue, 6 Jul 2010 04:01:42 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 56BC63A684D for ; Tue, 6 Jul 2010 04:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1278414103; bh=xEsdrs/1tA6VZ3jxo+oAzEzvady4ze2WEMC7r9HXCzY=; l=1325; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cP/ru09tBKWVaTTmADnakW0rZEWVeVGDVumTl5lIIZWlCeRTF8qaERgTT7NuHgvYO s7y8ZWZS/9p7D/F6EQvHEes8kwhEAjBw8ANUOm7C4fIu2y+fcgbXywhrsXkANGXiiY HiYeE7DuN5opPhpePB7UWB8VSF9dfRw1l7g2Lcmo= 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, 06 Jul 2010 13:01:43 +0200 id 00000000005DC036.000000004C330D17.000037E7 Message-ID: <4C330D16.5000103@tana.it> Date: Tue, 06 Jul 2010 13:01:42 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: marf@ietf.org References: <20100622040625.97472.qmail@joyce.lan><22377F8C-4BFB-4F4D-AC57-B81A7531D86E@cybernothing.org><6.2.5.6.2.20100622114236.07390908@resistor.net> <8CCE2028D7A01BF-9A8-2DF3@Webmail-m105.sysops.aol.com> <4776BFF0-87B0-499A-A4C6-4DFA2D8C0E01@cybernothing.org> <4C31B987.8070601@tana.it> <39E5378D-CC99-4800-ABA4-EC1CB42AAA3C@cybernothing.org> In-Reply-To: <39E5378D-CC99-4800-ABA4-EC1CB42AAA3C@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] list of current approval criteria 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 Jul 2010 11:01:44 -0000 On 05/Jul/10 14:40, J.D. Falk wrote: > On Jul 5, 2010, at 4:52 AM, Alessandro Vesely wrote: >> it is difficult to deduce the nature of FBLs from their approval criteria. > > Yeah, it's not intended as a descriptive or BCP document. I see. However, say a new organization asks advice about launching their new email infrastructure: Would you include subscribing to selected FBLs among the tasks they should do? > I believe that an advertisement in DNS could provide an equal (or better) level of authentication The DNS, much like subscription requests, contains unverified addresses, while a private list would only contain domains whose email contact has been tested. > After that, I don't see much opportunity for standardization In case we'll conclude that an FBL is a useful tool to have, why shouldn't everybody have a chance to implement it? Such approach might scale up to each mail domain maintaining a list of all other mail domains subscribed to its FBL. > though I'd certainly support a BCP calling for Feedback Generators to make more of their criteria public. +1, and also their consenting subscribers... Are there staffers of AOL, BlueTie, Comcast, Cox, Earthlink, Microsoft, Outblaze, OpenSRS, Rackspace, Road Runner, USA.net, and Yahoo! on this mailing list? From jdfalk-lists@cybernothing.org Tue Jul 6 15:38: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 6219F3A66B4 for ; Tue, 6 Jul 2010 15:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 FThN+G07AlRZ for ; Tue, 6 Jul 2010 15:37:59 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 2A0EA3A67AF for ; Tue, 6 Jul 2010 15:37:59 -0700 (PDT) Received: from jeremys-iphone.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 o66MbxeE028826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 6 Jul 2010 16:38:01 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o66MbxeE028826 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1278455881; bh=zN/yT7vCcmmxmAS66ux9lsj7+G6ROkB2BheaqN4Mo BE=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=ikzPuz+uIymT/5gH y54Zh2r7l5LNRspQv8xYcLvgPkHaE9SM+WnDVQ8s4qYwvVZkZ4xhz6AJRSFD97Z+Hyz ivi60/V1sKQy+ViNHWbtoJqMlFQ/so0eqnrCgyQ5Z4TqZXJkRU4PJYqewOWKqV8eoT2 Uhwxum6T2N8rJrTgau4Nw= References: <20100622040625.97472.qmail@joyce.lan><22377F8C-4BFB-4F4D-AC57-B81A7531D86E@cybernothing.org><6.2.5.6.2.20100622114236.07390908@resistor.net> <8CCE2028D7A01BF-9A8-2DF3@Webmail-m105.sysops.aol.com> <4776BFF0-87B0-499A-A4C6-4DFA2D8C0E01@cybernothing.org> <4C31B987.8070601@tana.it> <39E5378D-CC99-4800-ABA4-EC1CB42AAA3C@cybernothing.org> <4C330D16.5000103@tana.it> In-Reply-To: <4C330D16.5000103@tana.it> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <034993CD-BB47-4BB6-8782-16765220E28F@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 6 Jul 2010 16:37:54 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1081) Subject: Re: [marf] list of current approval criteria 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 Jul 2010 22:38:00 -0000 On Jul 6, 2010, at 5:01 AM, Alessandro Vesely wrote: > On 05/Jul/10 14:40, J.D. Falk wrote: >> On Jul 5, 2010, at 4:52 AM, Alessandro Vesely wrote: >>> it is difficult to deduce the nature of FBLs from their approval = criteria. >>=20 >> Yeah, it's not intended as a descriptive or BCP document. >=20 > I see. However, say a new organization asks advice about launching = their new email infrastructure: Would you include subscribing to = selected FBLs among the tasks they should do? That'd go in a BCP document, wouldn't it? >> I believe that an advertisement in DNS could provide an equal (or = better) level of authentication >=20 > The DNS, much like subscription requests, contains unverified = addresses, while a private list would only contain domains whose email = contact has been tested. >> After that, I don't see much opportunity for standardization >=20 > In case we'll conclude that an FBL is a useful tool to have, why = shouldn't everybody have a chance to implement it? Such approach might = scale up to each mail domain maintaining a list of all other mail = domains subscribed to its FBL. I'm confused. In this thread, I've been talking about subscription = acceptance policies. It sounds like you're talking about something = entirely different, but I'm not sure what it is. >> though I'd certainly support a BCP calling for Feedback Generators to = make more of their criteria public. >=20 > +1, and also their consenting subscribers... >=20 > Are there staffers of AOL, BlueTie, Comcast, Cox, Earthlink, = Microsoft, Outblaze, OpenSRS, Rackspace, Road Runner, USA.net, and = Yahoo! on this mailing list? They've all been encouraged to participate. Some are here. Some rely = on their 3rd party Feedback Generator (my employer) to tell them about = any new developments. -- J.D. Falk Return Path Inc From yakov@shaftek.org Tue Jul 6 17:09: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 8FF5F3A6A40 for ; Tue, 6 Jul 2010 17:09:32 -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 411LX3zNtkuO for ; Tue, 6 Jul 2010 17:09:31 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 2BAED3A6A3A for ; Tue, 6 Jul 2010 17:09:30 -0700 (PDT) Received: by eyb7 with SMTP id 7so209469eyb.31 for ; Tue, 06 Jul 2010 17:09:29 -0700 (PDT) Received: by 10.213.20.66 with SMTP id e2mr4910625ebb.83.1278461369152; Tue, 06 Jul 2010 17:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.22.77 with HTTP; Tue, 6 Jul 2010 17:09:09 -0700 (PDT) In-Reply-To: References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: Yakov Shafranovich Date: Tue, 6 Jul 2010 20:09:09 -0400 Message-ID: To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Wed, 07 Jul 2010 00:09:32 -0000 Well, Barry Leiba is the IETF liason to MAAWG while Murray is the IETF liason to OMA. I think between the two of them, we can probably figure out a way to coordinate things. Is this draft something that is coming out of OMA officially, or a work of individuals? Yakov On Tue, Jul 6, 2010 at 3:15 AM, Alex Bobotek wrote: > I think it would make a lot of sense for OMA SpamRep and IETF MARF to > either converge on SMS/MMS, or clearly identify reasons why they should > be kept separate. > > There seems to be difference in scope. =A0SpamRep is intended to support > SMS/MMS feedback from both device-based applications such as user agents > (e.g., 'this is spam' buttons in phones), and network nodes such as > SMSCs inside carrier networks. =A0This is significantly different from th= e > scope defined (or at least alluded to) in the introduction to > draft-cai-smsc-mmsc-reporting-marf-00: receiving reports from SMSCs and > MMSCs. =A0One of the challenges I faced in drafting the SMS portion of th= e > OMA spec is accommodating the SMS gateway functions (e.g., OTA-->GSM > MAP, GSM MAP-->SMPP) that transform a message as it passes through a > network and is finally stored in a device in an implementation-dependent > format; it is challenging to provide a uniform abuse report format which > is useful at all points in the message flow. =A0However, IMHO an > abuse-reporting format can be made flexible enough to accommodate all of > these cases by incorporating a sufficient number of optional parameters. > > > The SpamRep v1.0 specification is now largely complete, with consistency > review coming in the near future. =A0So comments are welcome. =A0While on= ly > OMA member companies may submit change requests, many member companies > are receptive to input from individuals and non-members. > > Draft OMA SpamRep specs are available at: > http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe > p/Permanent_documents/, including the latest 6/24/2010 draft. > Change requests (the vehicle by which the draft spec is modified) are > at: > http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe > p/2010/ > > Regards, > > Alex > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Monday, July 05, 2010 11:26 PM > To: Zeltsan, Zachary (Zachary); 'marf@ietf.org' > Subject: Re: [marf] FW: New Version Notification for > draft-cai-smsc-mmsc-reporting-marf-00 > >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf > Of >> Zeltsan, Zachary (Zachary) >> Sent: Monday, July 05, 2010 6:32 AM >> To: 'marf@ietf.org' >> Subject: [marf] FW: New Version Notification for draft-cai-smsc-mmsc- >> reporting-marf-00 >> >> Please review this new draft >> http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt >> >> Zachary > > Hi Zachary, > > The MARF working group is chartered to keep its work in parallel with > what the Open Mobile Alliance is up to in the area of mobile spam > reporting. =A0Are you familiar with their SpamRep proposal? > > -MSK > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From yigang.cai@alcatel-lucent.com Wed Jul 7 08:01:45 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 C82873A67AE for ; Wed, 7 Jul 2010 08:01:44 -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 gTryYc6Vvm2H for ; Wed, 7 Jul 2010 08:01:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 1EF473A67B6 for ; Wed, 7 Jul 2010 08:01:43 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o67F1jQQ022642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 10:01:45 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o67F1hrt029007; Wed, 7 Jul 2010 10:01:45 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 7 Jul 2010 10:01:42 -0500 From: "Cai, Yigang (Yigang)" To: SM , "Zeltsan, Zachary (Zachary)" Date: Wed, 7 Jul 2010 10:01:40 -0500 Thread-Topic: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 Thread-Index: AcsczsqS4E4iHxcfTFOlsEax7/4KhABFXyqg Message-ID: <5710F82C0E73B04FA559560098BF95B124F9A5C09D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6.2.5.6.2.20100705223859.06275830@resistor.net> In-Reply-To: <6.2.5.6.2.20100705223859.06275830@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "marf@ietf.org" Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Wed, 07 Jul 2010 15:01:45 -0000 All, See my response inline. Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of SM Sent: Tuesday, July 06, 2010 12:47 AM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-re= porting-marf-00 Hi Zachary, At 06:31 05-07-10, Zeltsan, Zachary (Zachary) wrote: >Please review this new draft >http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt In the Introduction Section: "This document introduces a SMS/MMS message abuse report and defines the content and report format; therefore, extends [draft-ietf-marf-base] to add features required for SMSC/MMSC reporting." What format is used for SMS/MMS messages? [Yigang] We prefer to re-use the email message abuse format here. So, the b= ase format can be extended to email server, SMSC, MMSC, etc. But we are ope= n to have separate format for SMS/MMS message abuse. In Section 3: "The following is a non-exhaustive list of the specific parameters that SHOULD be included as optional fields in the base reporting MIME feedback reports, but are RECOMMENDED for SMS/MMS message reporting:" Is the list of parameters correct? How should they be included as optional= fields? [Yigang] Yes, these are SMS/MMS message abuse related parameters, they shou= ld be only included as optional fields in the base reporting. The authors in the Normative References Section for draft-ietf-marf-base is= incorrect. [Yigang] Zachary will fix it. Regards, -sm=20 _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From zachary.zeltsan@alcatel-lucent.com Wed Jul 7 08:14: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 2968B3A6812 for ; Wed, 7 Jul 2010 08:14:49 -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 sXgG7TKDIIV5 for ; Wed, 7 Jul 2010 08:14:45 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 98B383A67FC for ; Wed, 7 Jul 2010 08:14:43 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o67FEkpl008899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 10:14:46 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o67FEevD023651; Wed, 7 Jul 2010 10:14:46 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 7 Jul 2010 10:14:45 -0500 From: "Zeltsan, Zachary (Zachary)" To: "Cai, Yigang (Yigang)" , SM Date: Wed, 7 Jul 2010 10:14:44 -0500 Thread-Topic: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 Thread-Index: AcsczsqS4E4iHxcfTFOlsEax7/4KhABFXyqgAABLbcA= Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DA1@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6.2.5.6.2.20100705223859.06275830@resistor.net> <5710F82C0E73B04FA559560098BF95B124F9A5C09D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9A5C09D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "marf@ietf.org" Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Wed, 07 Jul 2010 15:14:49 -0000 > The authors in the Normative References Section for draft-ietf-marf-base = is incorrect. Adding to what Yigang has said, I apologize for this (cut-and-paste) error.= I will submit the corrected version as soon as submission of the drafts is= allowed again after the IETF 78. Zachary -----Original Message----- From: Cai, Yigang (Yigang)=20 Sent: Wednesday, July 07, 2010 11:02 AM To: SM; Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: RE: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-re= porting-marf-00 All, See my response inline. Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of SM Sent: Tuesday, July 06, 2010 12:47 AM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-re= porting-marf-00 Hi Zachary, At 06:31 05-07-10, Zeltsan, Zachary (Zachary) wrote: >Please review this new draft >http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt In the Introduction Section: "This document introduces a SMS/MMS message abuse report and defines the content and report format; therefore, extends [draft-ietf-marf-base] to add features required for SMSC/MMSC reporting." What format is used for SMS/MMS messages? [Yigang] We prefer to re-use the email message abuse format here. So, the b= ase format can be extended to email server, SMSC, MMSC, etc. But we are ope= n to have separate format for SMS/MMS message abuse. In Section 3: "The following is a non-exhaustive list of the specific parameters that SHOULD be included as optional fields in the base reporting MIME feedback reports, but are RECOMMENDED for SMS/MMS message reporting:" Is the list of parameters correct? How should they be included as optional= fields? [Yigang] Yes, these are SMS/MMS message abuse related parameters, they shou= ld be only included as optional fields in the base reporting. The authors in the Normative References Section for draft-ietf-marf-base is= incorrect. [Yigang] Zachary will fix it. Regards, -sm=20 _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From zachary.zeltsan@alcatel-lucent.com Thu Jul 8 13:28:46 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 0AE233A688D for ; Thu, 8 Jul 2010 13:28:46 -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=[AWL=-0.001, 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 USnIK3XWijlu for ; Thu, 8 Jul 2010 13:28:44 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id E808B3A6836 for ; Thu, 8 Jul 2010 13:28:43 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o68KSjps028210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2010 15:28:46 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o68KSjt9023352; Thu, 8 Jul 2010 15:28:45 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 8 Jul 2010 15:28:29 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'barryleiba@computer.org'" , "'msk@cloudmark.com'" Date: Thu, 8 Jul 2010 15:28:29 -0500 Thread-Topic: Time slot at IETF 78 Thread-Index: Acse3CA3u3aM6SGmQASzPuZgxjU0Gw== Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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_5710F82C0E73B04FA559560098BF95B124F9688DA9USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "marf@ietf.org" Subject: [marf] Time slot at IETF 78 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, 08 Jul 2010 20:28:46 -0000 --_000_5710F82C0E73B04FA559560098BF95B124F9688DA9USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barry, Murray, Could you please give us a time slot (10 minutes) at the IETF 78 for presen= ting the recently-published draft An Extensible Format for SMSC/MMSC Feedba= ck Reports? (The draft is at http://datatracker.ietf.org/doc/draft-cai-smsc= -mmsc-reporting-marf/ ). With thanks, Zachary Zeltsan --_000_5710F82C0E73B04FA559560098BF95B124F9688DA9USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Barry,
Murray,
 
Could you please give us a time slot (10 minutes) at the IETF 78 for p= resenting the recently-published draft An Extensible Format for SMSC/MMS= C Feedback Reports? (The draft is at ht= tp://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ).
 
With thanks,
 
Zachary Zeltsan
  --_000_5710F82C0E73B04FA559560098BF95B124F9688DA9USNAVSXCHMBSA_-- From yakov@shaftek.org Thu Jul 8 20:44: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 5D0053A6B74 for ; Thu, 8 Jul 2010 20:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, 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 ecYSMCDnSJJQ for ; Thu, 8 Jul 2010 20:44:01 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A223B3A6B6B for ; Thu, 8 Jul 2010 20:44:00 -0700 (PDT) Received: by ewy22 with SMTP id 22so414294ewy.31 for ; Thu, 08 Jul 2010 20:44:00 -0700 (PDT) Received: by 10.213.32.136 with SMTP id c8mr7890118ebd.16.1278647040240; Thu, 08 Jul 2010 20:44:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.22.77 with HTTP; Thu, 8 Jul 2010 20:43:40 -0700 (PDT) In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: Yakov Shafranovich Date: Thu, 8 Jul 2010 23:43:40 -0400 Message-ID: To: "Zeltsan, Zachary (Zachary)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "marf@ietf.org" Subject: Re: [marf] Time slot at IETF 78 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 Jul 2010 03:44:02 -0000 Zachary, Before commenting on the technical aspects, can you tell us the background for this? Is this part of the OMA or MAAWG efforts, or is this something that you are submitting privately to the IETF? What is Alcatel's role here? Thanks, Yakov On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) wrote: > Barry, > Murray, > > Could you please give us a time slot (10 minutes) at the IETF 78 for > presenting the recently-published draft An Extensible Format for SMSC/MMSC > Feedback Reports? (The draft is at > http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > > With thanks, > > Zachary Zeltsan > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > From sm@resistor.net Thu Jul 8 23:39: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 77E843A6B9B for ; Thu, 8 Jul 2010 23:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 Pqnw3u7qBZW1 for ; Thu, 8 Jul 2010 23:39:00 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 3EEFA3A6B96 for ; Thu, 8 Jul 2010 23:39:00 -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 o696cT6u010142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2010 23:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1278657540; x=1278743940; bh=adpTGSmRKWN3qXfAaw7vZK5qVz07BFUcAYPYTXXJC6I=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=EtMCr2CblVNxUUuZ0wi/NxrvRQOFtfga/l9/i7VFszA7qlhWDY9i6OckhFXHnV11v L6pdVGeTTMpAUxdOxv32n9jW3uwFzv14qNrz/MszD+QH0atHFiExQ+1VVKO/B0CDL1 iknwNKHnItHXq1sa3LfDZAShLguqlv3FCvV6CzQI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1278657540; x=1278743940; bh=adpTGSmRKWN3qXfAaw7vZK5qVz07BFUcAYPYTXXJC6I=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=KRYrZ/VBr7af9mg2/971ShMqpgINeQllUNHuXevqqeeOF6UN03gJWftgZYN4XJEHf mMJQomBsfrjWFs14AqDuIm4SlURw7yVl80trA/jv/tw5iaFfDNHUBuFjTC7LVE1ZpB i54a1NTSdrXmsionuBq1RNlXdeTwVnvs7zE2gLMc= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=VTuY0MLwnU+D7WdQ+oVBLY9Jv7Ma0FGOcuZGdL4FkbSepmOwfZVpYTSXJ5fyRH3dt nN624dw5PAod9v70ZUejftbazokZoJYVBLB8cKQVZzU5fVQuBYX7zGBTmXq4YrjXaOl +oNtnPaTH6Fxy1TirwagijwR+DJDPRxqOtiF0zM= Message-Id: <6.2.5.6.2.20100708233116.05c8ab80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Jul 2010 23:37:29 -0700 To: "Cai, Yigang (Yigang)" , "Zeltsan, Zachary (Zachary)" From: SM In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9A5C09D@USNAVSXCHMBSA3. ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6.2.5.6.2.20100705223859.06275830@resistor.net> <5710F82C0E73B04FA559560098BF95B124F9A5C09D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Fri, 09 Jul 2010 06:39:01 -0000 Hi Yigang, At 08:01 07-07-10, Cai, Yigang (Yigang) wrote: >[Yigang] Yes, these are SMS/MMS message abuse related parameters, >they should be only included as optional fields in the base reporting. The reporting required fields in Section 3 are incorrect. Email uses "Message-ID" and not "Message ID". Please refer to the Permanent Message Header Field Names ( http://www.iana.org/assignments/message-headers/perm-headers.html ) for more information. Regards, -sm From yigang.cai@alcatel-lucent.com Fri Jul 9 06:27: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 B0A8B3A6A79 for ; Fri, 9 Jul 2010 06:27:08 -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 s941ClrgtZwE for ; Fri, 9 Jul 2010 06:27:07 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A42413A69BF for ; Fri, 9 Jul 2010 06:27:07 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o69DRC9M014128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2010 08:27:12 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o69DRBDS028284; Fri, 9 Jul 2010 08:27:12 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 9 Jul 2010 08:27:11 -0500 From: "Cai, Yigang (Yigang)" To: SM , "Zeltsan, Zachary (Zachary)" Date: Fri, 9 Jul 2010 08:27:10 -0500 Thread-Topic: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 Thread-Index: AcsfMW1s2fat0ClTTESTx4lxXhODPQAOPPdA Message-ID: <5710F82C0E73B04FA559560098BF95B124F9ABC69D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6.2.5.6.2.20100705223859.06275830@resistor.net> <5710F82C0E73B04FA559560098BF95B124F9A5C09D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6.2.5.6.2.20100708233116.05c8ab80@resistor.net> In-Reply-To: <6.2.5.6.2.20100708233116.05c8ab80@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "marf@ietf.org" Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Fri, 09 Jul 2010 13:27:08 -0000 Okay, we will fix it.=20 -----Original Message----- From: SM [mailto:sm@resistor.net]=20 Sent: Friday, July 09, 2010 1:37 AM To: Cai, Yigang (Yigang); Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: RE: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-re= porting-marf-00 Hi Yigang, At 08:01 07-07-10, Cai, Yigang (Yigang) wrote: >[Yigang] Yes, these are SMS/MMS message abuse related parameters, they=20 >should be only included as optional fields in the base reporting. The reporting required fields in Section 3 are incorrect. Email uses "Mess= age-ID" and not "Message ID". Please refer to the Permanent Message Header= Field Names ( http://www.iana.org/assignments/message-headers/perm-headers= .html ) for more information. Regards, -sm=20 From zachary.zeltsan@alcatel-lucent.com Fri Jul 9 08:16: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 071B83A6ABC for ; Fri, 9 Jul 2010 08:16:01 -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=[AWL=0.000, 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 Gj6tBq03d0Nv for ; Fri, 9 Jul 2010 08:15:59 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 4725F3A6ACB for ; Fri, 9 Jul 2010 08:15:53 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o69FFqr1016132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jul 2010 10:15:53 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o69FFoYF004279 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Jul 2010 10:15:52 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 9 Jul 2010 10:15:40 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Yakov Shafranovich'" Date: Fri, 9 Jul 2010 10:15:39 -0500 Thread-Topic: [marf] Time slot at IETF 78 Thread-Index: AcsfGe/+dLoh6LYkSP21ruOHa+ar/wAW1z5Q Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "Torabi, Mohammad \(Moh\)" , "marf@ietf.org" Subject: Re: [marf] Time slot at IETF 78 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 Jul 2010 15:16:01 -0000 Yakov, Moh, who is one of the draft's co-authors, has been involved in the OMA wor= k and is in a better position to answer questions related to the OMA effort= . (I have copied this message to Moh). Zachary -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org]=20 Sent: Thursday, July 08, 2010 11:44 PM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Zachary, Before commenting on the technical aspects, can you tell us the background for this? Is this part of the OMA or MAAWG efforts, or is this something that you are submitting privately to the IETF? What is Alcatel's role here? Thanks, Yakov On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) wrote: > Barry, > Murray, > > Could you please give us a time slot (10 minutes) at the IETF 78 for > presenting the recently-published draft An Extensible Format for SMSC/MMS= C > Feedback Reports? (The draft is at > http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > > With thanks, > > Zachary Zeltsan > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > From moh.torabi@alcatel-lucent.com Fri Jul 9 08:25: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 00A903A697D for ; Fri, 9 Jul 2010 08:25:59 -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 lOxDM-wKVruR for ; Fri, 9 Jul 2010 08:25:50 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 12F2B3A6AAA for ; Fri, 9 Jul 2010 08:25:50 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o69FPpNG026903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2010 10:25:52 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o69FPoeA011193; Fri, 9 Jul 2010 10:25:51 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 9 Jul 2010 10:25:42 -0500 From: "Torabi, Mohammad (Moh)" To: "Zeltsan, Zachary (Zachary)" , "'Yakov Shafranovich'" Date: Fri, 9 Jul 2010 10:25:40 -0500 Thread-Topic: [marf] Time slot at IETF 78 Thread-Index: AcsfGe/+dLoh6LYkSP21ruOHa+ar/wAW1z5QAAEgvRA= Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 X-Mailman-Approved-At: Fri, 09 Jul 2010 08:28:08 -0700 Cc: "marf@ietf.org" Subject: Re: [marf] Time slot at IETF 78 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 Jul 2010 15:25:59 -0000 Hi Yakov, This work is trying to address a gap that is seen in the ongoing work of IE= TF's MARF and OMA's SpamRep WA. The draft is submitted by individuals as is= the usual procedure to follow in IETF. However, all authors/contributors a= re Alcatel-Lucent employees. Regards, Moh=20 -----Original Message----- From: Zeltsan, Zachary (Zachary)=20 Sent: Friday, July 09, 2010 8:16 AM To: 'Yakov Shafranovich' Cc: marf@ietf.org; Torabi, Mohammad (Moh) Subject: RE: [marf] Time slot at IETF 78 Yakov, Moh, who is one of the draft's co-authors, has been involved in the OMA wor= k and is in a better position to answer questions related to the OMA effort= . (I have copied this message to Moh). Zachary -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org]=20 Sent: Thursday, July 08, 2010 11:44 PM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Zachary, Before commenting on the technical aspects, can you tell us the background for this? Is this part of the OMA or MAAWG efforts, or is this something that you are submitting privately to the IETF? What is Alcatel's role here? Thanks, Yakov On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) wrote: > Barry, > Murray, > > Could you please give us a time slot (10 minutes) at the IETF 78 for > presenting the recently-published draft An Extensible Format for SMSC/MMS= C > Feedback Reports? (The draft is at > http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > > With thanks, > > Zachary Zeltsan > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > From zachary.zeltsan@alcatel-lucent.com Fri Jul 9 09:19: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 8BCBB3A69B1 for ; Fri, 9 Jul 2010 09:19:44 -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=[AWL=0.000, 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 tyDFxXVJVvmp for ; Fri, 9 Jul 2010 09:19:43 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 9A54A3A6877 for ; Fri, 9 Jul 2010 09:19:43 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o69GJlXv024514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2010 11:19:47 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o69GJlIP028241; Fri, 9 Jul 2010 11:19:47 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 9 Jul 2010 11:19:26 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Yakov Shafranovich'" Date: Fri, 9 Jul 2010 11:19:25 -0500 Thread-Topic: [marf] Time slot at IETF 78 Thread-Index: AcsfGe/+dLoh6LYkSP21ruOHa+ar/wAW1z5QAAEgvRAAAhZiUA== Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688DAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "Torabi, Mohammad \(Moh\)" , "marf@ietf.org" Subject: Re: [marf] Time slot at IETF 78 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 Jul 2010 16:19:44 -0000 Sent on Moh's behalf... -----Original Message----- From: Torabi, Mohammad (Moh)=20 Sent: Friday, July 09, 2010 11:26 AM To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich' Cc: marf@ietf.org Subject: RE: [marf] Time slot at IETF 78 Hi Yakov, This work is trying to address a gap that is seen in the ongoing work of IE= TF's MARF and OMA's SpamRep WA. The draft is submitted by individuals as is= the usual procedure to follow in IETF. However, all authors/contributors a= re Alcatel-Lucent employees. Regards, Moh=20 -----Original Message----- From: Zeltsan, Zachary (Zachary)=20 Sent: Friday, July 09, 2010 8:16 AM To: 'Yakov Shafranovich' Cc: marf@ietf.org; Torabi, Mohammad (Moh) Subject: RE: [marf] Time slot at IETF 78 Yakov, Moh, who is one of the draft's co-authors, has been involved in the OMA wor= k and is in a better position to answer questions related to the OMA effort= . (I have copied this message to Moh). Zachary -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org]=20 Sent: Thursday, July 08, 2010 11:44 PM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Zachary, Before commenting on the technical aspects, can you tell us the background for this? Is this part of the OMA or MAAWG efforts, or is this something that you are submitting privately to the IETF? What is Alcatel's role here? Thanks, Yakov On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) wrote: > Barry, > Murray, > > Could you please give us a time slot (10 minutes) at the IETF 78 for > presenting the recently-published draft An Extensible Format for SMSC/MMS= C > Feedback Reports? (The draft is at > http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > > With thanks, > > Zachary Zeltsan > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > From msk@cloudmark.com Fri Jul 9 11:24: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 8CC5D3A6800 for ; Fri, 9 Jul 2010 11:24:51 -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.301, 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 ySeJeQrmnQdy for ; Fri, 9 Jul 2010 11:24:49 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id A40233A6861 for ; Fri, 9 Jul 2010 11:24:49 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Fri, 9 Jul 2010 11:24:54 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 9 Jul 2010 11:24:54 -0700 Thread-Topic: IETF 78 agenda items Thread-Index: AcsflAbV8RHYsuBHT1qq+wvbET89nA== 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_BB012BD379D7B046ABE1472D8093C61C01F5D16CE4EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] IETF 78 agenda items 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 Jul 2010 18:24:51 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01F5D16CE4EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We have a 1 hr, 40 minute session on Tuesday at the upcoming IETF meeting i= n Maastricht. I have the following as a rough agenda for our session. Any= one see anything that should be added or changed? 0:00-0:05 Agenda bashing (all) 0:05-0:10 Document status (chairs) 0:10-0:25 draft-ietf-marf-dkim-reporting (Murray) 0:25-0:40 draft-jdfalk-marf-reporting-discovery (JD) 0:40-0:55 draft-jdfalk-marf-acceptance-criteria (JD) 0:55-1:10 Overview of OMA SpamRep Enabler (Murray) 1:10-1:25 draft-cai-smsc-mmsc-reporting-marf (?) 1:25-1:40 any other business The documents that are not "draft-ietf-marf-*" are candidates for being bro= ught in as working group items provided they correspond to our charter. Of= course if we feel strongly that other work is appropriate and within our g= eneral scope, we can talk to our AD about extending our charter to cover th= at work. Feedback welcome. -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01F5D16CE4EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We have a 1 hr, 40 minute session on Tuesday at the up= coming IETF meeting in Maastricht.  I have the following as a rough agenda fo= r our session.  Anyone see anything that should be added or changed?

 

0:00-0:05       &nb= sp;      Agenda bashing (all)

0:05-0:10       &nb= sp;      Document status (chairs)

0:10-0:25       &nb= sp;      draft-ietf-marf-dkim-reporting (Murray)

0:25-0:40       &nb= sp;      draft-jdfalk-marf-reporting-discovery (JD)

0:40-0:55       &nb= sp;      draft-jdfalk-marf-acceptance-criteria (JD)

0:55-1:10       &nb= sp;      Overview of OMA SpamRep Enabler (Murray)

1:10-1:25       &nb= sp;      draft-cai-smsc-mmsc-reporting-marf (?)

1:25-1:40       &nb= sp;      any other business

 

The documents that are not “draft-ietf-marf-*= 221; are candidates for being brought in as working group items provided they correspond to our charter.  Of course if we feel strongly that other w= ork is appropriate and within our general scope, we can talk to our AD about extending our charter to cover that work.

 

Feedback welcome.

 

-MSK

 

--_000_BB012BD379D7B046ABE1472D8093C61C01F5D16CE4EXCHC2corpclo_-- From jdfalk-lists@cybernothing.org Fri Jul 9 12:36: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 D63923A684A for ; Fri, 9 Jul 2010 12:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[AWL=-0.697, 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 yD7rToEK5Bg0 for ; Fri, 9 Jul 2010 12:36:29 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 9E4DB3A67EA for ; Fri, 9 Jul 2010 12:36:29 -0700 (PDT) Received: from [192.168.0.5] (174-29-210-5.hlrn.qwest.net [174.29.210.5]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o69JaRVu028846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 9 Jul 2010 13:36:33 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o69JaRVu028846 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1278704194; bh=pd+pvld+ts0eKzxRsM0iCOVu0YWiUrPGgORqSvZKo 9w=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=k8/8e21vgIFBSgii RIBmuJfi4jKzWJxIpSJk8TnKVeaOFBRHwviBK3Bn9LoyL2xA7ikm96p4IjD+LY8h8sM osziWC2eMZE/fEwgc/WOeJ0GygFGZIUP71FOGli5X2idGe1nlZggzct38lG4+IdG1IJ gLKiPJ/AYrqiiU5m2dAlg= References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Fri, 9 Jul 2010 13:36:21 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1081) Subject: Re: [marf] IETF 78 agenda items 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 Jul 2010 19:36:30 -0000 On Jul 9, 2010, at 12:24 PM, Murray S. Kucherawy wrote: > 1:25-1:40 any other business MAAWG's complaint feedback loop BCP should be published before we meet = in Maastricht, so we could schedule a discussion of whether to import it = as the BCP in the charter, or start new work that refers to it, or = ignore it entirely, or whatever's appropriate. -- J.D. Falk Return Path Inc From alex@bobotek.net Sat Jul 10 19:50: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 32DAD3A659A for ; Sat, 10 Jul 2010 19:50:14 -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 c3wWEjHvGDwc for ; Sat, 10 Jul 2010 19:50:13 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 1C9193A68D9 for ; Sat, 10 Jul 2010 19:50:12 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta02.emeryville.ca.mail.comcast.net with comcast id gSiR1e0011bwxycA2SqKlr; Sun, 11 Jul 2010 02:50:19 +0000 Received: from bobo1.bobotek.net ([71.227.197.27]) by omta18.emeryville.ca.mail.comcast.net with comcast id gSqJ1e0030bxBZT8eSqJT5; Sun, 11 Jul 2010 02:50:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 10 Jul 2010 19:49:24 -0700 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9688DAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [marf] Time slot at IETF 78 Thread-Index: AcsfGe/+dLoh6LYkSP21ruOHa+ar/wAW1z5QAAEgvRAAAhZiUABITI5g References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "Alex Bobotek" To: "Zeltsan, Zachary (Zachary)" , "Yakov Shafranovich" , "Torabi, Mohammad (Moh)" Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 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: Sun, 11 Jul 2010 02:50:14 -0000 Could someone help explain what gap in OMA SpamRep is addressed by this? Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Zeltsan, Zachary (Zachary) Sent: Friday, July 09, 2010 9:19 AM To: 'Yakov Shafranovich' Cc: Torabi, Mohammad (Moh); marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Sent on Moh's behalf... -----Original Message----- From: Torabi, Mohammad (Moh)=20 Sent: Friday, July 09, 2010 11:26 AM To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich' Cc: marf@ietf.org Subject: RE: [marf] Time slot at IETF 78 Hi Yakov, This work is trying to address a gap that is seen in the ongoing work of IETF's MARF and OMA's SpamRep WA. The draft is submitted by individuals as is the usual procedure to follow in IETF. However, all authors/contributors are Alcatel-Lucent employees. Regards, Moh=20 -----Original Message----- From: Zeltsan, Zachary (Zachary)=20 Sent: Friday, July 09, 2010 8:16 AM To: 'Yakov Shafranovich' Cc: marf@ietf.org; Torabi, Mohammad (Moh) Subject: RE: [marf] Time slot at IETF 78 Yakov, Moh, who is one of the draft's co-authors, has been involved in the OMA work and is in a better position to answer questions related to the OMA effort. (I have copied this message to Moh). Zachary -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org]=20 Sent: Thursday, July 08, 2010 11:44 PM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Zachary, Before commenting on the technical aspects, can you tell us the background for this? Is this part of the OMA or MAAWG efforts, or is this something that you are submitting privately to the IETF? What is Alcatel's role here? Thanks, Yakov On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) wrote: > Barry, > Murray, > > Could you please give us a time slot (10 minutes) at the IETF 78 for > presenting the recently-published draft An Extensible Format for SMSC/MMSC > Feedback Reports? (The draft is at > http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > > With thanks, > > Zachary Zeltsan > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yakov@shaftek.org Sun Jul 11 08:53:29 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 35EC83A69B7 for ; Sun, 11 Jul 2010 08:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 OdDiGcTOPxvi for ; Sun, 11 Jul 2010 08:53:28 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 196833A69B4 for ; Sun, 11 Jul 2010 08:53:27 -0700 (PDT) Received: by ewy22 with SMTP id 22so820376ewy.31 for ; Sun, 11 Jul 2010 08:53:30 -0700 (PDT) Received: by 10.213.32.140 with SMTP id c12mr525997ebd.95.1278863610431; Sun, 11 Jul 2010 08:53:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.127.66 with HTTP; Sun, 11 Jul 2010 08:53:10 -0700 (PDT) From: Yakov Shafranovich Date: Sun, 11 Jul 2010 11:53:10 -0400 Message-ID: To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Sun, 11 Jul 2010 15:53:29 -0000 This is in regards to the following draft: http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt As per emails to the list and the SpamRep documentation at the OMA, this draft is trying to address the gap between MARF and the OMA SpamRep requirements. One key point to note is that the MARF model is focused on feedback loops between the ISP and the original email sender, while the OMA SpamRep activity is focused on the end user and their network provider. The analogous use case in the email space is a "report spam" button for end users which creates a report for their ISP. 1. Section 1.2 "requirements" - this seems to repeat the main MARF draft requirements and seems to be different from the OMA requirements. There is no need to repeat the MARF requirements verbatim, it may be sufficient to reference them. The OMA requirements should be referenced, and some of the OMA SpamRep requirements which cannot be solved with MARF should be addressed explicitly here. Ideally this section should clearly state that this draft seeks to address OMA requirements X and Y, but not Z. 2. There needs to be a reference in the draft to the standard that defines SMS/MMS message formats. This is needed in order for us to see how it differs from email. Additionally, you need to specify whether these SMS/MMS spam report will be delivered via email. If not, this may not fall within MARF or IETF scope of work. 3. As per the MARF draft, there is a specific format to be followed when defining fields for the registry. You need to specify which abuse type it references, whether it is included once or multiple times, and whether it is historical. That format should be followed. Additionally, ABNF would not hurt. 4. The draft keeps referencing abuse detected by the message center. However, the OMA SpamRep requirements talk about the end user reporting spam. 5. One of the basic principles underpinning MARF is that the data included in section 2 of the report, should be data that cannot be otherwise derived from the original message. Many of the fields that I see listed seem to be ones that will be included in the original message itself. There is no need to repeat them again in section 2 of the report. Some field specific comments: 6. "Message ID" - in the email world, this is automatically generated in the headers of the MARF report itself. 7. "Message Center ID" - in the email world the sender of the MARF report would be in the headers. 8. "Message Type" - MARF is specific for email, IM reporting has its own formatting. You will need to create a registry or tightly define this. Also, is this information that would be included in the original message? 9. Fields 4.4 - 4.15 - are these included in the original message? Is there a need to repeat them in part 2? 10. Abuse types - is there a need for all of these? Prior discussion here seems to indicate that most of these are not necessary and some overlap. For example, message flooding and DOS are the same. 11. Abuse detection methods - this is similar to the authentication results header we currently discussed regarding DKIM. There needs to be a document covering this. 12. Sections 4.18-4.23 - is any of this data included in the original message? Also, are any of these currently used? 13. Regarding feedback types - I would recommend looking at the possibility of defining a new feedback type called "sms" or "mobile" and re-using as much as possible of existing MARF. For example, abuse keywords, etc. could be specified using URIs. Yakov From zengw@huawei.com Sun Jul 11 10:40: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 63E763A6826 for ; Sun, 11 Jul 2010 10:40:38 -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 Y9rEcpQInxAx for ; Sun, 11 Jul 2010 10:40:37 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 22D1A3A67F5 for ; Sun, 11 Jul 2010 10:40:37 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5E00ANEMFVMX@usaga01-in.huawei.com> for marf@ietf.org; Sun, 11 Jul 2010 10:40:43 -0700 (PDT) Received: from zengPC (umc-196172.dhcp.missouri.edu [161.130.196.172]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0L5E00453MFQBW@usaga01-in.huawei.com> for marf@ietf.org; Sun, 11 Jul 2010 10:40:43 -0700 (PDT) Date: Sun, 11 Jul 2010 12:40:32 -0500 From: "Wenjun (Kevin) Zeng" In-reply-to: To: 'Yakov Shafranovich' , marf@ietf.org Message-id: <001f01cb2120$2d2fab80$878f0280$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcshET9HRHPEbGZORiK4Fzt7R24z1gACxiKw References: Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: zengw@huawei.com List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 17:40:38 -0000 Hi Yakov and all, A couple of clarifications. 1. Although OMA SpamRep was originally motivated by feedback loop between the end user and their network provider, the actual specification only specifies two logical entities, i.e., a SpamRep server and a SpamRep client where the client could be UA, MTA, SMSC etc. 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF restricted to email delivery of report only? Thanks. -Kevin -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Yakov Shafranovich Sent: Sunday, July 11, 2010 10:53 AM To: marf@ietf.org Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" This is in regards to the following draft: http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt As per emails to the list and the SpamRep documentation at the OMA, this draft is trying to address the gap between MARF and the OMA SpamRep requirements. One key point to note is that the MARF model is focused on feedback loops between the ISP and the original email sender, while the OMA SpamRep activity is focused on the end user and their network provider. The analogous use case in the email space is a "report spam" button for end users which creates a report for their ISP. 1. Section 1.2 "requirements" - this seems to repeat the main MARF draft requirements and seems to be different from the OMA requirements. There is no need to repeat the MARF requirements verbatim, it may be sufficient to reference them. The OMA requirements should be referenced, and some of the OMA SpamRep requirements which cannot be solved with MARF should be addressed explicitly here. Ideally this section should clearly state that this draft seeks to address OMA requirements X and Y, but not Z. 2. There needs to be a reference in the draft to the standard that defines SMS/MMS message formats. This is needed in order for us to see how it differs from email. Additionally, you need to specify whether these SMS/MMS spam report will be delivered via email. If not, this may not fall within MARF or IETF scope of work. 3. As per the MARF draft, there is a specific format to be followed when defining fields for the registry. You need to specify which abuse type it references, whether it is included once or multiple times, and whether it is historical. That format should be followed. Additionally, ABNF would not hurt. 4. The draft keeps referencing abuse detected by the message center. However, the OMA SpamRep requirements talk about the end user reporting spam. 5. One of the basic principles underpinning MARF is that the data included in section 2 of the report, should be data that cannot be otherwise derived from the original message. Many of the fields that I see listed seem to be ones that will be included in the original message itself. There is no need to repeat them again in section 2 of the report. Some field specific comments: 6. "Message ID" - in the email world, this is automatically generated in the headers of the MARF report itself. 7. "Message Center ID" - in the email world the sender of the MARF report would be in the headers. 8. "Message Type" - MARF is specific for email, IM reporting has its own formatting. You will need to create a registry or tightly define this. Also, is this information that would be included in the original message? 9. Fields 4.4 - 4.15 - are these included in the original message? Is there a need to repeat them in part 2? 10. Abuse types - is there a need for all of these? Prior discussion here seems to indicate that most of these are not necessary and some overlap. For example, message flooding and DOS are the same. 11. Abuse detection methods - this is similar to the authentication results header we currently discussed regarding DKIM. There needs to be a document covering this. 12. Sections 4.18-4.23 - is any of this data included in the original message? Also, are any of these currently used? 13. Regarding feedback types - I would recommend looking at the possibility of defining a new feedback type called "sms" or "mobile" and re-using as much as possible of existing MARF. For example, abuse keywords, etc. could be specified using URIs. Yakov _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yakov@shaftek.org Sun Jul 11 12:16: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 876B53A69FE for ; Sun, 11 Jul 2010 12:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=0.681, 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 msO49j7oOojH for ; Sun, 11 Jul 2010 12:16:43 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id BF4FF3A6888 for ; Sun, 11 Jul 2010 12:16:42 -0700 (PDT) Received: by ewy22 with SMTP id 22so843502ewy.31 for ; Sun, 11 Jul 2010 12:16:46 -0700 (PDT) Received: by 10.213.65.141 with SMTP id j13mr8806847ebi.37.1278875806282; Sun, 11 Jul 2010 12:16:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.127.66 with HTTP; Sun, 11 Jul 2010 12:16:26 -0700 (PDT) In-Reply-To: <001f01cb2120$2d2fab80$878f0280$@com> References: <001f01cb2120$2d2fab80$878f0280$@com> From: Yakov Shafranovich Date: Sun, 11 Jul 2010 15:16:26 -0400 Message-ID: To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Sun, 11 Jul 2010 19:16:44 -0000 1. Thanks. 2. As of now, the intention of MARF is to be exchanged via email only. It is a "son of" RFC 3462 which is "multipart/report" for administrative messages regarding email. Of course, other transport methods could be defined in the future. Yakov On Sun, Jul 11, 2010 at 1:40 PM, Wenjun (Kevin) Zeng wrote: > Hi Yakov and all, > > A couple of clarifications. > > 1. Although OMA SpamRep was originally motivated by feedback loop between > the end user and > their network provider, the actual specification only specifies two logical > entities, i.e., a SpamRep server and a SpamRep client where the client could > be UA, MTA, SMSC etc. > > 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF > restricted to email delivery of report only? > > Thanks. > > -Kevin > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Sunday, July 11, 2010 10:53 AM > To: marf@ietf.org > Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" > > This is in regards to the following draft: > > http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt > > As per emails to the list and the SpamRep documentation at the OMA, > this draft is trying to address the gap between MARF and the OMA > SpamRep requirements. One key point to note is that the MARF model is > focused on feedback loops between the ISP and the original email > sender, while the OMA SpamRep activity is focused on the end user and > their network provider. The analogous use case in the email space is a > "report spam" button for end users which creates a report for their > ISP. > > 1. Section 1.2 "requirements" - this seems to repeat the main MARF > draft requirements and seems to be different from the OMA > requirements. There is no need to repeat the MARF requirements > verbatim, it may be sufficient to reference them. The OMA requirements > should be referenced, and some of the OMA SpamRep requirements which > cannot be solved with MARF should be addressed explicitly here. > Ideally this section should clearly state that this draft seeks to > address OMA requirements X and Y, but not Z. > > 2. There needs to be a reference in the draft to the standard that > defines SMS/MMS message formats. This is needed in order for us to see > how it differs from email. Additionally, you need to specify whether > these SMS/MMS spam report will be delivered via email. If not, this > may not fall within MARF or IETF scope of work. > > 3. As per the MARF draft, there is a specific format to be followed > when defining fields for the registry. You need to specify which abuse > type it references, whether it is included once or multiple times, and > whether it is historical. That format should be followed. > Additionally, ABNF would not hurt. > > 4. The draft keeps referencing abuse detected by the message center. > However, the OMA SpamRep requirements talk about the end user > reporting spam. > > 5. One of the basic principles underpinning MARF is that the data > included in section 2 of the report, should be data that cannot be > otherwise derived from the original message. Many of the fields that I > see listed seem to be ones that will be included in the original > message itself. There is no need to repeat them again in section 2 of > the report. > > Some field specific comments: > 6. "Message ID" - in the email world, this is automatically generated > in the headers of the MARF report itself. > 7. "Message Center ID" - in the email world the sender of the MARF > report would be in the headers. > 8. "Message Type" - MARF is specific for email, IM reporting has its > own formatting. You will need to create a registry or tightly define > this. Also, is this information that would be included in the original > message? > 9. Fields 4.4 - 4.15 - are these included in the original message? Is > there a need to repeat them in part 2? > 10. Abuse types - is there a need for all of these? Prior discussion > here seems to indicate that most of these are not necessary and some > overlap. For example, message flooding and DOS are the same. > 11. Abuse detection methods - this is similar to the authentication > results header we currently discussed regarding DKIM. There needs to > be a document covering this. > 12. Sections 4.18-4.23 - is any of this data included in the original > message? Also, are any of these currently used? > 13. Regarding feedback types - I would recommend looking at the > possibility of defining a new feedback type called "sms" or "mobile" > and re-using as much as possible of existing MARF. For example, abuse > keywords, etc. could be specified using URIs. > > Yakov > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > From alex@bobotek.net Sun Jul 11 13:19:56 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 961783A6800 for ; Sun, 11 Jul 2010 13:19:56 -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 V+4zdVf2LSlg for ; Sun, 11 Jul 2010 13:19:55 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id 92CD83A635F for ; Sun, 11 Jul 2010 13:19:50 -0700 (PDT) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta12.emeryville.ca.mail.comcast.net with comcast id gk8N1e0020x6nqcACkKx1C; Sun, 11 Jul 2010 20:19:57 +0000 Received: from bobo1.bobotek.net ([71.227.197.27]) by omta12.emeryville.ca.mail.comcast.net with comcast id gkKx1e0030bxBZT8YkKxmo; Sun, 11 Jul 2010 20:19:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Sun, 11 Jul 2010 13:19:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <001f01cb2120$2d2fab80$878f0280$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers Thread-Index: AcshET9HRHPEbGZORiK4Fzt7R24z1gACxiKwAAVLWzA= References: <001f01cb2120$2d2fab80$878f0280$@com> From: "Alex Bobotek" To: , "Yakov Shafranovich" , Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers 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: Sun, 11 Jul 2010 20:19:56 -0000 I believe that a single standard for mobile reporting (OMA and/or IETF) should be our goal, and am very interested in seeing OMA and IETF develop standards that do not fragment use and implementation, whether by having one or both bodies produce applicable standard(s). SpamRep was motivated by a desire to provide reporting from more than end users: to provide a standard format for mobile reporting. Yes, it is important to have a mobile spec that can be incorporated into phones by device manufacturers otherwise uninvolved in anti-abuse. However, the SMS portion was writer to specifically support the following (and hopefully other) classes of reporting: * Manual reporting from an SMS UA to a network node * Automated reporting from an SMS UA to a network node * Automated/manual reporting from an SS7 or SMPP network node such as an SMSC * Intercarrier abuse notifications SMS abuse reporting presents many challenges that are less prominent in email, notably that there are inherently many gateways (protocol conversions) in the delivery path, and very little backtrace information (as in email headers). =20 In drafting the SMS portion of SpamRep, I found supporting multiple reporter classes to be a challenge, but not an impossibility. Separate specifications seem to be an unnecessary and disadvantageous approach. =20 While contributing to OMA SpamRep, OMA contributors (myself included) been following ARF/MARF, even using it as a baseline for many initial SpamRep requirements and features. Two key differences between SpamRep and MARF are: * SMTP vs HTTP (at least typically) for transport=20 * XML vs RFC 5322 (email) style headers for report and message metadata IMO, either transport-independence (costly in that transport features such as encryption and authentication may be leveraged) or adaptation to multiple transports (my preference) is desirable and entirely feasible. The key difference is that SpamRep is XML-based while thdraft-cai-smsc-mmsc-reporting-marf-00 draft and MARF is header-based. At the root of this is that email works this way, while many other communications systems use XML. Does anyone have any suggestions on how to drive convergence? =20 Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Wenjun (Kevin) Zeng Sent: Sunday, July 11, 2010 10:41 AM To: 'Yakov Shafranovich'; marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Hi Yakov and all, A couple of clarifications. 1. Although OMA SpamRep was originally motivated by feedback loop between the end user and their network provider, the actual specification only specifies two logical entities, i.e., a SpamRep server and a SpamRep client where the client could be UA, MTA, SMSC etc. 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF restricted to email delivery of report only? Thanks. -Kevin -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Yakov Shafranovich Sent: Sunday, July 11, 2010 10:53 AM To: marf@ietf.org Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" This is in regards to the following draft: http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt As per emails to the list and the SpamRep documentation at the OMA, this draft is trying to address the gap between MARF and the OMA SpamRep requirements. One key point to note is that the MARF model is focused on feedback loops between the ISP and the original email sender, while the OMA SpamRep activity is focused on the end user and their network provider. The analogous use case in the email space is a "report spam" button for end users which creates a report for their ISP. 1. Section 1.2 "requirements" - this seems to repeat the main MARF draft requirements and seems to be different from the OMA requirements. There is no need to repeat the MARF requirements verbatim, it may be sufficient to reference them. The OMA requirements should be referenced, and some of the OMA SpamRep requirements which cannot be solved with MARF should be addressed explicitly here. Ideally this section should clearly state that this draft seeks to address OMA requirements X and Y, but not Z. 2. There needs to be a reference in the draft to the standard that defines SMS/MMS message formats. This is needed in order for us to see how it differs from email. Additionally, you need to specify whether these SMS/MMS spam report will be delivered via email. If not, this may not fall within MARF or IETF scope of work. 3. As per the MARF draft, there is a specific format to be followed when defining fields for the registry. You need to specify which abuse type it references, whether it is included once or multiple times, and whether it is historical. That format should be followed. Additionally, ABNF would not hurt. 4. The draft keeps referencing abuse detected by the message center. However, the OMA SpamRep requirements talk about the end user reporting spam. 5. One of the basic principles underpinning MARF is that the data included in section 2 of the report, should be data that cannot be otherwise derived from the original message. Many of the fields that I see listed seem to be ones that will be included in the original message itself. There is no need to repeat them again in section 2 of the report. Some field specific comments: 6. "Message ID" - in the email world, this is automatically generated in the headers of the MARF report itself. 7. "Message Center ID" - in the email world the sender of the MARF report would be in the headers. 8. "Message Type" - MARF is specific for email, IM reporting has its own formatting. You will need to create a registry or tightly define this. Also, is this information that would be included in the original message? 9. Fields 4.4 - 4.15 - are these included in the original message? Is there a need to repeat them in part 2? 10. Abuse types - is there a need for all of these? Prior discussion here seems to indicate that most of these are not necessary and some overlap. For example, message flooding and DOS are the same. 11. Abuse detection methods - this is similar to the authentication results header we currently discussed regarding DKIM. There needs to be a document covering this. 12. Sections 4.18-4.23 - is any of this data included in the original message? Also, are any of these currently used? 13. Regarding feedback types - I would recommend looking at the possibility of defining a new feedback type called "sms" or "mobile" and re-using as much as possible of existing MARF. For example, abuse keywords, etc. could be specified using URIs. Yakov _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yakov@shaftek.org Sun Jul 11 16:34:03 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 1B7743A6A1E for ; Sun, 11 Jul 2010 16:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.511, 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 FoOpr+3C-9Pp for ; Sun, 11 Jul 2010 16:34:01 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4856E3A6A13 for ; Sun, 11 Jul 2010 16:34:01 -0700 (PDT) Received: by ewy22 with SMTP id 22so870605ewy.31 for ; Sun, 11 Jul 2010 16:34:04 -0700 (PDT) Received: by 10.213.32.140 with SMTP id c12mr814933ebd.95.1278891244464; Sun, 11 Jul 2010 16:34:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.127.66 with HTTP; Sun, 11 Jul 2010 16:33:44 -0700 (PDT) In-Reply-To: References: <001f01cb2120$2d2fab80$878f0280$@com> From: Yakov Shafranovich Date: Sun, 11 Jul 2010 19:33:44 -0400 Message-ID: To: Alex Bobotek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers 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: Sun, 11 Jul 2010 23:34:03 -0000 One of the main issues with the draft as it is, is the basic principle of MARF as it was designed - section 2, the machine readable section, should not contain any data that can be derived from the message itself. Because we don't know what standard you are using for defining SMS / MMS formats, I can't figure out whether the various message fields are already included in the original message. Yakov On Sun, Jul 11, 2010 at 4:19 PM, Alex Bobotek wrote: > I believe that a single standard for mobile reporting (OMA and/or IETF) > should be our goal, and am very interested in seeing OMA and IETF > develop standards that do not fragment use and implementation, whether > by having one or both bodies produce applicable standard(s). > > SpamRep was motivated by a desire to provide reporting from more than > end users: =A0to provide a standard format for mobile reporting. =A0Yes, = it > is important to have a mobile spec that can be incorporated into phones > by device manufacturers otherwise uninvolved in anti-abuse. =A0However, > the SMS portion was writer to specifically support the following (and > hopefully other) classes of reporting: > > * =A0Manual reporting from an SMS UA to a network node > * =A0Automated reporting from an SMS UA to a network node > * =A0Automated/manual reporting from an SS7 or SMPP network node such as > an SMSC > * =A0Intercarrier abuse notifications > > SMS abuse reporting presents many challenges that are less prominent in > email, notably that there are inherently many gateways (protocol > conversions) in the delivery path, and very little backtrace information > (as in email headers). > > In drafting the SMS portion of SpamRep, I found supporting multiple > reporter classes to be a challenge, but not an impossibility. =A0Separate > specifications seem to be an unnecessary and disadvantageous approach. > > While contributing to OMA SpamRep, OMA contributors (myself included) > been following ARF/MARF, even using it as a baseline for many initial > SpamRep requirements and features. =A0Two key differences between SpamRep > and MARF are: > > * SMTP vs HTTP (at least typically) for transport > * XML vs RFC 5322 (email) style headers for report and message metadata > > IMO, either transport-independence (costly in that transport features > such as encryption and authentication may be leveraged) or adaptation to > multiple transports (my preference) is desirable and entirely feasible. > > The key difference is that SpamRep is XML-based while > thdraft-cai-smsc-mmsc-reporting-marf-00 draft and MARF is header-based. > At the root of this is that email works this way, while many other > communications systems use XML. =A0Does anyone have any suggestions on ho= w > to drive convergence? > > > > Regards, > > Alex > > > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Wenjun (Kevin) Zeng > Sent: Sunday, July 11, 2010 10:41 AM > To: 'Yakov Shafranovich'; marf@ietf.org > Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" > > Hi Yakov and all, > > A couple of clarifications. > > 1. Although OMA SpamRep was originally motivated by feedback loop > between > the end user and > their network provider, the actual specification only specifies two > logical > entities, i.e., a SpamRep server and a SpamRep client where the client > could > be UA, MTA, SMSC etc. > > 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF > restricted to email delivery of report only? > > Thanks. > > -Kevin > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Sunday, July 11, 2010 10:53 AM > To: marf@ietf.org > Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" > > This is in regards to the following draft: > > http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt > > As per emails to the list and the SpamRep documentation at the OMA, > this draft is trying to address the gap between MARF and the OMA > SpamRep requirements. One key point to note is that the MARF model is > focused on feedback loops between the ISP and the original email > sender, while the OMA SpamRep activity is focused on the end user and > their network provider. The analogous use case in the email space is a > "report spam" button for end users which creates a report for their > ISP. > > 1. Section 1.2 "requirements" - this seems to repeat the main MARF > draft requirements and seems to be different from the OMA > requirements. There is no need to repeat the MARF requirements > verbatim, it may be sufficient to reference them. The OMA requirements > should be referenced, and some of the OMA SpamRep requirements which > cannot be solved with MARF should be addressed explicitly here. > Ideally this section should clearly state that this draft seeks to > address OMA requirements X and Y, but not Z. > > 2. There needs to be a reference in the draft to the standard that > defines SMS/MMS message formats. This is needed in order for us to see > how it differs from email. Additionally, you need to specify whether > these SMS/MMS spam report will be delivered via email. If not, this > may not fall within MARF or IETF scope of work. > > 3. As per the MARF draft, there is a specific format to be followed > when defining fields for the registry. You need to specify which abuse > type it references, whether it is included once or multiple times, and > whether it is historical. That format should be followed. > Additionally, ABNF would not hurt. > > 4. The draft keeps referencing abuse detected by the message center. > However, the OMA SpamRep requirements talk about the end user > reporting spam. > > 5. One of the basic principles underpinning MARF is that the data > included in section 2 of the report, should be data that cannot be > otherwise derived from the original message. Many of the fields that I > see listed seem to be ones that will be included in the original > message itself. There is no need to repeat them again in section 2 of > the report. > > Some field specific comments: > 6. "Message ID" - in the email world, this is automatically generated > in the headers of the MARF report itself. > 7. "Message Center ID" - in the email world the sender of the MARF > report would be in the headers. > 8. "Message Type" - MARF is specific for email, IM reporting has its > own formatting. You will need to create a registry or tightly define > this. Also, is this information that would be included in the original > message? > 9. Fields 4.4 - 4.15 - are these included in the original message? Is > there a need to repeat them in part 2? > 10. Abuse types - is there a need for all of these? Prior discussion > here seems to indicate that most of these are not necessary and some > overlap. For example, message flooding and DOS are the same. > 11. Abuse detection methods - this is similar to the authentication > results header we currently discussed regarding DKIM. There needs to > be a document covering this. > 12. Sections 4.18-4.23 - is any of this data included in the original > message? Also, are any of these currently used? > 13. Regarding feedback types - I would recommend looking at the > possibility of defining a new feedback type called "sms" or "mobile" > and re-using as much as possible of existing MARF. For example, abuse > keywords, etc. could be specified using URIs. > > Yakov > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From alex@bobotek.net Sun Jul 11 21:09: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 B84053A68E6 for ; Sun, 11 Jul 2010 21:09:23 -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 qUiD5ZAI5IoX for ; Sun, 11 Jul 2010 21:09:22 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 2D7643A68CE for ; Sun, 11 Jul 2010 21:09:21 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta15.emeryville.ca.mail.comcast.net with comcast id gqTn1e0061GXsucAFs9VDP; Mon, 12 Jul 2010 04:09:29 +0000 Received: from bobo1.bobotek.net ([71.227.197.27]) by omta07.emeryville.ca.mail.comcast.net with comcast id gs9U1e00C0bxBZT8Us9VYv; Mon, 12 Jul 2010 04:09:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Jul 2010 21:08:30 -0700 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers Thread-Index: AcshUY5ehQhupkwGRCqJhwMMuSA1zgAEYjBw References: <001f01cb2120$2d2fab80$878f0280$@com> From: "Alex Bobotek" To: "Yakov Shafranovich" Cc: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers 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 Jul 2010 04:09:23 -0000 Yakov, I'm not certain whether your comment was intended to addresses the = SpamRep, draft-cai-smsc-mmsc-reporting-marf-00 or both. However, field = definition and mapping is a challenge for any SMS standard. Even in a = most common type of SMSC (SMPP<---->GSM MAP), an abusive message may be = received in MAP or SMPP protocols. =20 The Sad Fact of SMS Mangling during (and after) Transport The lack of a single transport protocol over the numerous hops in SMS = transport has its challenges; the "original message" often does not = exist. GSM OTA-->GSM MAP-->SMPP-->SMPP-->GSM MAP-->GSM OTA gateway and = protocol conversions are common. And GSM and SMPP standards are by no = means the only ones in play, nor is there necessarily any indication of = the route a message may have traversed or what protocol conversions or = modifications may have been performed. Beyond this, there is = segmentation/reassembly, and a UA may render SMS text into Unicode or = some other format for local storage, and discard much of an original = message's (perhaps GSM MAP) information. Even where unadulterated = copies of a message may exist, their fidelity may be uncertain. For = example, what was the original UDH information? Without a complete set = of GSM MAP and/or SMPP attributes and perhaps original padding, a full = corpus cannot be constructed. And simply dropping, say, a UDH header = attribute in GSM MAP may substantially mangle a message. =20 So how should this be handled? Should there be different protocols for = reporting from SMSCs, SMPP, GSM MAP, clients, SIP IPSM Gateways, STPs, = user agents, etc.? I think not. This uncertainty as to the fidelity of = 'corpus' is seemingly incompatible with a pragma of excluding from = metadata (e.g, Section 2) anything which may be contained in message = corpus. A further complication is the lack of delivery path info in SMS = (no Received headers). SpamRep further allows for variant formats = which, at times place similar information in XML and other times in = corpus. =20 IMHO, an applicable set of pragmas for SMS is: * Report what you can * Report as fact what you know * Report what you are told as hearsay OMA SMS SpamRep attributes were largely extracted from GSM MAP and SMPP = protocol fields. But it is recognized that many attributes are not = always available. It is PREFERRED that accurate corpus be attached, but = this isn't always possible. In OMA SMS SpamRep there is metadata (i.e., = DecodedUDIndicator and UDHAttached) that indicates whether or not, for = example, the attached SMS corpus contains verbatim UD and UDH. Another = important metadata field (sometimes discernable from the message corpus) = is SpamRep's 'ReportingNode' {SMS_Router, IP-SM-GW, SMS Router, IP-SM-GW, SMS-SC, Mobile_Device, Subscriber, = Email_Gateway, Unknown, Other} attribute. OMA SpamRep SMS reporting attempts to address the myriad challenges of = SMS abuse reporting discussed above, and others. =20 Regards, Alex -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org]=20 Sent: Sunday, July 11, 2010 4:34 PM To: Alex Bobotek Cc: zengw@huawei.com; marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": = XML vs Headers One of the main issues with the draft as it is, is the basic principle of MARF as it was designed - section 2, the machine readable section, should not contain any data that can be derived from the message itself. Because we don't know what standard you are using for defining SMS / MMS formats, I can't figure out whether the various message fields are already included in the original message. Yakov On Sun, Jul 11, 2010 at 4:19 PM, Alex Bobotek wrote: > I believe that a single standard for mobile reporting (OMA and/or = IETF) > should be our goal, and am very interested in seeing OMA and IETF > develop standards that do not fragment use and implementation, whether > by having one or both bodies produce applicable standard(s). > > SpamRep was motivated by a desire to provide reporting from more than > end users: =A0to provide a standard format for mobile reporting. = =A0Yes, it > is important to have a mobile spec that can be incorporated into = phones > by device manufacturers otherwise uninvolved in anti-abuse. = =A0However, > the SMS portion was writer to specifically support the following (and > hopefully other) classes of reporting: > > * =A0Manual reporting from an SMS UA to a network node > * =A0Automated reporting from an SMS UA to a network node > * =A0Automated/manual reporting from an SS7 or SMPP network node such = as > an SMSC > * =A0Intercarrier abuse notifications > > SMS abuse reporting presents many challenges that are less prominent = in > email, notably that there are inherently many gateways (protocol > conversions) in the delivery path, and very little backtrace = information > (as in email headers). > > In drafting the SMS portion of SpamRep, I found supporting multiple > reporter classes to be a challenge, but not an impossibility. = =A0Separate > specifications seem to be an unnecessary and disadvantageous approach. > > While contributing to OMA SpamRep, OMA contributors (myself included) > been following ARF/MARF, even using it as a baseline for many initial > SpamRep requirements and features. =A0Two key differences between = SpamRep > and MARF are: > > * SMTP vs HTTP (at least typically) for transport > * XML vs RFC 5322 (email) style headers for report and message = metadata > > IMO, either transport-independence (costly in that transport features > such as encryption and authentication may be leveraged) or adaptation = to > multiple transports (my preference) is desirable and entirely = feasible. > > The key difference is that SpamRep is XML-based while > thdraft-cai-smsc-mmsc-reporting-marf-00 draft and MARF is = header-based. > At the root of this is that email works this way, while many other > communications systems use XML. =A0Does anyone have any suggestions on = how > to drive convergence? > > > > Regards, > > Alex > > > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of > Wenjun (Kevin) Zeng > Sent: Sunday, July 11, 2010 10:41 AM > To: 'Yakov Shafranovich'; marf@ietf.org > Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" > > Hi Yakov and all, > > A couple of clarifications. > > 1. Although OMA SpamRep was originally motivated by feedback loop > between > the end user and > their network provider, the actual specification only specifies two > logical > entities, i.e., a SpamRep server and a SpamRep client where the client > could > be UA, MTA, SMSC etc. > > 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF > restricted to email delivery of report only? > > Thanks. > > -Kevin > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of > Yakov Shafranovich > Sent: Sunday, July 11, 2010 10:53 AM > To: marf@ietf.org > Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" > > This is in regards to the following draft: > > http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt > > As per emails to the list and the SpamRep documentation at the OMA, > this draft is trying to address the gap between MARF and the OMA > SpamRep requirements. One key point to note is that the MARF model is > focused on feedback loops between the ISP and the original email > sender, while the OMA SpamRep activity is focused on the end user and > their network provider. The analogous use case in the email space is a > "report spam" button for end users which creates a report for their > ISP. > > 1. Section 1.2 "requirements" - this seems to repeat the main MARF > draft requirements and seems to be different from the OMA > requirements. There is no need to repeat the MARF requirements > verbatim, it may be sufficient to reference them. The OMA requirements > should be referenced, and some of the OMA SpamRep requirements which > cannot be solved with MARF should be addressed explicitly here. > Ideally this section should clearly state that this draft seeks to > address OMA requirements X and Y, but not Z. > > 2. There needs to be a reference in the draft to the standard that > defines SMS/MMS message formats. This is needed in order for us to see > how it differs from email. Additionally, you need to specify whether > these SMS/MMS spam report will be delivered via email. If not, this > may not fall within MARF or IETF scope of work. > > 3. As per the MARF draft, there is a specific format to be followed > when defining fields for the registry. You need to specify which abuse > type it references, whether it is included once or multiple times, and > whether it is historical. That format should be followed. > Additionally, ABNF would not hurt. > > 4. The draft keeps referencing abuse detected by the message center. > However, the OMA SpamRep requirements talk about the end user > reporting spam. > > 5. One of the basic principles underpinning MARF is that the data > included in section 2 of the report, should be data that cannot be > otherwise derived from the original message. Many of the fields that I > see listed seem to be ones that will be included in the original > message itself. There is no need to repeat them again in section 2 of > the report. > > Some field specific comments: > 6. "Message ID" - in the email world, this is automatically generated > in the headers of the MARF report itself. > 7. "Message Center ID" - in the email world the sender of the MARF > report would be in the headers. > 8. "Message Type" - MARF is specific for email, IM reporting has its > own formatting. You will need to create a registry or tightly define > this. Also, is this information that would be included in the original > message? > 9. Fields 4.4 - 4.15 - are these included in the original message? Is > there a need to repeat them in part 2? > 10. Abuse types - is there a need for all of these? Prior discussion > here seems to indicate that most of these are not necessary and some > overlap. For example, message flooding and DOS are the same. > 11. Abuse detection methods - this is similar to the authentication > results header we currently discussed regarding DKIM. There needs to > be a document covering this. > 12. Sections 4.18-4.23 - is any of this data included in the original > message? Also, are any of these currently used? > 13. Regarding feedback types - I would recommend looking at the > possibility of defining a new feedback type called "sms" or "mobile" > and re-using as much as possible of existing MARF. For example, abuse > keywords, etc. could be specified using URIs. > > Yakov > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From yakov@shaftek.org Sun Jul 11 21:10:45 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 3351A28C114 for ; Sun, 11 Jul 2010 21:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=0.409, 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 v6sJZDnGHA81 for ; Sun, 11 Jul 2010 21:10:40 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 7140E3A68E6 for ; Sun, 11 Jul 2010 21:10:40 -0700 (PDT) Received: by eyb7 with SMTP id 7so632899eyb.31 for ; Sun, 11 Jul 2010 21:10:44 -0700 (PDT) Received: by 10.213.13.71 with SMTP id b7mr9552295eba.3.1278907844231; Sun, 11 Jul 2010 21:10:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.127.66 with HTTP; Sun, 11 Jul 2010 21:10:24 -0700 (PDT) In-Reply-To: References: <001f01cb2120$2d2fab80$878f0280$@com> From: Yakov Shafranovich Date: Mon, 12 Jul 2010 00:10:24 -0400 Message-ID: To: Alex Bobotek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers 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 Jul 2010 04:10:45 -0000 Considering this, is it smart to shore horn SMS abuse reporting into MARF? On Mon, Jul 12, 2010 at 12:08 AM, Alex Bobotek wrote: > Yakov, > > I'm not certain whether your comment was intended to addresses the SpamRe= p, draft-cai-smsc-mmsc-reporting-marf-00 or both. =A0However, field definit= ion and mapping is a challenge for any SMS standard. =A0Even in a most comm= on type of SMSC (SMPP<---->GSM MAP), an abusive message may be received in = MAP or SMPP protocols. > > The Sad Fact of SMS Mangling during (and after) Transport > > The lack of a single transport protocol over the numerous hops in SMS tra= nsport has its challenges; the "original message" often does not exist. =A0= GSM OTA-->GSM MAP-->SMPP-->SMPP-->GSM MAP-->GSM OTA gateway and protocol co= nversions are common. =A0And GSM and SMPP standards are by no means the onl= y ones in play, nor is there necessarily any indication of the route a mess= age may have traversed or what protocol conversions or modifications may ha= ve been performed. =A0Beyond this, there is segmentation/reassembly, and a = UA may render SMS text into Unicode or some other format for local storage,= and discard much of an original message's (perhaps GSM MAP) information. = =A0Even where unadulterated copies of a message may exist, their fidelity m= ay be uncertain. =A0For example, what was the original UDH information? =A0= Without a complete set of GSM MAP and/or SMPP attributes and perhaps origin= al padding, a full corpus cannot be constructed. =A0And simply dropping, sa= y, a UDH header attribute in GSM MAP may substantially mangle a message. > > So how should this be handled? =A0Should there be different protocols for= reporting from SMSCs, SMPP, GSM MAP, clients, SIP IPSM Gateways, STPs, use= r agents, etc.? =A0I think not. =A0This uncertainty as to the fidelity of '= corpus' is seemingly incompatible with a pragma of excluding from metadata = (e.g, Section 2) anything which may be contained in message corpus. =A0A fu= rther complication is the lack of delivery path info in SMS (no Received he= aders). =A0SpamRep further allows for variant formats which, at times place= similar information in XML and other times in corpus. > > IMHO, an applicable set of pragmas for SMS is: > * =A0 =A0 =A0 Report what you can > =A0 =A0 =A0 =A0* =A0 =A0 =A0 Report as fact what you know > =A0 =A0 =A0 =A0* =A0 =A0 =A0 Report what you are told as hearsay > > OMA SMS SpamRep attributes were largely extracted from GSM MAP and SMPP p= rotocol fields. =A0But it is recognized that many attributes are not always= available. =A0It is PREFERRED that accurate corpus be attached, but this i= sn't always possible. =A0In OMA SMS SpamRep there is metadata (i.e., Decode= dUDIndicator and UDHAttached) that indicates whether or not, for example, t= he attached SMS corpus contains verbatim UD and UDH. =A0Another important m= etadata field (sometimes discernable from the message corpus) is SpamRep's = 'ReportingNode' {SMS_Router, > IP-SM-GW, SMS Router, IP-SM-GW, SMS-SC, Mobile_Device, Subscriber, Email_= Gateway, Unknown, Other} attribute. > > OMA SpamRep SMS reporting attempts to address the myriad challenges of SM= S abuse reporting discussed above, and others. > > Regards, > > Alex > > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Sunday, July 11, 2010 4:34 PM > To: Alex Bobotek > Cc: zengw@huawei.com; marf@ietf.org > Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XM= L vs Headers > > One of the main issues with the draft as it is, is the basic principle > of MARF as it was designed - section 2, the machine readable section, > should not contain any data that can be derived from the message > itself. Because we don't know what standard you are using for defining > SMS / MMS formats, I can't figure out whether the various message > fields are already included in the original message. > > Yakov > > On Sun, Jul 11, 2010 at 4:19 PM, Alex Bobotek wrote: >> I believe that a single standard for mobile reporting (OMA and/or IETF) >> should be our goal, and am very interested in seeing OMA and IETF >> develop standards that do not fragment use and implementation, whether >> by having one or both bodies produce applicable standard(s). >> >> SpamRep was motivated by a desire to provide reporting from more than >> end users: =A0to provide a standard format for mobile reporting. =A0Yes,= it >> is important to have a mobile spec that can be incorporated into phones >> by device manufacturers otherwise uninvolved in anti-abuse. =A0However, >> the SMS portion was writer to specifically support the following (and >> hopefully other) classes of reporting: >> >> * =A0Manual reporting from an SMS UA to a network node >> * =A0Automated reporting from an SMS UA to a network node >> * =A0Automated/manual reporting from an SS7 or SMPP network node such as >> an SMSC >> * =A0Intercarrier abuse notifications >> >> SMS abuse reporting presents many challenges that are less prominent in >> email, notably that there are inherently many gateways (protocol >> conversions) in the delivery path, and very little backtrace information >> (as in email headers). >> >> In drafting the SMS portion of SpamRep, I found supporting multiple >> reporter classes to be a challenge, but not an impossibility. =A0Separat= e >> specifications seem to be an unnecessary and disadvantageous approach. >> >> While contributing to OMA SpamRep, OMA contributors (myself included) >> been following ARF/MARF, even using it as a baseline for many initial >> SpamRep requirements and features. =A0Two key differences between SpamRe= p >> and MARF are: >> >> * SMTP vs HTTP (at least typically) for transport >> * XML vs RFC 5322 (email) style headers for report and message metadata >> >> IMO, either transport-independence (costly in that transport features >> such as encryption and authentication may be leveraged) or adaptation to >> multiple transports (my preference) is desirable and entirely feasible. >> >> The key difference is that SpamRep is XML-based while >> thdraft-cai-smsc-mmsc-reporting-marf-00 draft and MARF is header-based. >> At the root of this is that email works this way, while many other >> communications systems use XML. =A0Does anyone have any suggestions on h= ow >> to drive convergence? >> >> >> >> Regards, >> >> Alex >> >> >> >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of >> Wenjun (Kevin) Zeng >> Sent: Sunday, July 11, 2010 10:41 AM >> To: 'Yakov Shafranovich'; marf@ietf.org >> Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" >> >> Hi Yakov and all, >> >> A couple of clarifications. >> >> 1. Although OMA SpamRep was originally motivated by feedback loop >> between >> the end user and >> their network provider, the actual specification only specifies two >> logical >> entities, i.e., a SpamRep server and a SpamRep client where the client >> could >> be UA, MTA, SMSC etc. >> >> 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF >> restricted to email delivery of report only? >> >> Thanks. >> >> -Kevin >> >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of >> Yakov Shafranovich >> Sent: Sunday, July 11, 2010 10:53 AM >> To: marf@ietf.org >> Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" >> >> This is in regards to the following draft: >> >> http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt >> >> As per emails to the list and the SpamRep documentation at the OMA, >> this draft is trying to address the gap between MARF and the OMA >> SpamRep requirements. One key point to note is that the MARF model is >> focused on feedback loops between the ISP and the original email >> sender, while the OMA SpamRep activity is focused on the end user and >> their network provider. The analogous use case in the email space is a >> "report spam" button for end users which creates a report for their >> ISP. >> >> 1. Section 1.2 "requirements" - this seems to repeat the main MARF >> draft requirements and seems to be different from the OMA >> requirements. There is no need to repeat the MARF requirements >> verbatim, it may be sufficient to reference them. The OMA requirements >> should be referenced, and some of the OMA SpamRep requirements which >> cannot be solved with MARF should be addressed explicitly here. >> Ideally this section should clearly state that this draft seeks to >> address OMA requirements X and Y, but not Z. >> >> 2. There needs to be a reference in the draft to the standard that >> defines SMS/MMS message formats. This is needed in order for us to see >> how it differs from email. Additionally, you need to specify whether >> these SMS/MMS spam report will be delivered via email. If not, this >> may not fall within MARF or IETF scope of work. >> >> 3. As per the MARF draft, there is a specific format to be followed >> when defining fields for the registry. You need to specify which abuse >> type it references, whether it is included once or multiple times, and >> whether it is historical. That format should be followed. >> Additionally, ABNF would not hurt. >> >> 4. The draft keeps referencing abuse detected by the message center. >> However, the OMA SpamRep requirements talk about the end user >> reporting spam. >> >> 5. One of the basic principles underpinning MARF is that the data >> included in section 2 of the report, should be data that cannot be >> otherwise derived from the original message. Many of the fields that I >> see listed seem to be ones that will be included in the original >> message itself. There is no need to repeat them again in section 2 of >> the report. >> >> Some field specific comments: >> 6. "Message ID" - in the email world, this is automatically generated >> in the headers of the MARF report itself. >> 7. "Message Center ID" - in the email world the sender of the MARF >> report would be in the headers. >> 8. "Message Type" - MARF is specific for email, IM reporting has its >> own formatting. You will need to create a registry or tightly define >> this. Also, is this information that would be included in the original >> message? >> 9. Fields 4.4 - 4.15 - are these included in the original message? Is >> there a need to repeat them in part 2? >> 10. Abuse types - is there a need for all of these? Prior discussion >> here seems to indicate that most of these are not necessary and some >> overlap. For example, message flooding and DOS are the same. >> 11. Abuse detection methods - this is similar to the authentication >> results header we currently discussed regarding DKIM. There needs to >> be a document covering this. >> 12. Sections 4.18-4.23 - is any of this data included in the original >> message? Also, are any of these currently used? >> 13. Regarding feedback types - I would recommend looking at the >> possibility of defining a new feedback type called "sms" or "mobile" >> and re-using as much as possible of existing MARF. For example, abuse >> keywords, etc. could be specified using URIs. >> >> Yakov >> _______________________________________________ >> marf mailing list >> marf@ietf.org >> https://www.ietf.org/mailman/listinfo/marf >> >> _______________________________________________ >> marf mailing list >> marf@ietf.org >> https://www.ietf.org/mailman/listinfo/marf >> > From johnl@iecc.com Sun Jul 11 22:22: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 B468A3A6A40 for ; Sun, 11 Jul 2010 22:22:01 -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 NyIDisEtNhj9 for ; Sun, 11 Jul 2010 22:21:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 746613A6835 for ; Sun, 11 Jul 2010 22:21:59 -0700 (PDT) Received: (qmail 53321 invoked from network); 12 Jul 2010 05:17:16 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 Jul 2010 05:17:16 -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=k1007; olt=johnl@user.iecc.com; bh=9sQNxJ29sBr4tlAvA+SDIxNFXb80CuH7D1chDhlmyLo=; b=LcgCQSmTh5p176AJgEgLg8AVJvMenLXKDwPS9cgbXf6DV+R9vtkvfh/TwjbPxdPveg0CYZVUmpp5C8DlVuewcvxoRuvCU4ycwN/GF9tYRM26SiXrJRqDAZSM8fkZSzl3LM3xlhqqIZFJR+HMonghc5Alx6FRJ5wfJ4Ct7mcZgEU= 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=k1007; bh=9sQNxJ29sBr4tlAvA+SDIxNFXb80CuH7D1chDhlmyLo=; b=jXaQJ2l+NG3mgnlzWUFmFh2eJoHDZx5mLm+gCEcJ9Nw1O2olh0fkCKDwq+r6ZK17lJVApf9vkC73dJDoqfp1ZJhfDa23FdltJDfE0XmUJhi8fdhFByG9nIYz5OAhk56Tl/5FfnJbCgHetajiV0TWwDzf2XPl7AuX47vWsZpFvVw= Date: 12 Jul 2010 05:22:06 -0000 Message-ID: <20100712052206.2387.qmail@joyce.lan> From: John Levine To: marf@ietf.org In-Reply-To: <001f01cb2120$2d2fab80$878f0280$@com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Mon, 12 Jul 2010 05:22:02 -0000 >2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF >restricted to email delivery of report only? MARF defines a MIME type. To date, it's always been sent as the body of an email message, but HTTP also transmits MIME objects. For that matter, since SpamRep is also a MIME type, you can send those, at least the ones that don't ask for an immediate response, by e-mail. Given how little SMTP and SMS have in common, I'd be more inclined to keep them separate and encourage places that can accept both to accept them both by mail and HTTP. R's, John From alex@bobotek.net Sun Jul 11 23:46: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 42C2D3A6855 for ; Sun, 11 Jul 2010 23:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 e-Uo+wM26jDy for ; Sun, 11 Jul 2010 23:46:04 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id A408B3A6A4F for ; Sun, 11 Jul 2010 23:45:51 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta06.emeryville.ca.mail.comcast.net with comcast id gul21e0020mlR8UA6ulz9N; Mon, 12 Jul 2010 06:45:59 +0000 Received: from bobo1.bobotek.net ([71.227.197.27]) by omta11.emeryville.ca.mail.comcast.net with comcast id guly1e00D0bxBZT8XulyeV; Mon, 12 Jul 2010 06:45:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Sun, 11 Jul 2010 23:45:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <20100712052206.2387.qmail@joyce.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Thread-Index: Acshgi+sJbmdX2ERQaeJ/l2ZbZoeQAAAfNBw References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> From: "Alex Bobotek" To: "John Levine" , Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Mon, 12 Jul 2010 06:46:05 -0000 I'm in agreement with John that MARF/Email and SpamRep/SMS are so far apart that it would be difficult to force them to converge. Feedback and abuse management from a mobile SMS user agent has requirements for which HTTP (or any request/response protocol) is more advantageous than SMTP. This is IMO true for any UA-based feedback, but especially so in the mobile case. =20 SpamRep is a request/response transaction protocol in which some processing (with potential side effects) may be required prior to an application-layer response. As written, it is not completely compatible with store & forward SMTP relay. It would be awkward to mail back an asynchronous response to a device that has limited Internet connectivity, and some sort of extension to SMTP would likely be necessary for handling a MIME response. Lemonade-like optimizations that prevent over-the-air transmission of messages already in possession of the receiving system are also needed. SMTP is not an ideal transport for SpamRep. =20 Emailing back protocol responses to cellular mobile devices (even if not over port 25, and especially if not immediate) isn't an attractive architecture. A substantial subset of SpamRep could, in theory, operate over a message transport protocol such as SMTP. =20 So it's probably best to use SpamRep for SMS. =20 Note that SpamRep does support Email abuse reporting over HTTP. Perhaps any overlap in this area should be discussed. Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of John Levine Sent: Sunday, July 11, 2010 10:22 PM To: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" >2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF >restricted to email delivery of report only? MARF defines a MIME type. To date, it's always been sent as the body of an email message, but HTTP also transmits MIME objects. For that matter, since SpamRep is also a MIME type, you can send those, at least the ones that don't ask for an immediate response, by e-mail. Given how little SMTP and SMS have in common, I'd be more inclined to keep them separate and encourage places that can accept both to accept them both by mail and HTTP. R's, John _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From johnl@taugh.com Mon Jul 12 00:26: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 4223E3A69A8 for ; Mon, 12 Jul 2010 00:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, MANGLED_SPAM=2.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 2udMF1LQJf-Z for ; Mon, 12 Jul 2010 00:26:49 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 1183E3A680E for ; Mon, 12 Jul 2010 00:26:48 -0700 (PDT) Received: (qmail 12985 invoked from network); 12 Jul 2010 07:22:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1007; bh=53hD0LvNfppNDxUgpQNvNqHtT0zbYyfql4iJQV0Zw80=; b=URe+i56p/8CpbpRoNM/kdmDK6JkcCAL2jw8HQ3wwupH8TuJDXBCT7323SItClXaMNy2xXC85V80I7+MdtshIhhGcT741AjTGyzKghFC1ei3LAIy+1yCNLkOovXd98XeiX+olf4dpAsmW+HAeTrydgoM2nod/39PvZdDhtIOi29o= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1007; bh=53hD0LvNfppNDxUgpQNvNqHtT0zbYyfql4iJQV0Zw80=; b=MuI8iFVFm6yC+7J1CBZdZsyK/nvVtDtSAnCSnxQuki0fV649rg9hSUkcTMXiE3/G0V/ORwM8dp9RP0tl8I//surN4/sglaqWATIPzZsq0D2iCDlnujnfXvMVjq2LAjdgPGk8lmh5jxj3IjPB5b4gjfGqzvqyOVCBwcBXDxzHuw4= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jul 2010 07:21:43 -0000 Date: 12 Jul 2010 03:26:54 -0400 Message-ID: From: "John R Levine" To: "Alex Bobotek" In-Reply-To: References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ARF mailing list Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Mon, 12 Jul 2010 07:26:51 -0000 > Note that SpamRep does support Email abuse reporting over HTTP. Perhaps > any overlap in this area should be discussed. In the ASRG, we had a robust discussion about the way one might add a spam button to a MUA: http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs One of the open questions is how the MUA sends the report back to the appropriate place, which in this case is similar to the SpamRep model, the mail server from which the MUA picked up the mail. HTTP is not a bad way to go, particularly on mobile devices where users are likely to have both e-mail and SMS/MMS spam to report. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From msk@cloudmark.com Mon Jul 12 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 65F733A6A74 for ; Mon, 12 Jul 2010 10:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 Qc6qlrNff3uZ for ; Mon, 12 Jul 2010 10:22:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id CD2DF3A6B54 for ; Mon, 12 Jul 2010 10:22:06 -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, 12 Jul 2010 10:22:14 -0700 From: "Murray S. Kucherawy" To: Alex Bobotek , John Levine , "marf@ietf.org" Date: Mon, 12 Jul 2010 10:22:13 -0700 Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Thread-Index: Acshgi+sJbmdX2ERQaeJ/l2ZbZoeQAAAfNBwABiSo+A= Message-ID: References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> 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] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Mon, 12 Jul 2010 17:22:16 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alex Bobotek > Sent: Sunday, July 11, 2010 11:45 PM > To: John Levine; marf@ietf.org > Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" >=20 > SpamRep is a request/response transaction protocol in which some > processing (with potential side effects) may be required prior to an > application-layer response. As written, it is not completely > compatible > with store & forward SMTP relay. It would be awkward to mail back an > asynchronous response to a device that has limited Internet > connectivity, and some sort of extension to SMTP would likely be > necessary for handling a MIME response. Lemonade-like optimizations > that prevent over-the-air transmission of messages already in > possession > of the receiving system are also needed. SMTP is not an ideal > transport > for SpamRep. >=20 > Emailing back protocol responses to cellular mobile devices (even if > not > over port 25, and especially if not immediate) isn't an attractive > architecture. A substantial subset of SpamRep could, in theory, > operate > over a message transport protocol such as SMTP. It seems to me that SpamRep does two things: It defines a message format an= d it defines the interaction between the sender of the report (Client) and = the report receiver (Server). As a message format is transport-agnostic, o= ne could use HTTP POST to send either a SpamRep message or a MARF message. In the former case, we would simply not require the Server response when us= ed via email. That is, the protocol part of SpamRep doesn't make sense in = the email side of things but the message format part would probably be fine= . From johnl@taugh.com Mon Jul 12 10:33: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 E53743A684F for ; Mon, 12 Jul 2010 10:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.624 X-Spam-Level: X-Spam-Status: No, score=-10.624 tagged_above=-999 required=5 tests=[AWL=0.575, 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 Qy11Akyj5Iss for ; Mon, 12 Jul 2010 10:33:39 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 38A263A6B98 for ; Mon, 12 Jul 2010 10:33:21 -0700 (PDT) Received: (qmail 25989 invoked from network); 12 Jul 2010 17:28:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1007; bh=dfeXvcuo9NK4swKd6rJNZjbDlth2ldVdLysbRMeGFTo=; b=Pttq4oYDIcglmG9mAEnoeSxY1Og+jhXAx53Vicb9CWPn2EvyWS6zYfVpFf6yl3AnJ8VVYkj97/3YcLL/yuQU+Nn+SsRR6XMv2Q1EcMdiefZ1fUXnVcg2Z2iLlkpTXuzsiU4AnyTUP//g1jwqt/P38oM8qAPuqrwdew73+G5vPEI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1007; bh=dfeXvcuo9NK4swKd6rJNZjbDlth2ldVdLysbRMeGFTo=; b=NIu6F/O/BO2HJtVgyJ0P+AImYdTfIsCzXhK4EyP7wMQkteo6XdFDoYYXuC/dazZ3GwH6oo7u+AYgMbynK2PYJLCDrWFF5vOu7XCmL3nwoH3Ltalvn5tgu13lRA6P7BIecqUDV8ng5tQBZPJp7r1ilrS+86qg+M2+Ny+1YozdujY= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jul 2010 17:28:16 -0000 Date: 12 Jul 2010 13:33:27 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "marf@ietf.org" Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Mon, 12 Jul 2010 17:33:41 -0000 > In the former case, we would simply not require the Server response when used via email. That is, the protocol part of SpamRep doesn't make sense in the email side of things but the message format part would probably be fine. I could imagine a hypothetical model in which the server would mail back the responses, but it's hard to see a practical application. There's a reason all those servers we had 15 years ago to retrieve stuff by mail aren't around any more. On the other hand, a model where an MUA does a POST to send back an ARF report could work well. Most current MUAs have 90% of a web browser built in already to render HTML mail so I expect that it would not be a lot of extra programming to add. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From dotis@mail-abuse.org Mon Jul 12 11:03: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 BFD323A6A4D for ; Mon, 12 Jul 2010 11:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, 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 YacTBSWZyVnO for ; Mon, 12 Jul 2010 11:03:14 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 55EC53A6BD4 for ; Mon, 12 Jul 2010 11:03:14 -0700 (PDT) Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id EF67AA9449B for ; Mon, 12 Jul 2010 18:03:18 +0000 (UTC) Message-ID: <4C3B58E6.40104@mail-abuse.org> Date: Mon, 12 Jul 2010 11:03:18 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: marf@ietf.org References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Mon, 12 Jul 2010 18:03:16 -0000 On 7/12/10 10:33 AM, John R Levine wrote: >> In the former case, we would simply not require the Server response >> when used via email. That is, the protocol part of SpamRep doesn't >> make sense in the email side of things but the message format part >> would probably be fine. > > I could imagine a hypothetical model in which the server would mail > back the responses, but it's hard to see a practical application. > There's a reason all those servers we had 15 years ago to retrieve > stuff by mail aren't around any more. > > On the other hand, a model where an MUA does a POST to send back an > ARF report could work well. Most current MUAs have 90% of a web > browser built in already to render HTML mail so I expect that it would > not be a lot of extra programming to add. Why introduce yet another messaging system? Such protocol diversity will likely depend upon insecure automatic configurations, where this new transport would add HTTP redirection vulnerabilities, and introduce acceptance issues when session interaction is expected, such as including Captcha. From a management and security standpoint, less is more. -Doug From vesely@tana.it Mon Jul 12 11:11: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 388D93A685E for ; Mon, 12 Jul 2010 11:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, 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 6xz4gUCguAKf for ; Mon, 12 Jul 2010 11:11:26 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id D2D1E3A6BD7 for ; Mon, 12 Jul 2010 11:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1278958288; bh=KD/09ZLeafskBkASO04uSM40SPw8bfaHKQHqlscoNQc=; l=1138; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=EOpVQhesS/2VCaRnMsL7C9pGS5GaC2WNxmFZDq5TicX25jvqEgpbRliPfePh19t/L rposWOpSPnT23XvkHYSlErf5fQSi+grM5ip09oCp3sUZ5jFcKliUBQFG9JljJq/E2l soyYhzEGKHCezo8DmD7b3i1ncWyXJ+IQ7pdZCqgE= 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; Mon, 12 Jul 2010 20:11:28 +0200 id 00000000005DC02B.000000004C3B5AD0.00003BBC Message-ID: <4C3B5AD0.5090108@tana.it> Date: Mon, 12 Jul 2010 20:11:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: marf@ietf.org References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Mon, 12 Jul 2010 18:11:30 -0000 On 12/Jul/10 09:26, John R Levine wrote: >> Note that SpamRep does support Email abuse reporting over HTTP. Perhaps >> any overlap in this area should be discussed. +1 > In the ASRG, we had a robust discussion about the way one might add a > spam button to a MUA: > > http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs > > One of the open questions is how the MUA sends the report back to the > appropriate place, which in this case is similar to the SpamRep model, > the mail server from which the MUA picked up the mail. HTTP is not a bad > way to go, particularly on mobile devices where users are likely to have > both e-mail and SMS/MMS spam to report. There is a "RID Transport" [1] draft that may have parallel facets with this use of HTTP. Although that is focused on the team-to-team step rather than the user-to-team one, several considerations about, say, TLS, port numbers, and URIs may be relevant. I take this occasion to repeat that discussing any overlapping with the IODEF effort is probably worth too. -- [1] http://tools.ietf.org/html/draft-moriarty-post-inch-rid-transport From jdfalk-lists@cybernothing.org Mon Jul 12 11: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 E1CE73A69EB for ; Mon, 12 Jul 2010 11:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 t+QPQmhbyWJJ for ; Mon, 12 Jul 2010 11:33:06 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 91D083A6B33 for ; Mon, 12 Jul 2010 11:33:05 -0700 (PDT) Received: from jds-macbook.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 o6CIX8Td021140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Jul 2010 12:33:09 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o6CIX8Td021140 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1278959590; bh=ObiBxicVDp3ikTQpI/WG6u6jQJ3vo8JJH5b1+Lvmw 8Q=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=DzSeBGC7cOyLBXy5 N7iO8DzriQ8bSHIp1nKWEzPANpVLoBZD4UjeBQlmB0qsr9jLbcJlfXmhYfyWjxa2bne 9Ix3bbxVuS+NAxwOkqVO30X7HnB2lEP/ezWeqsIqrrgwwMiL6/Hve4fmbGHO494KdA/ dUd+7WWAqnArZTQdBZwnM= References: <20100712052206.2387.qmail@joyce.lan> In-Reply-To: <20100712052206.2387.qmail@joyce.lan> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <5A47C254-740A-4091-B6EE-1AD5069664A8@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Mon, 12 Jul 2010 12:33:02 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1081) Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Mon, 12 Jul 2010 18:33:09 -0000 On Jul 11, 2010, at 11:22 PM, John Levine wrote: > Given how little SMTP and SMS have in common, I'd be more inclined to > keep them separate and encourage places that can accept both to accept > them both by mail and HTTP. +1 On Jul 12, 2010, at 12:45 AM, Alex Bobotek wrote: > Note that SpamRep does support Email abuse reporting over HTTP. = Perhaps > any overlap in this area should be discussed. +1 draft-jdfalk-marf-reporting-discovery also mentions MUA submissions via = HTTP, though I kept it simple: a POST of a message/rfc822 MIME part to = the specified URI. SpamRep may be a better way to go, particularly = given the increasing availability of fully-featured MUAs on mobile = devices. -- J.D. Falk Return Path Inc From yakov@shaftek.org Mon Jul 12 17:22: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 E6AA53A6822 for ; Mon, 12 Jul 2010 17:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=0.341, 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 uwnSoHnMRANy for ; Mon, 12 Jul 2010 17:22:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 79D533A67B3 for ; Mon, 12 Jul 2010 17:22:46 -0700 (PDT) Received: by eyb7 with SMTP id 7so840789eyb.31 for ; Mon, 12 Jul 2010 17:22:50 -0700 (PDT) Received: by 10.213.15.12 with SMTP id i12mr10691236eba.55.1278980570126; Mon, 12 Jul 2010 17:22:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.127.66 with HTTP; Mon, 12 Jul 2010 17:22:30 -0700 (PDT) In-Reply-To: References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> From: Yakov Shafranovich Date: Mon, 12 Jul 2010 20:22:30 -0400 Message-ID: To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Tue, 13 Jul 2010 00:22:48 -0000 On Mon, Jul 12, 2010 at 1:22 PM, Murray S. Kucherawy wr= ote: > It seems to me that SpamRep does two things: It defines a message format = and it defines the interaction between the sender of the report (Client) an= d the report receiver (Server). =A0As a message format is transport-agnosti= c, one could use HTTP POST to send either a SpamRep message or a MARF messa= ge. > > In the former case, we would simply not require the Server response when = used via email. =A0That is, the protocol part of SpamRep doesn't make sense= in the email side of things but the message format part would probably be = fine. I think this is a good way of looking at it. There are two separate issues here - one is that of transport and second of the actual format. It may be prudent to attack them separately. The transport issue per se isn't really a big deal. We have been talking about using non-SMTP ways to route ARF reports here and there, so HTTP may be another way. I think that perhaps splitting that into a separate draft may work better. I have a bigger concern with the message format itself. The draft is defining over 15 new headers. Without knowing how SMS / MMS and mobile IM is formatted, it is very hard to shoehorn this into MARF. Additionally, within the MARF model, the lowest common denominator is the message itself - it is primae faceae evidence of the spam activity and part 2 is only included to assist people with information not otherwise available. Perhaps as a way to converge SpamRep and MARF may be to focus specifically on reporting spam email messages from mobile phones. That would be addressable via existing draft with a new transport method perhaps, and a few additional headers. The next step would be to tackle IM, perhaps via additional headers already defined for XMPP, and then SMS itself. It would also be helpful if the people on the mobile space can explain what the various headers are, what they do and why they are not being included in the original spam message. Thanks, Yakov From yigang.cai@alcatel-lucent.com Tue Jul 13 04:25: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 2C3F63A6A05 for ; Tue, 13 Jul 2010 04:25:19 -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 ax5kkPUJuplw for ; Tue, 13 Jul 2010 04:25:18 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 35B493A69D1 for ; Tue, 13 Jul 2010 04:25:18 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o6DBPOEF022066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jul 2010 06:25:24 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6DBPMFw024649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Jul 2010 06:25:24 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 13 Jul 2010 06:25:04 -0500 From: "Cai, Yigang (Yigang)" To: Yakov Shafranovich , "marf@ietf.org" Date: Tue, 13 Jul 2010 06:25:03 -0500 Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Thread-Index: AcsiIY2dDxokRT+dT3+6ChoYsFT3wQAW+HVw Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B13D14@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Tue, 13 Jul 2010 11:25:19 -0000 Yakov, I put 15 new parameters in the draft because most of them are useful info a= nd spam classification which can be detected or by canalization from SMSC/M= MSC. We can reduce number of new parameters, and only list some of common p= arameters among email, SMS/MMS, and IM. I agree with you the transport isn't big issue. But at the beginning, we ma= y define SMTP and HTTP as base. Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Yak= ov Shafranovich Sent: Monday, July 12, 2010 7:23 PM To: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" On Mon, Jul 12, 2010 at 1:22 PM, Murray S. Kucherawy wr= ote: > It seems to me that SpamRep does two things: It defines a message format = and it defines the interaction between the sender of the report (Client) an= d the report receiver (Server). =A0As a message format is transport-agnosti= c, one could use HTTP POST to send either a SpamRep message or a MARF messa= ge. > > In the former case, we would simply not require the Server response when = used via email. =A0That is, the protocol part of SpamRep doesn't make sense= in the email side of things but the message format part would probably be = fine. I think this is a good way of looking at it. There are two separate issues = here - one is that of transport and second of the actual format. It may be = prudent to attack them separately. The transport issue per se isn't really a big deal. We have been talking ab= out using non-SMTP ways to route ARF reports here and there, so HTTP may be= another way. I think that perhaps splitting that into a separate draft may= work better. I have a bigger concern with the message format itself. The draft is defini= ng over 15 new headers. Without knowing how SMS / MMS and mobile IM is form= atted, it is very hard to shoehorn this into MARF. Additionally, within the MARF model, the lowest common denominator is the m= essage itself - it is primae faceae evidence of the spam activity and part = 2 is only included to assist people with information not otherwise availabl= e. Perhaps as a way to converge SpamRep and MARF may be to focus specifically = on reporting spam email messages from mobile phones. That would be addressa= ble via existing draft with a new transport method perhaps, and a few addit= ional headers. The next step would be to tackle IM, perhaps via additional = headers already defined for XMPP, and then SMS itself. It would also be helpful if the people on the mobile space can explain what= the various headers are, what they do and why they are not being included = in the original spam message. Thanks, Yakov _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From moh.torabi@alcatel-lucent.com Tue Jul 13 07:08: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 09D843A6A0C for ; Tue, 13 Jul 2010 07:08:06 -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=[AWL=-0.001, 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 w3VkGr2WA0JL for ; Tue, 13 Jul 2010 07:07:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 170903A69E1 for ; Tue, 13 Jul 2010 07:07:57 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o6DE83AJ028116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 09:08:03 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6DE82J6007350; Tue, 13 Jul 2010 09:08:03 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 13 Jul 2010 09:07:53 -0500 From: "Torabi, Mohammad (Moh)" To: "'alex@bobotek.net'" Date: Tue, 13 Jul 2010 09:07:49 -0500 Thread-Topic: [marf] Time slot at IETF 78 Thread-Index: AcsfGe/+dLoh6LYkSP21ruOHa+ar/wAW1z5QAAEgvRAAAhZiUABITI5gAHqYHDA= Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11340690BF8@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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_6F428EFD2B8C2F49A2FB1317291A76C11340690BF8USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "'marf@ietf.org'" Subject: Re: [marf] Time slot at IETF 78 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 Jul 2010 14:08:06 -0000 --_000_6F428EFD2B8C2F49A2FB1317291A76C11340690BF8USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are two areas of work and this draft to fill some gaps in these two a= reas: OMA SpamRep, IETF MARF and this Draft proposal: 1. OMA Work Area OMA draft of "Mobile Spam Reporting Technical Specification" (OMA-TS-SpamRe= p-V1_0-20100601-D) defines spam reporting (SpamRep) messages between client= and server. It provides a capability wherein media content that is receive= d on a device can be designated, either by the user or automatically by the= SpamRep client, as Spam and a report containing information about the Spam= message is sent to a Server for further processing. Furthermore, the work = and the protocol are applicable to email, SMS, MMS and IM message spam repo= rting from end user device to/from the server. However, it does not specify= the spam reporting from a message center (email server, email gateway, SMS= C, MMSC, web portal, and other applications). This is an area that market (= operators/service providers) may be interested in. Furthermore, the OMA wor= k does not address how to carry SpamRep XML Document in existing mobile pro= tocols from mobile device to/from the server - SIP, MAP, SMPP, etc. 2. IETF Work Area IETF has produced two drafts so far on the subject: draft-ietf-marf-base-06= & draft-ietf-marf-dkim-reporting-00. draft-ietf-marf-base-06: This draft specifies an email spam reporting/feedb= ack protocol and attributes from email operator/server when discovering eit= her incoming or outgoing email suspicious. However, it does not address spa= m reporting from end user or end user device. Furthermore, it does not cove= r other message types (SMS, MMS, IM) draft-ietf-marf-dkim-reporting-00: This draft presents an extension to the = DomainKeys Identified Mail (DKIM) specifications to allow public keys for v= erification to include a reporting address to be used for reporting message= verification issues. It extends an Internet Message reporting format to be= followed when generating such reports. It also extends MARF-Base to add fe= atures required for DKIM reporting. 3. Our proposal (draft-cai-smsc-mmsc-reporting-marf-00.txt) This proposal (to IETF MARF in IETF 78) addresses one area of gap and that = is for the message centers, SMSC and MMSC spam reporting, to filter and det= ect spam messages (machine only) and report them to network spam control se= rver. This draft will be an extent to MARF's Base Draft. It defines an exte= nsible format and MIME type that may be used by SMSC or MMSC to report feed= back about received SMS and MMS with message abuses. -M -----Original Message----- From: Alex Bobotek [mailto:alex@bobotek.net] Sent: Saturday, July 10, 2010 7:49 PM To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh) Cc: marf@ietf.org Subject: RE: [marf] Time slot at IETF 78 Could someone help explain what gap in OMA SpamRep is addressed by this? Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Zeltsan, Zachary (Zachary) Sent: Friday, July 09, 2010 9:19 AM To: 'Yakov Shafranovich' Cc: Torabi, Mohammad (Moh); marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Sent on Moh's behalf... -----Original Message----- From: Torabi, Mohammad (Moh) Sent: Friday, July 09, 2010 11:26 AM To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich' Cc: marf@ietf.org Subject: RE: [marf] Time slot at IETF 78 Hi Yakov, This work is trying to address a gap that is seen in the ongoing work of IETF's MARF and OMA's SpamRep WA. The draft is submitted by individuals as is the usual procedure to follow in IETF. However, all authors/contributors are Alcatel-Lucent employees. Regards, Moh -----Original Message----- From: Zeltsan, Zachary (Zachary) Sent: Friday, July 09, 2010 8:16 AM To: 'Yakov Shafranovich' Cc: marf@ietf.org; Torabi, Mohammad (Moh) Subject: RE: [marf] Time slot at IETF 78 Yakov, Moh, who is one of the draft's co-authors, has been involved in the OMA work and is in a better position to answer questions related to the OMA effort. (I have copied this message to Moh). Zachary -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org] Sent: Thursday, July 08, 2010 11:44 PM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Zachary, Before commenting on the technical aspects, can you tell us the background for this? Is this part of the OMA or MAAWG efforts, or is this something that you are submitting privately to the IETF? What is Alcatel's role here? Thanks, Yakov On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) wrote: > Barry, > Murray, > > Could you please give us a time slot (10 minutes) at the IETF 78 for > presenting the recently-published draft An Extensible Format for SMSC/MMSC > Feedback Reports? (The draft is at > http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > > With thanks, > > Zachary Zeltsan > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf --_000_6F428EFD2B8C2F49A2FB1317291A76C11340690BF8USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are two areas of work and this draft to fill = some gaps in these two areas: OMA SpamRep, IETF MARF and this Draft proposal:

1.         = OMA Work Area

OMA draft of “Mobile Spam Reporting Technical Specification” (OMA-TS-SpamRep-V1_0-20100601-D) defines spam reportin= g (SpamRep) messages between client and server. It provides a capability wher= ein media content that is received on a device can be designated, either by the= user or automatically by the SpamRep client, as Spam and a report containing information about the Spam message is sent to a Server for further processi= ng. Furthermore, the work and the protocol are applicable to email, SMS, MMS an= d IM message spam reporting from end user device to/from the server. However, it= does not specify the spam reporting from a message center (email server, email gateway, SMSC, MMSC, web portal, and other applications). This is an area t= hat market (operators/service providers) may be interested in. Furthermore, the= OMA work does not address how to carry SpamRep XML Document in existing mobile protocols from mobile device to/from the server – SIP, MAP, SMPP, etc= .

 

2.         = IETF Work Area

IETF has produced two drafts so far on the subject:= draft-ietf-marf-base-06 & draft-ietf-marf-dkim-reporting-00.

draft-ietf-marf-base-06: This draft specifie= s an email spam reporting/feedback protocol and attributes from email operator/server when discovering either incoming or outgoing email suspicio= us. However, it does not address spam reporting from end user or end user device. Furthe= rmore, it does not cover other message types (SMS, MMS, IM)

draft-ietf-marf-dkim-reporting-00: This draf= t presents an extension to the DomainKeys Identified Mail (DKIM) specificatio= ns to allow public keys for verification to include a reporting address to be = used for reporting message verification issues. It extends an Internet Message reporting format to be followed when generating such reports. It also exten= ds MARF-Base to add features required for DKIM reporting.

 

3. Our proposal (draft-cai-smsc-mmsc-reporting-m= arf-00.txt)

This proposal (to IETF MARF in IETF 78) addresses o= ne area of gap and that is for the message centers, SMSC and MMSC spam reporti= ng, to filter and detect spam messages (machine only) and report them to network s= pam control server. This draft will be an extent to MARF’s Base Draft. It defines an extensible format and MIME type that may be used by SMSC or MMSC= to report feedback about received SMS and MMS with message abuses.

 

-M

 

-----Original Message-----
From: Alex Bobotek [mailto:alex@bobotek.net]
Sent: Saturday, July 10, 2010 7:49 PM
To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh)<= br> Cc: marf@ietf.org
Subject: RE: [marf] Time slot at IETF 78

 

Could someone help explain what gap in OMA SpamRep = is addressed by this?

 

 

Regards,

 

Alex

 

-----Original Message-----

From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of

Zeltsan, Zachary (Zachary)

Sent: Friday, July 09, 2010 9:19 AM

To: 'Yakov Shafranovich'

Cc: Torabi, Mohammad (Moh); marf@ietf.org

Subject: Re: [marf] Time slot at IETF 78=

 

Sent on Moh's behalf...

 

-----Original Message-----

From: Torabi, Mohammad (Moh)

Sent: Friday, July 09, 2010 11:26 AM

To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich= '

Cc: marf@ietf.org

Subject: RE: [marf] Time slot at IETF 78=

 

Hi Yakov,

This work is trying to address a gap that is seen i= n the ongoing work of

IETF's MARF and OMA's SpamRep WA. The draft is subm= itted by individuals

as is the usual procedure to follow in IETF. Howeve= r, all

authors/contributors are Alcatel-Lucent employees.<= o:p>

 

Regards,

 

Moh

 

-----Original Message-----

From: Zeltsan, Zachary (Zachary)

Sent: Friday, July 09, 2010 8:16 AM

To: 'Yakov Shafranovich'

Cc: marf@ietf.org; Torabi, Mohammad (Moh)

Subject: RE: [marf] Time slot at IETF 78=

 

Yakov,

 

Moh, who is one of the draft's co-authors, has been involved in the OMA

work and is in a better position to answer question= s related to the OMA

effort. (I have copied this message to Moh).

 

Zachary

 

-----Original Message-----

From: Yakov Shafranovich [mailto:yakov@shaftek.org]=

Sent: Thursday, July 08, 2010 11:44 PM

To: Zeltsan, Zachary (Zachary)

Cc: marf@ietf.org

Subject: Re: [marf] Time slot at IETF 78=

 

Zachary,

 

Before commenting on the technical aspects, can you= tell us the

background for this? Is this part of the OMA or MAA= WG efforts, or is

this something that you are submitting privately to= the IETF? What is

Alcatel's role here?

 

Thanks,

Yakov

 

On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary)

<zachary.zeltsan@alcatel-lucent.com> wrote:

> Barry,

> Murray,

> 

> Could you please give us a time slot (10 minut= es) at the IETF 78 for

> presenting the recently-published draft An Extensible Format for

SMSC/MMSC

> Feedback Reports? (The draft is at<= /p>

> http://datatracker.ietf.org/doc/draft-cai-smsc= -mmsc-reporting-marf/ ).

> 

> With thanks,

> 

> Zachary Zeltsan

> 

> ______________________________________________= _

> marf mailing list

> marf@ietf.org

> https://www.ietf.org/mailman/listinfo/marf

> 

> 

_______________________________________________

marf mailing list

marf@ietf.org

https://www.ietf.org/mailman/listinfo/marf

--_000_6F428EFD2B8C2F49A2FB1317291A76C11340690BF8USNAVSXCHMBSA_-- From yigang.cai@alcatel-lucent.com Tue Jul 13 07:40: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 9B3A43A6803 for ; Tue, 13 Jul 2010 07:40:37 -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=[AWL=0.000, 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 EFmfNCrFq15L for ; Tue, 13 Jul 2010 07:40:36 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 4EEAC3A6978 for ; Tue, 13 Jul 2010 07:40:36 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o6DEeiqR020451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 09:40:44 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6DEei1T012320; Tue, 13 Jul 2010 09:40:44 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 13 Jul 2010 09:40:44 -0500 From: "Cai, Yigang (Yigang)" To: Yakov Shafranovich , "marf@ietf.org" Date: Tue, 13 Jul 2010 09:40:42 -0500 Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Thread-Index: AcshETrdxTOIaVcaSpSutbvhCRpv7QBhcxMg Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B13E7D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Tue, 13 Jul 2010 14:40:37 -0000 Yakov, Please see my response inline. Thanks, Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Yak= ov Shafranovich Sent: Sunday, July 11, 2010 10:53 AM To: marf@ietf.org Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" This is in regards to the following draft: http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt As per emails to the list and the SpamRep documentation at the OMA, this dr= aft is trying to address the gap between MARF and the OMA SpamRep requireme= nts. One key point to note is that the MARF model is focused on feedback lo= ops between the ISP and the original email sender, while the OMA SpamRep ac= tivity is focused on the end user and their network provider. The analogous= use case in the email space is a "report spam" button for end users which = creates a report for their ISP. [Yigang] SMS/MMS abuse somehow should be covered either by OMA or MARF. OMA= SpamRep currently seems for a report from mobile device to server. MARF is= a report from a server to a server.=20 1. Section 1.2 "requirements" - this seems to repeat the main MARF draft re= quirements and seems to be different from the OMA requirements. There is no= need to repeat the MARF requirements verbatim, it may be sufficient to ref= erence them. The OMA requirements should be referenced, and some of the OMA= SpamRep requirements which cannot be solved with MARF should be addressed = explicitly here. Ideally this section should clearly state that this draft seeks to address = OMA requirements X and Y, but not Z. [Yigang] Okay, will consider to revise this section. 2. There needs to be a reference in the draft to the standard that defines = SMS/MMS message formats. This is needed in order for us to see how it diffe= rs from email. Additionally, you need to specify whether these SMS/MMS spam= report will be delivered via email. If not, this may not fall within MARF = or IETF scope of work. [Yigang] Do you need to see SMS format standards? Then, 3GPP/GSM MAP, CDMA = SMDPP, SMPP, Parley, etc., too many. But spam report can be aligned with em= ail. =20 3. As per the MARF draft, there is a specific format to be followed when de= fining fields for the registry. You need to specify which abuse type it ref= erences, whether it is included once or multiple times, and whether it is h= istorical. That format should be followed. Additionally, ABNF would not hurt. [Yigang] Once it is determined it falls within MARF scope, I can add the sp= ecific format. 4. The draft keeps referencing abuse detected by the message center. However, the OMA SpamRep requirements talk about the end user reporting spa= m. [Yigang] SMSC/MMSC and some gateway currently have different levels abuse d= etections. Therefore the reporting is bit different from the end user. 5. One of the basic principles underpinning MARF is that the data included = in section 2 of the report, should be data that cannot be otherwise derived= from the original message. Many of the fields that I see listed seem to be= ones that will be included in the original message itself. There is no nee= d to repeat them again in section 2 of the report. [Yigang] To cover SMS/MMS, we should know whether the format is exactly sam= e or not with email. Most of data cannot be included in original message if= SMS report using email format. Some field specific comments: 6. "Message ID" - in the email world, this is automatically generated in th= e headers of the MARF report itself. [Yigang] In SMS world, this is generated by SMSC, while using different SMS= protocol, the message ID will be in different parameters. 7. "Message Center ID" - in the email world the sender of the MARF report w= ould be in the headers. [Yigang] it is SMSC ID, it may or may not in SMS header depending on protoc= ol. 8. "Message Type" - MARF is specific for email, IM reporting has its own fo= rmatting. You will need to create a registry or tightly define this. Also, = is this information that would be included in the original message? [Yigang] It depends how to include original message, just text or original = headers, and depending on protocol. 9. Fields 4.4 - 4.15 - are these included in the original message? Is there= a need to repeat them in part 2? [Yigang] Depends. 10. Abuse types - is there a need for all of these? Prior discussion here s= eems to indicate that most of these are not necessary and some overlap. For= example, message flooding and DOS are the same. [Yigang] it is important when SMSC/MMSC determine abuse type. 11. Abuse detection methods - this is similar to the authentication results= header we currently discussed regarding DKIM. There needs to be a document= covering this. [Yigang] Sure. I will be happy to do it. 12. Sections 4.18-4.23 - is any of this data included in the original messa= ge? Also, are any of these currently used? [Yigang] depends. 13. Regarding feedback types - I would recommend looking at the possibility= of defining a new feedback type called "sms" or "mobile" and re-using as much as possible of existing MARF. For example, abuse keywo= rds, etc. could be specified using URIs. [Yigang] Sure. I can discuss further. Yakov _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From alex@bobotek.net Tue Jul 13 09:26:39 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 B52B83A6A43 for ; Tue, 13 Jul 2010 09:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 1DUvKAUf9yoG for ; Tue, 13 Jul 2010 09:26:36 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id 4147A3A6A4C for ; Tue, 13 Jul 2010 09:26:36 -0700 (PDT) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta13.emeryville.ca.mail.comcast.net with comcast id hR2M1e0070FhH24ADUSl3l; Tue, 13 Jul 2010 16:26:45 +0000 Received: from bobo1.bobotek.net ([71.227.197.27]) by omta08.emeryville.ca.mail.comcast.net with comcast id hUSk1e0080bxBZT8UUSk1J; Tue, 13 Jul 2010 16:26:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Tue, 13 Jul 2010 09:25:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9B13E7D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Thread-Index: AcshETrdxTOIaVcaSpSutbvhCRpv7QBhcxMgAAQgECA= References: <5710F82C0E73B04FA559560098BF95B124F9B13E7D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> From: "Alex Bobotek" To: "Cai, Yigang (Yigang)" , "Yakov Shafranovich" , Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Tue, 13 Jul 2010 16:26:39 -0000 In reference to #4 below, we should understand that OMA SpamRep was written to cover reporting of SMS from an SMSC in addition to an SMS UA. SpamRep is not limited to UA reporting. Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Cai, Yigang (Yigang) Sent: Tuesday, July 13, 2010 7:41 AM To: Yakov Shafranovich; marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Yakov, Please see my response inline. Thanks, Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Yakov Shafranovich Sent: Sunday, July 11, 2010 10:53 AM To: marf@ietf.org Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" This is in regards to the following draft: http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt As per emails to the list and the SpamRep documentation at the OMA, this draft is trying to address the gap between MARF and the OMA SpamRep requirements. One key point to note is that the MARF model is focused on feedback loops between the ISP and the original email sender, while the OMA SpamRep activity is focused on the end user and their network provider. The analogous use case in the email space is a "report spam" button for end users which creates a report for their ISP. [Yigang] SMS/MMS abuse somehow should be covered either by OMA or MARF. OMA SpamRep currently seems for a report from mobile device to server. MARF is a report from a server to a server.=20 1. Section 1.2 "requirements" - this seems to repeat the main MARF draft requirements and seems to be different from the OMA requirements. There is no need to repeat the MARF requirements verbatim, it may be sufficient to reference them. The OMA requirements should be referenced, and some of the OMA SpamRep requirements which cannot be solved with MARF should be addressed explicitly here. Ideally this section should clearly state that this draft seeks to address OMA requirements X and Y, but not Z. [Yigang] Okay, will consider to revise this section. 2. There needs to be a reference in the draft to the standard that defines SMS/MMS message formats. This is needed in order for us to see how it differs from email. Additionally, you need to specify whether these SMS/MMS spam report will be delivered via email. If not, this may not fall within MARF or IETF scope of work. [Yigang] Do you need to see SMS format standards? Then, 3GPP/GSM MAP, CDMA SMDPP, SMPP, Parley, etc., too many. But spam report can be aligned with email. =20 3. As per the MARF draft, there is a specific format to be followed when defining fields for the registry. You need to specify which abuse type it references, whether it is included once or multiple times, and whether it is historical. That format should be followed. Additionally, ABNF would not hurt. [Yigang] Once it is determined it falls within MARF scope, I can add the specific format. 4. The draft keeps referencing abuse detected by the message center. However, the OMA SpamRep requirements talk about the end user reporting spam. [Yigang] SMSC/MMSC and some gateway currently have different levels abuse detections. Therefore the reporting is bit different from the end user. 5. One of the basic principles underpinning MARF is that the data included in section 2 of the report, should be data that cannot be otherwise derived from the original message. Many of the fields that I see listed seem to be ones that will be included in the original message itself. There is no need to repeat them again in section 2 of the report. [Yigang] To cover SMS/MMS, we should know whether the format is exactly same or not with email. Most of data cannot be included in original message if SMS report using email format. Some field specific comments: 6. "Message ID" - in the email world, this is automatically generated in the headers of the MARF report itself. [Yigang] In SMS world, this is generated by SMSC, while using different SMS protocol, the message ID will be in different parameters. 7. "Message Center ID" - in the email world the sender of the MARF report would be in the headers. [Yigang] it is SMSC ID, it may or may not in SMS header depending on protocol. 8. "Message Type" - MARF is specific for email, IM reporting has its own formatting. You will need to create a registry or tightly define this. Also, is this information that would be included in the original message? [Yigang] It depends how to include original message, just text or original headers, and depending on protocol. 9. Fields 4.4 - 4.15 - are these included in the original message? Is there a need to repeat them in part 2? [Yigang] Depends. 10. Abuse types - is there a need for all of these? Prior discussion here seems to indicate that most of these are not necessary and some overlap. For example, message flooding and DOS are the same. [Yigang] it is important when SMSC/MMSC determine abuse type. 11. Abuse detection methods - this is similar to the authentication results header we currently discussed regarding DKIM. There needs to be a document covering this. [Yigang] Sure. I will be happy to do it. 12. Sections 4.18-4.23 - is any of this data included in the original message? Also, are any of these currently used? [Yigang] depends. 13. Regarding feedback types - I would recommend looking at the possibility of defining a new feedback type called "sms" or "mobile" and re-using as much as possible of existing MARF. For example, abuse keywords, etc. could be specified using URIs. [Yigang] Sure. I can discuss further. Yakov _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From msk@cloudmark.com Tue Jul 13 10:32:10 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 D208B3A69A2 for ; Tue, 13 Jul 2010 10:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.712 X-Spam-Level: X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, GB_I_LETTER=-2, 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 7dMKwYRG4UyM for ; Tue, 13 Jul 2010 10:31:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id CAF653A6902 for ; Tue, 13 Jul 2010 10:31:57 -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 Jul 2010 10:32:06 -0700 From: "Murray S. Kucherawy" To: "Torabi, Mohammad (Moh)" , "'alex@bobotek.net'" Date: Tue, 13 Jul 2010 10:32:06 -0700 Thread-Topic: [marf] Time slot at IETF 78 Thread-Index: AcsfGe/+dLoh6LYkSP21ruOHa+ar/wAW1z5QAAEgvRAAAhZiUABITI5gAHqYHDAACFEJwA== Message-ID: References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11340690BF8@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C11340690BF8@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> 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_BB012BD379D7B046ABE1472D8093C61C01F68809FFEXCHC2corpclo_" MIME-Version: 1.0 Cc: "'marf@ietf.org'" Subject: Re: [marf] Time slot at IETF 78 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 Jul 2010 17:32:10 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01F68809FFEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Mohammad, I disagree with the first argument presented in (1) below. SpamRep defines= the format for reporting from a SpamRep Client to a SpamRep Server. It do= esn't stipulate what specific devices those are. There's nothing in SpamRe= p that stipulates, for example, that a SpamRep Client could not be an email= server, email gateway, SMSC, MMSC, web portal, or any other application. = It simply names the two roles for the purposes of specifying what to send a= nd expect in the same way RFC5321 says the client uses four-letter verbs as= commands and the server uses three-digit numbers as replies. Transport is a separate issue. SpamRep mandates use of HTTP POST as its tr= ansport, which seems to be a reasonable first approach especially since the= payload will usually be large and the usable space of an SMPP message is r= ather small. That said, one could propose a supplemental transport mechani= sm that deals with fragmentation and reassembly of a SpamRep report into pi= eces that fit inside a batch of SMPP messages. This is a whole other work = area though, and one could argue that it "belongs" to OMA and not IETF. Given the scope you're attempting to cover in (3) below, perhaps a faster r= oute forward would be to make a draft that updates draft-ietf-marf-base to = permit the third MIME part to be of the MIME type defined by SpamRep. That= MIME type already covers the ability to report on SMS and MMS spam, and wo= uld use MARF (and thus email) as the transport. It seems to me that would = cover all of your requirements except for the transport one discussed above= . -MSK From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Tor= abi, Mohammad (Moh) Sent: Tuesday, July 13, 2010 7:08 AM To: 'alex@bobotek.net' Cc: 'marf@ietf.org' Subject: Re: [marf] Time slot at IETF 78 There are two areas of work and this draft to fill some gaps in these two a= reas: OMA SpamRep, IETF MARF and this Draft proposal: 1. OMA Work Area OMA draft of "Mobile Spam Reporting Technical Specification" (OMA-TS-SpamRe= p-V1_0-20100601-D) defines spam reporting (SpamRep) messages between client= and server. It provides a capability wherein media content that is receive= d on a device can be designated, either by the user or automatically by the= SpamRep client, as Spam and a report containing information about the Spam= message is sent to a Server for further processing. Furthermore, the work = and the protocol are applicable to email, SMS, MMS and IM message spam repo= rting from end user device to/from the server. However, it does not specify= the spam reporting from a message center (email server, email gateway, SMS= C, MMSC, web portal, and other applications). This is an area that market (= operators/service providers) may be interested in. Furthermore, the OMA wor= k does not address how to carry SpamRep XML Document in existing mobile pro= tocols from mobile device to/from the server - SIP, MAP, SMPP, etc. 2. IETF Work Area IETF has produced two drafts so far on the subject: draft-ietf-marf-base-06= & draft-ietf-marf-dkim-reporting-00. draft-ietf-marf-base-06: This draft specifies an email spam reporting/feedb= ack protocol and attributes from email operator/server when discovering eit= her incoming or outgoing email suspicious. However, it does not address spa= m reporting from end user or end user device. Furthermore, it does not cove= r other message types (SMS, MMS, IM) draft-ietf-marf-dkim-reporting-00: This draft presents an extension to the = DomainKeys Identified Mail (DKIM) specifications to allow public keys for v= erification to include a reporting address to be used for reporting message= verification issues. It extends an Internet Message reporting format to be= followed when generating such reports. It also extends MARF-Base to add fe= atures required for DKIM reporting. 3. Our proposal (draft-cai-smsc-mmsc-reporting-marf-00.txt) This proposal (to IETF MARF in IETF 78) addresses one area of gap and that = is for the message centers, SMSC and MMSC spam reporting, to filter and det= ect spam messages (machine only) and report them to network spam control se= rver. This draft will be an extent to MARF's Base Draft. It defines an exte= nsible format and MIME type that may be used by SMSC or MMSC to report feed= back about received SMS and MMS with message abuses. -M -----Original Message----- From: Alex Bobotek [mailto:alex@bobotek.net] Sent: Saturday, July 10, 2010 7:49 PM To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh) Cc: marf@ietf.org Subject: RE: [marf] Time slot at IETF 78 Could someone help explain what gap in OMA SpamRep is addressed by this? Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Zeltsan, Zachary (Zachary) Sent: Friday, July 09, 2010 9:19 AM To: 'Yakov Shafranovich' Cc: Torabi, Mohammad (Moh); marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Sent on Moh's behalf... -----Original Message----- From: Torabi, Mohammad (Moh) Sent: Friday, July 09, 2010 11:26 AM To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich' Cc: marf@ietf.org Subject: RE: [marf] Time slot at IETF 78 Hi Yakov, This work is trying to address a gap that is seen in the ongoing work of IETF's MARF and OMA's SpamRep WA. The draft is submitted by individuals as is the usual procedure to follow in IETF. However, all authors/contributors are Alcatel-Lucent employees. Regards, Moh -----Original Message----- From: Zeltsan, Zachary (Zachary) Sent: Friday, July 09, 2010 8:16 AM To: 'Yakov Shafranovich' Cc: marf@ietf.org; Torabi, Mohammad (Moh) Subject: RE: [marf] Time slot at IETF 78 Yakov, Moh, who is one of the draft's co-authors, has been involved in the OMA work and is in a better position to answer questions related to the OMA effort. (I have copied this message to Moh). Zachary -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org] Sent: Thursday, July 08, 2010 11:44 PM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Zachary, Before commenting on the technical aspects, can you tell us the background for this? Is this part of the OMA or MAAWG efforts, or is this something that you are submitting privately to the IETF? What is Alcatel's role here? Thanks, Yakov On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) wrote: > Barry, > Murray, > > Could you please give us a time slot (10 minutes) at the IETF 78 for > presenting the recently-published draft An Extensible Format for SMSC/MMSC > Feedback Reports? (The draft is at > http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > > With thanks, > > Zachary Zeltsan > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf --_000_BB012BD379D7B046ABE1472D8093C61C01F68809FFEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Mohammad,

 =

I disagree with the firs= t argument presented in (1) below.  SpamRep defines the format for reporting from= a SpamRep Client to a SpamRep Server.  It doesn’t stipulate what specific devices those are.  There’s nothing in SpamRep that stipulates, for example, that a SpamRep Client could not be an email server= , email gateway, SMSC, MMSC, web portal, or any other application.  It simply names the two roles for the purposes of specifying what to send and expect in the same way RFC5321 says the client uses four-letter verbs as commands and the server uses three-digit numbers as replies.

 =

Transport is a separate issue.  SpamRep mandates use of HTTP POST as its transport, which seem= s to be a reasonable first approach especially since the payload will usually be large and the usable space of an SMPP message is rather small.  That s= aid, one could propose a supplemental transport mechanism that deals with fragmentation and reassembly of a SpamRep report into pieces that fit insid= e a batch of SMPP messages.  This is a whole other work area though, and o= ne could argue that it “belongs” to OMA and not IETF.

 =

Given the scope you̵= 7;re attempting to cover in (3) below, perhaps a faster route forward would be t= o make a draft that updates draft-ietf-marf-base to permit the third MIME par= t to be of the MIME type defined by SpamRep.  That MIME type already covers= the ability to report on SMS and MMS spam, and would use MARF (and thus email) = as the transport.  It seems to me that would cover all of your requiremen= ts except for the transport one discussed above.

 =

-MSK

 =

 =

From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of To= rabi, Mohammad (Moh)
Sent: Tuesday, July 13, 2010 7:08 AM
To: 'alex@bobotek.net'
Cc: 'marf@ietf.org'
Subject: Re: [marf] Time slot at IETF 78

 

There are two areas of work and this draft to fill = some gaps in these two areas: OMA SpamRep, IETF MARF and this Draft proposal:

1.         = OMA Work Area

OMA draft of “Mobile Spam Reporting Technical Specification” (OMA-TS-SpamRep-V1_0-20100601-D) defines spam reportin= g (SpamRep) messages between client and server. It provides a capability wher= ein media content that is received on a device can be designated, either by the user or automatically by the SpamRep client, as Spam and a report containin= g information about the Spam message is sent to a Server for further processi= ng. Furthermore, the work and the protocol are applicable to email, SMS, MMS an= d IM message spam reporting from end user device to/from the server. However, it does not specify the spam reporting from a message center (email server, em= ail gateway, SMSC, MMSC, web portal, and other applications). This is an area t= hat market (operators/service providers) may be interested in. Furthermore, the= OMA work does not address how to carry SpamRep XML Document in existing mobile protocols from mobile device to/from the server – SIP, MAP, SMPP, etc= .

 

2.         = IETF Work Area

IETF has produced two drafts so far on the subject: draft-ietf-marf-base-06 & draft-ietf-marf-dkim-reporting-00.=

draft-ietf-marf-base-06: This draft specifie= s an email spam reporting/feedback protocol and attributes from email operator/server when discovering either incoming or outgoing email suspicio= us. However, it does not address spam reporting from end user or end user devic= e. Furthermore, it does not cover other message types (SMS, MMS, IM)

draft-ietf-marf-dkim-reporting-00: This draf= t presents an extension to the DomainKeys Identified Mail (DKIM) specificatio= ns to allow public keys for verification to include a reporting address to be = used for reporting message verification issues. It extends an Internet Message reporting format to be followed when generating such reports. It also exten= ds MARF-Base to add features required for DKIM reporting.

 

3. Our proposal (draft-cai-smsc-mmsc-reporting-m= arf-00.txt)

This proposal (to IETF MARF in IETF 78) addresses o= ne area of gap and that is for the message centers, SMSC and MMSC spam reporti= ng, to filter and detect spam messages (machine only) and report them to networ= k spam control server. This draft will be an extent to MARF’s Base Draf= t. It defines an extensible format and MIME type that may be used by SMSC or M= MSC to report feedback about received SMS and MMS with message abuses.<= /p>

 

-M

 

-----Original Message-----
From: Alex Bobotek [mailto:alex@bobotek.net]
Sent: Saturday, July 10, 2010 7:49 PM
To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh)<= br> Cc: marf@ietf.org
Subject: RE: [marf] Time slot at IETF 78

 

Could someone help explain what gap in OMA SpamRep = is addressed by this?

 

 

Regards,

 

Alex

 

-----Original Message-----

From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of

Zeltsan, Zachary (Zachary)

Sent: Friday, July 09, 2010 9:19 AM

To: 'Yakov Shafranovich'

Cc: Torabi, Mohammad (Moh); marf@ietf.org

Subject: Re: [marf] Time slot at IETF 78=

 

Sent on Moh's behalf...

 

-----Original Message-----

From: Torabi, Mohammad (Moh)

Sent: Friday, July 09, 2010 11:26 AM

To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich= '

Cc: marf@ietf.org

Subject: RE: [marf] Time slot at IETF 78=

 

Hi Yakov,

This work is trying to address a gap that is seen i= n the ongoing work of

IETF's MARF and OMA's SpamRep WA. The draft is subm= itted by individuals

as is the usual procedure to follow in IETF. Howeve= r, all

authors/contributors are Alcatel-Lucent employees.<= o:p>

 

Regards,

 

Moh

 

-----Original Message-----

From: Zeltsan, Zachary (Zachary)

Sent: Friday, July 09, 2010 8:16 AM

To: 'Yakov Shafranovich'

Cc: marf@ietf.org; Torabi, Mohammad (Moh)

Subject: RE: [marf] Time slot at IETF 78=

 

Yakov,

 

Moh, who is one of the draft's co-authors, has been involved in the OMA

work and is in a better position to answer question= s related to the OMA

effort. (I have copied this message to Moh).

 

Zachary

 

-----Original Message-----

From: Yakov Shafranovich [mailto:yakov@shaftek.org]=

Sent: Thursday, July 08, 2010 11:44 PM

To: Zeltsan, Zachary (Zachary)

Cc: marf@ietf.org

Subject: Re: [marf] Time slot at IETF 78=

 

Zachary,

 

Before commenting on the technical aspects, can you= tell us the

background for this? Is this part of the OMA or MAA= WG efforts, or is

this something that you are submitting privately to= the IETF? What is

Alcatel's role here?

 

Thanks,

Yakov

 

On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary)

<zachary.zeltsan@alcatel-lucent.com> wrote:

> Barry,

> Murray,

> 

> Could you please give us a time slot (10 minut= es) at the IETF 78 for

> presenting the recently-published draft An Extensible Format for

SMSC/MMSC

> Feedback Reports? (The draft is at<= /p>

> http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ).=

> 

> With thanks,

> 

> Zachary Zeltsan

> 

> ______________________________________________= _

> marf mailing list

> marf@ietf.org

> https://www.ietf.org/mailman/listinfo/marf

> 

> 

_______________________________________________

marf mailing list

marf@ietf.org

https://www.ietf.org/mailman/listinfo/marf

--_000_BB012BD379D7B046ABE1472D8093C61C01F68809FFEXCHC2corpclo_-- From vesely@tana.it Tue Jul 13 10:50: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 86D193A69A5 for ; Tue, 13 Jul 2010 10:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, 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 DGRr7GTOKI59 for ; Tue, 13 Jul 2010 10:50:46 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 9E2393A6848 for ; Tue, 13 Jul 2010 10:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1279043454; bh=NqtFz0B4Ep7y2fETVX0AnFAeOf6RCSViSb5q2I9YcdE=; l=1824; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=j/AieGz0GdK9Qn68n1qGbosC3LYYO4h12SJUXUMYBNPMFVvFcUa+aRnmPOSweOW1o aZqNmsW/dBP8Bt1Fmk/oPBJ/oACTEPwIWlM4/ooYm7c13HFJJfg45+d/bKo8UQNMPH 6LccfvdF0/ht2DvsvPldX21k4CUQ7ZSV63YR3w8U= 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 Jul 2010 19:50:54 +0200 id 00000000005DC041.000000004C3CA77E.00001F29 Message-ID: <4C3CA77E.4060504@tana.it> Date: Tue, 13 Jul 2010 19:50:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "marf@ietf.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [marf] The case of forwarding spam reports to 3rd parties, in reporting-discovery 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 Jul 2010 17:50:51 -0000 J.D. has committed the additions I proposed to his [DRAFT], which, among other things, discourage forwarding abuse reports to 3rd parties. However, that recommendation does not match with items #3 "Connection provider" and #4 "Reputation tracker" in the report flow depicted in [AR]. How come? My understanding is that MARF, and the [DRAFT] in particular, focus on /tractable/ spam. That is, cases where a responsible party is readily identifiable and willing to cooperate. In such circumstance, it may make sense to drop any interest on how opt-in practices had been carried out, and instruct an informal process that will cure the issue at hand. Forwarding to the connection provider is more akin to reporting network incidents. It suits botnets and other "intractable" spammers, and may be better dealt with using IODEF-style reporting. Whatever the style, the current [DRAFT] wording is that "feedback generators SHOULD NOT send reports to ADMDs that are not responsible for the reported message", thus it would be enough to hold that a carrier /is/ in some sense responsible for the message transmission. Reputation trackers are needed to avoid that cooperative senders actually become opt-out operators with licence to spam. This topic is not yet well understood --at least by me. However, feedback is a fundamental ingredient of any reputation systems, so preventing it is not a good idea. However, there is no equivalent of the WHOIS LIR assignments databases in order to ascertain the involvement of a reputation tracker. How are we going to make up for that? -- [DRAFT] http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery [AR] http://wiki.asrg.sp.am/wiki/Abuse_Reporting#The_Feedback_Loop_.28FBL.29_and_other_usage_of_abuse_reports From yakov@shaftek.org Tue Jul 13 16:16: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 DC37F3A6A0D for ; Tue, 13 Jul 2010 16:16:25 -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=1.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] 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 cwRXmi4Og79C for ; Tue, 13 Jul 2010 16:16:24 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 55B453A69EF for ; Tue, 13 Jul 2010 16:16:24 -0700 (PDT) Received: by ewy22 with SMTP id 22so1502094ewy.31 for ; Tue, 13 Jul 2010 16:16:30 -0700 (PDT) Received: by 10.213.27.68 with SMTP id h4mr11940573ebc.4.1279062986260; Tue, 13 Jul 2010 16:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.127.66 with HTTP; Tue, 13 Jul 2010 16:15:47 -0700 (PDT) In-Reply-To: References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11340690BF8@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> From: Yakov Shafranovich Date: Tue, 13 Jul 2010 19:15:47 -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] Time slot at IETF 78 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 Jul 2010 23:16:26 -0000 What is the MIME type defined by SpamRep? On Tue, Jul 13, 2010 at 1:32 PM, Murray S. Kucherawy wr= ote: > Hello Mohammad, > > > > I disagree with the first argument presented in (1) below.=A0 SpamRep def= ines > the format for reporting from a SpamRep Client to a SpamRep Server.=A0 It > doesn=92t stipulate what specific devices those are.=A0 There=92s nothing= in > SpamRep that stipulates, for example, that a SpamRep Client could not be = an > email server, email gateway, SMSC, MMSC, web portal, or any other > application.=A0 It simply names the two roles for the purposes of specify= ing > what to send and expect in the same way RFC5321 says the client uses > four-letter verbs as commands and the server uses three-digit numbers as > replies. > > > > Transport is a separate issue.=A0 SpamRep mandates use of HTTP POST as it= s > transport, which seems to be a reasonable first approach especially since > the payload will usually be large and the usable space of an SMPP message= is > rather small.=A0 That said, one could propose a supplemental transport > mechanism that deals with fragmentation and reassembly of a SpamRep repor= t > into pieces that fit inside a batch of SMPP messages.=A0 This is a whole = other > work area though, and one could argue that it =93belongs=94 to OMA and no= t IETF. > > > > Given the scope you=92re attempting to cover in (3) below, perhaps a fast= er > route forward would be to make a draft that updates draft-ietf-marf-base = to > permit the third MIME part to be of the MIME type defined by SpamRep.=A0 = That > MIME type already covers the ability to report on SMS and MMS spam, and > would use MARF (and thus email) as the transport.=A0 It seems to me that = would > cover all of your requirements except for the transport one discussed abo= ve. > > > > -MSK > > > > > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Torabi, Mohammad (Moh) > Sent: Tuesday, July 13, 2010 7:08 AM > To: 'alex@bobotek.net' > Cc: 'marf@ietf.org' > Subject: Re: [marf] Time slot at IETF 78 > > > > There are two areas of work and this draft to fill some gaps in these two > areas: OMA SpamRep, IETF MARF and this Draft proposal: > > 1.=A0=A0=A0=A0=A0=A0=A0=A0 OMA Work Area > > OMA draft of =93Mobile Spam Reporting Technical Specification=94 > (OMA-TS-SpamRep-V1_0-20100601-D) defines spam reporting (SpamRep) message= s > between client and server. It provides a capability wherein media content > that is received on a device can be designated, either by the user or > automatically by the SpamRep client, as Spam and a report containing > information about the Spam message is sent to a Server for further > processing. Furthermore, the work and the protocol are applicable to emai= l, > SMS, MMS and IM message spam reporting from end user device to/from the > server. However, it does not specify the spam reporting from a message > center (email server, email gateway, SMSC, MMSC, web portal, and other > applications). This is an area that market (operators/service providers) = may > be interested in. Furthermore, the OMA work does not address how to carry > SpamRep XML Document in existing mobile protocols from mobile device to/f= rom > the server =96 SIP, MAP, SMPP, etc. > > > > 2.=A0=A0=A0=A0=A0=A0=A0=A0 IETF Work Area > > IETF has produced two drafts so far on the subject: draft-ietf-marf-base-= 06 > & draft-ietf-marf-dkim-reporting-00. > > draft-ietf-marf-base-06: This draft specifies an email spam > reporting/feedback protocol and attributes from email operator/server whe= n > discovering either incoming or outgoing email suspicious. However, it doe= s > not address spam reporting from end user or end user device. Furthermore,= it > does not cover other message types (SMS, MMS, IM) > > draft-ietf-marf-dkim-reporting-00: This draft presents an extension to th= e > DomainKeys Identified Mail (DKIM) specifications to allow public keys for > verification to include a reporting address to be used for reporting mess= age > verification issues. It extends an Internet Message reporting format to b= e > followed when generating such reports. It also extends MARF-Base to add > features required for DKIM reporting. > > > > 3. Our proposal (draft-cai-smsc-mmsc-reporting-marf-00.txt) > > This proposal (to IETF MARF in IETF 78) addresses one area of gap and tha= t > is for the message centers, SMSC and MMSC spam reporting, to filter and > detect spam messages (machine only) and report them to network spam contr= ol > server. This draft will be an extent to MARF=92s Base Draft. It defines a= n > extensible format and MIME type that may be used by SMSC or MMSC to repor= t > feedback about received SMS and MMS with message abuses. > > > > -M > > > > -----Original Message----- > From: Alex Bobotek [mailto:alex@bobotek.net] > Sent: Saturday, July 10, 2010 7:49 PM > To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh= ) > Cc: marf@ietf.org > Subject: RE: [marf] Time slot at IETF 78 > > > > Could someone help explain what gap in OMA SpamRep is addressed by this? > > > > > > Regards, > > > > Alex > > > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Zeltsan, Zachary (Zachary) > > Sent: Friday, July 09, 2010 9:19 AM > > To: 'Yakov Shafranovich' > > Cc: Torabi, Mohammad (Moh); marf@ietf.org > > Subject: Re: [marf] Time slot at IETF 78 > > > > Sent on Moh's behalf... > > > > -----Original Message----- > > From: Torabi, Mohammad (Moh) > > Sent: Friday, July 09, 2010 11:26 AM > > To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich' > > Cc: marf@ietf.org > > Subject: RE: [marf] Time slot at IETF 78 > > > > Hi Yakov, > > This work is trying to address a gap that is seen in the ongoing work of > > IETF's MARF and OMA's SpamRep WA. The draft is submitted by individuals > > as is the usual procedure to follow in IETF. However, all > > authors/contributors are Alcatel-Lucent employees. > > > > Regards, > > > > Moh > > > > -----Original Message----- > > From: Zeltsan, Zachary (Zachary) > > Sent: Friday, July 09, 2010 8:16 AM > > To: 'Yakov Shafranovich' > > Cc: marf@ietf.org; Torabi, Mohammad (Moh) > > Subject: RE: [marf] Time slot at IETF 78 > > > > Yakov, > > > > Moh, who is one of the draft's co-authors, has been involved in the OMA > > work and is in a better position to answer questions related to the OMA > > effort. (I have copied this message to Moh). > > > > Zachary > > > > -----Original Message----- > > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > > Sent: Thursday, July 08, 2010 11:44 PM > > To: Zeltsan, Zachary (Zachary) > > Cc: marf@ietf.org > > Subject: Re: [marf] Time slot at IETF 78 > > > > Zachary, > > > > Before commenting on the technical aspects, can you tell us the > > background for this? Is this part of the OMA or MAAWG efforts, or is > > this something that you are submitting privately to the IETF? What is > > Alcatel's role here? > > > > Thanks, > > Yakov > > > > On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) > > wrote: > >> Barry, > >> Murray, > >> > >> Could you please give us a time slot (10 minutes) at the IETF 78 for > >> presenting the recently-published draft An Extensible Format for > > SMSC/MMSC > >> Feedback Reports? (The draft is at > >> http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > >> > >> With thanks, > >> > >> Zachary Zeltsan > >> > >> _______________________________________________ > >> marf mailing list > >> marf@ietf.org > >> https://www.ietf.org/mailman/listinfo/marf > >> > >> > > _______________________________________________ > > marf mailing list > > marf@ietf.org > > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > From msk@cloudmark.com Tue Jul 13 22:41: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 5FA313A680A for ; Tue, 13 Jul 2010 22:41:47 -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.199, 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 KDTUggQT0Dsk for ; Tue, 13 Jul 2010 22:41:45 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id D04023A6829 for ; Tue, 13 Jul 2010 22:41:45 -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 Jul 2010 22:41:55 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich Date: Tue, 13 Jul 2010 22:41:54 -0700 Thread-Topic: [marf] Time slot at IETF 78 Thread-Index: Acsi4W471E1GeXMkTTa5Kp0KKUJGcAANOxHa Message-ID: References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11340690BF8@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> , 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] Time slot at IETF 78 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, 14 Jul 2010 05:41:47 -0000 "application/vnd.oma.spamrep+xml". There are no I-Ds for it yet, but I bel= ieve the current technical specifications that define it are public: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/P= ermanent_documents/OMA-TS-SpamRep-V1_0-20100708-D.zip ________________________________________ From: Yakov Shafranovich [yakov@shaftek.org] Sent: Tuesday, July 13, 2010 4:15 PM To: Murray S. Kucherawy Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 What is the MIME type defined by SpamRep? From yigang.cai@alcatel-lucent.com Fri Jul 16 13:08: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 73C863A6A81 for ; Fri, 16 Jul 2010 13:08:09 -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 6A+D-A0tUlYh for ; Fri, 16 Jul 2010 13:08:04 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 73E9A3A6B46 for ; Fri, 16 Jul 2010 13:08:00 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o6GK8BrY003978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 15:08:12 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6GK8Ajm020961; Fri, 16 Jul 2010 15:08:11 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 16 Jul 2010 15:08:10 -0500 From: "Cai, Yigang (Yigang)" To: Yakov Shafranovich , "marf@ietf.org" Date: Fri, 16 Jul 2010 15:08:08 -0500 Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Thread-Index: AcshLZ/L/Q87KMcqTo2FEtToPGC9/AD9KqhA Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B71CEA@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <001f01cb2120$2d2fab80$878f0280$@com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Fri, 16 Jul 2010 20:08:09 -0000 All, Considering standards and practice already allow SMS to carry email and IM,= it is better to have a converged report format with multiple transport met= hods supported. Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Yak= ov Shafranovich Sent: Sunday, July 11, 2010 2:16 PM To: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" 1. Thanks. 2. As of now, the intention of MARF is to be exchanged via email only. It is a "son of" RFC 3462 which is "multipart/report" for administrative me= ssages regarding email. Of course, other transport methods could be defined= in the future. Yakov On Sun, Jul 11, 2010 at 1:40 PM, Wenjun (Kevin) Zeng wro= te: > Hi Yakov and all, > > A couple of clarifications. > > 1. Although OMA SpamRep was originally motivated by feedback loop=20 > between the end user and their network provider, the actual=20 > specification only specifies two logical entities, i.e., a SpamRep=20 > server and a SpamRep client where the client could be UA, MTA, SMSC=20 > etc. > > 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF=20 > restricted to email delivery of report only? > > Thanks. > > -Kevin > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf=20 > Of Yakov Shafranovich > Sent: Sunday, July 11, 2010 10:53 AM > To: marf@ietf.org > Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" > > This is in regards to the following draft: > > http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt > > As per emails to the list and the SpamRep documentation at the OMA,=20 > this draft is trying to address the gap between MARF and the OMA=20 > SpamRep requirements. One key point to note is that the MARF model is=20 > focused on feedback loops between the ISP and the original email=20 > sender, while the OMA SpamRep activity is focused on the end user and=20 > their network provider. The analogous use case in the email space is a=20 > "report spam" button for end users which creates a report for their=20 > ISP. > > 1. Section 1.2 "requirements" - this seems to repeat the main MARF=20 > draft requirements and seems to be different from the OMA=20 > requirements. There is no need to repeat the MARF requirements=20 > verbatim, it may be sufficient to reference them. The OMA requirements=20 > should be referenced, and some of the OMA SpamRep requirements which=20 > cannot be solved with MARF should be addressed explicitly here. > Ideally this section should clearly state that this draft seeks to=20 > address OMA requirements X and Y, but not Z. > > 2. There needs to be a reference in the draft to the standard that=20 > defines SMS/MMS message formats. This is needed in order for us to see=20 > how it differs from email. Additionally, you need to specify whether=20 > these SMS/MMS spam report will be delivered via email. If not, this=20 > may not fall within MARF or IETF scope of work. > > 3. As per the MARF draft, there is a specific format to be followed=20 > when defining fields for the registry. You need to specify which abuse=20 > type it references, whether it is included once or multiple times, and=20 > whether it is historical. That format should be followed. > Additionally, ABNF would not hurt. > > 4. The draft keeps referencing abuse detected by the message center. > However, the OMA SpamRep requirements talk about the end user=20 > reporting spam. > > 5. One of the basic principles underpinning MARF is that the data=20 > included in section 2 of the report, should be data that cannot be=20 > otherwise derived from the original message. Many of the fields that I=20 > see listed seem to be ones that will be included in the original=20 > message itself. There is no need to repeat them again in section 2 of=20 > the report. > > Some field specific comments: > 6. "Message ID" - in the email world, this is automatically generated=20 > in the headers of the MARF report itself. > 7. "Message Center ID" - in the email world the sender of the MARF=20 > report would be in the headers. > 8. "Message Type" - MARF is specific for email, IM reporting has its=20 > own formatting. You will need to create a registry or tightly define=20 > this. Also, is this information that would be included in the original=20 > message? > 9. Fields 4.4 - 4.15 - are these included in the original message? Is=20 > there a need to repeat them in part 2? > 10. Abuse types - is there a need for all of these? Prior discussion=20 > here seems to indicate that most of these are not necessary and some=20 > overlap. For example, message flooding and DOS are the same. > 11. Abuse detection methods - this is similar to the authentication=20 > results header we currently discussed regarding DKIM. There needs to=20 > be a document covering this. > 12. Sections 4.18-4.23 - is any of this data included in the original=20 > message? Also, are any of these currently used? > 13. Regarding feedback types - I would recommend looking at the=20 > possibility of defining a new feedback type called "sms" or "mobile" > and re-using as much as possible of existing MARF. For example, abuse=20 > keywords, etc. could be specified using URIs. > > Yakov > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yigang.cai@alcatel-lucent.com Fri Jul 16 13:18:52 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 3501D3A6B3B for ; Fri, 16 Jul 2010 13:18:52 -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=[AWL=0.000, 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 PzEWb4gdXBxl for ; Fri, 16 Jul 2010 13:18:50 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 9F2823A680F for ; Fri, 16 Jul 2010 13:18:50 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o6GKIuSe026591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 15:18:57 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6GKIr8p030266; Fri, 16 Jul 2010 15:18:56 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 16 Jul 2010 15:18:46 -0500 From: "Cai, Yigang (Yigang)" To: Alex Bobotek , "Murray S. Kucherawy" , "Zeltsan, Zachary (Zachary)" , "marf@ietf.org" Date: Fri, 16 Jul 2010 15:18:45 -0500 Thread-Topic: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 Thread-Index: AcscRGjg1uHn6/O0T/+tybWI2qMghAAARjXAACOb5oAAADtHMAITtGHw Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B71CF9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Fri, 16 Jul 2010 20:18:52 -0000 Alex, >>it is challenging to provide a uniform abuse report format which is usefu= l at all points in the message flow. I agree with your point. But we should work in this direction. >>However, IMHO an abuse-reporting format can be made flexible enough to ac= commodate all of these cases by incorporating a sufficient number of option= al parameters. That is one of my purposes in the draft. BTW, could you advise me what is I= MHO? Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Ale= x Bobotek Sent: Tuesday, July 06, 2010 2:16 AM To: Murray S. Kucherawy; Zeltsan, Zachary (Zachary); marf@ietf.org Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-re= porting-marf-00 I think it would make a lot of sense for OMA SpamRep and IETF MARF to eithe= r converge on SMS/MMS, or clearly identify reasons why they should be kept = separate. =20 There seems to be difference in scope. SpamRep is intended to support SMS/= MMS feedback from both device-based applications such as user agents (e.g.,= 'this is spam' buttons in phones), and network nodes such as SMSCs inside = carrier networks. This is significantly different from the scope defined (= or at least alluded to) in the introduction to draft-cai-smsc-mmsc-reporting-marf-00: receiving reports from SMSCs and MMS= Cs. One of the challenges I faced in drafting the SMS portion of the OMA s= pec is accommodating the SMS gateway functions (e.g., OTA-->GSM MAP, GSM MA= P-->SMPP) that transform a message as it passes through a network and is fi= nally stored in a device in an implementation-dependent format; it is chall= enging to provide a uniform abuse report format which is useful at all poin= ts in the message flow. However, IMHO an abuse-reporting format can be mad= e flexible enough to accommodate all of these cases by incorporating a suff= icient number of optional parameters. The SpamRep v1.0 specification is now largely complete, with consistency re= view coming in the near future. So comments are welcome. While only OMA m= ember companies may submit change requests, many member companies are recep= tive to input from individuals and non-members. =20 Draft OMA SpamRep specs are available at: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/Permanent_documents/, including the latest 6/24/2010 draft. =20 Change requests (the vehicle by which the draft spec is modified) are at: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/2010/=20 Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Monday, July 05, 2010 11:26 PM To: Zeltsan, Zachary (Zachary); 'marf@ietf.org' Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-re= porting-marf-00 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Zeltsan, Zachary (Zachary) > Sent: Monday, July 05, 2010 6:32 AM > To: 'marf@ietf.org' > Subject: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-=20 > reporting-marf-00 >=20 > Please review this new draft > http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt >=20 > Zachary Hi Zachary, The MARF working group is chartered to keep its work in parallel with what = the Open Mobile Alliance is up to in the area of mobile spam reporting. Ar= e you familiar with their SpamRep proposal? -MSK _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yigang.cai@alcatel-lucent.com Fri Jul 16 13:44: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 C09593A65A5 for ; Fri, 16 Jul 2010 13:44:08 -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=[AWL=0.000, 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 ID4K6YM1Rw36 for ; Fri, 16 Jul 2010 13:44:06 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 2B60F3A6B36 for ; Fri, 16 Jul 2010 13:44:06 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o6GKiD2c011832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 15:44:13 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6GKiCKQ029236; Fri, 16 Jul 2010 15:44:12 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 16 Jul 2010 15:43:57 -0500 From: "Cai, Yigang (Yigang)" To: Alex Bobotek , "zengw@huawei.com" , Yakov Shafranovich , "marf@ietf.org" Date: Fri, 16 Jul 2010 15:43:56 -0500 Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers Thread-Index: AcshET9HRHPEbGZORiK4Fzt7R24z1gACxiKwAAVLWzAA/SQpMA== Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B71D0F@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <001f01cb2120$2d2fab80$878f0280$@com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers 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 Jul 2010 20:44:08 -0000 Alex, I concur with many of your points, please see my comments inserted below. Thanks, Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Ale= x Bobotek Sent: Sunday, July 11, 2010 3:19 PM To: zengw@huawei.com; Yakov Shafranovich; marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML = vs Headers I believe that a single standard for mobile reporting (OMA and/or IETF) sho= uld be our goal, and am very interested in seeing OMA and IETF develop stan= dards that do not fragment use and implementation, whether by having one or= both bodies produce applicable standard(s). [Yigang] I agree with this goal. SpamRep was motivated by a desire to provide reporting from more than end u= sers: to provide a standard format for mobile reporting. Yes, it is impor= tant to have a mobile spec that can be incorporated into phones by device m= anufacturers otherwise uninvolved in anti-abuse. However, the SMS portion = was writer to specifically support the following (and hopefully other) clas= ses of reporting: * Manual reporting from an SMS UA to a network node * Automated reporting from an SMS UA to a network node * Automated/manual reporting from an SS7 or SMPP network node such as an S= MSC * Intercarrier abuse notifications [Yigang] In current service providers networks, the gateway and/or the SMSC= already implemented spam filtering capability. It is much easier for them = to report message abuse automatically. SMS abuse reporting presents many challenges that are less prominent in ema= il, notably that there are inherently many gateways (protocol conversions) in the delivery path, and very little backtrace information (a= s in email headers).=20 [Yigang] In some networks, SMS spam could be 80-90% of total SMS received. = Since SMS is able to carry emails and IMs, some SMS spams are sourced from = email and some email spams are sourced from SMS.=20 In drafting the SMS portion of SpamRep, I found supporting multiple reporte= r classes to be a challenge, but not an impossibility. Separate specificat= ions seem to be an unnecessary and disadvantageous approach.=20 [Yigang] Fully agree with you.=20 While contributing to OMA SpamRep, OMA contributors (myself included) been = following ARF/MARF, even using it as a baseline for many initial SpamRep re= quirements and features. Two key differences between SpamRep and MARF are: * SMTP vs HTTP (at least typically) for transport [Yigang] From SMSC/MMSC point of view, SMTP and HTTP make not much differen= ce w.r.t. development and testing effort.=20 * XML vs RFC 5322 (email) style headers for report and message metadata [Yigang] I prefer we converge to one. IMO, either transport-independence (costly in that transport features such = as encryption and authentication may be leveraged) or adaptation to multipl= e transports (my preference) is desirable and entirely feasible. The key difference is that SpamRep is XML-based while thdraft-cai-smsc-mmsc= -reporting-marf-00 draft and MARF is header-based. At the root of this is that email works this way, while many other communic= ations systems use XML. Does anyone have any suggestions on how to drive c= onvergence?=20 [Yigang] I prefer to drive them to convergence. =20 Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Wen= jun (Kevin) Zeng Sent: Sunday, July 11, 2010 10:41 AM To: 'Yakov Shafranovich'; marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Hi Yakov and all, A couple of clarifications. 1. Although OMA SpamRep was originally motivated by feedback loop between t= he end user and their network provider, the actual specification only speci= fies two logical entities, i.e., a SpamRep server and a SpamRep client wher= e the client could be UA, MTA, SMSC etc. 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF restric= ted to email delivery of report only? Thanks. -Kevin -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Yak= ov Shafranovich Sent: Sunday, July 11, 2010 10:53 AM To: marf@ietf.org Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" This is in regards to the following draft: http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt As per emails to the list and the SpamRep documentation at the OMA, this dr= aft is trying to address the gap between MARF and the OMA SpamRep requireme= nts. One key point to note is that the MARF model is focused on feedback lo= ops between the ISP and the original email sender, while the OMA SpamRep ac= tivity is focused on the end user and their network provider. The analogous= use case in the email space is a "report spam" button for end users which = creates a report for their ISP. 1. Section 1.2 "requirements" - this seems to repeat the main MARF draft re= quirements and seems to be different from the OMA requirements. There is no= need to repeat the MARF requirements verbatim, it may be sufficient to ref= erence them. The OMA requirements should be referenced, and some of the OMA= SpamRep requirements which cannot be solved with MARF should be addressed = explicitly here. Ideally this section should clearly state that this draft seeks to address = OMA requirements X and Y, but not Z. 2. There needs to be a reference in the draft to the standard that defines = SMS/MMS message formats. This is needed in order for us to see how it diffe= rs from email. Additionally, you need to specify whether these SMS/MMS spam= report will be delivered via email. If not, this may not fall within MARF = or IETF scope of work. 3. As per the MARF draft, there is a specific format to be followed when de= fining fields for the registry. You need to specify which abuse type it ref= erences, whether it is included once or multiple times, and whether it is h= istorical. That format should be followed. Additionally, ABNF would not hurt. 4. The draft keeps referencing abuse detected by the message center. However, the OMA SpamRep requirements talk about the end user reporting spa= m. 5. One of the basic principles underpinning MARF is that the data included = in section 2 of the report, should be data that cannot be otherwise derived= from the original message. Many of the fields that I see listed seem to be= ones that will be included in the original message itself. There is no nee= d to repeat them again in section 2 of the report. Some field specific comments: 6. "Message ID" - in the email world, this is automatically generated in th= e headers of the MARF report itself. 7. "Message Center ID" - in the email world the sender of the MARF report w= ould be in the headers. 8. "Message Type" - MARF is specific for email, IM reporting has its own fo= rmatting. You will need to create a registry or tightly define this. Also, = is this information that would be included in the original message? 9. Fields 4.4 - 4.15 - are these included in the original message? Is there= a need to repeat them in part 2? 10. Abuse types - is there a need for all of these? Prior discussion here s= eems to indicate that most of these are not necessary and some overlap. For= example, message flooding and DOS are the same. 11. Abuse detection methods - this is similar to the authentication results= header we currently discussed regarding DKIM. There needs to be a document= covering this. 12. Sections 4.18-4.23 - is any of this data included in the original messa= ge? Also, are any of these currently used? 13. Regarding feedback types - I would recommend looking at the possibility= of defining a new feedback type called "sms" or "mobile" and re-using as much as possible of existing MARF. For example, abuse keywo= rds, etc. could be specified using URIs. Yakov _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yigang.cai@alcatel-lucent.com Fri Jul 16 13:52: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 B14523A65A5 for ; Fri, 16 Jul 2010 13:52:00 -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 ISqhGv3C56wI for ; Fri, 16 Jul 2010 13:51:59 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id E895E3A6407 for ; Fri, 16 Jul 2010 13:51:58 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o6GKq7BN013192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jul 2010 15:52:07 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6GKpxUX020130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Jul 2010 15:52:06 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 16 Jul 2010 15:52:05 -0500 From: "Cai, Yigang (Yigang)" To: Yakov Shafranovich , Alex Bobotek Date: Fri, 16 Jul 2010 15:52:04 -0500 Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers Thread-Index: AcsheDu2KQLq+7i0QNmEvAj6pA2rAwDr/wCA Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B71D16@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <001f01cb2120$2d2fab80$878f0280$@com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "marf@ietf.org" Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers 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 Jul 2010 20:52:00 -0000 Yakov, Some SMS spam is source of email spam considering SMS/email/IM can be conve= rted either ways. It is a good the system receives abuse reports from multi= ple protocols and help to facilitate anti-spam policy in a centralized plac= e. Yigang =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Yak= ov Shafranovich Sent: Sunday, July 11, 2010 11:10 PM To: Alex Bobotek Cc: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML = vs Headers Considering this, is it smart to shore horn SMS abuse reporting into MARF? On Mon, Jul 12, 2010 at 12:08 AM, Alex Bobotek wrote: > Yakov, > > I'm not certain whether your comment was intended to addresses the SpamRe= p, draft-cai-smsc-mmsc-reporting-marf-00 or both. =A0However, field definit= ion and mapping is a challenge for any SMS standard. =A0Even in a most comm= on type of SMSC (SMPP<---->GSM MAP), an abusive message may be received in = MAP or SMPP protocols. > > The Sad Fact of SMS Mangling during (and after) Transport > > The lack of a single transport protocol over the numerous hops in SMS tra= nsport has its challenges; the "original message" often does not exist. =A0= GSM OTA-->GSM MAP-->SMPP-->SMPP-->GSM MAP-->GSM OTA gateway and protocol co= nversions are common. =A0And GSM and SMPP standards are by no means the onl= y ones in play, nor is there necessarily any indication of the route a mess= age may have traversed or what protocol conversions or modifications may ha= ve been performed. =A0Beyond this, there is segmentation/reassembly, and a = UA may render SMS text into Unicode or some other format for local storage,= and discard much of an original message's (perhaps GSM MAP) information. = =A0Even where unadulterated copies of a message may exist, their fidelity m= ay be uncertain. =A0For example, what was the original UDH information? =A0= Without a complete set of GSM MAP and/or SMPP attributes and perhaps origin= al padding, a full corpus cannot be constructed. =A0And simply dropping, sa= y, a UDH header attribute in GSM MAP may substantially mangle a message. > > So how should this be handled? =A0Should there be different protocols for= reporting from SMSCs, SMPP, GSM MAP, clients, SIP IPSM Gateways, STPs, use= r agents, etc.? =A0I think not. =A0This uncertainty as to the fidelity of '= corpus' is seemingly incompatible with a pragma of excluding from metadata = (e.g, Section 2) anything which may be contained in message corpus. =A0A fu= rther complication is the lack of delivery path info in SMS (no Received he= aders). =A0SpamRep further allows for variant formats which, at times place= similar information in XML and other times in corpus. > > IMHO, an applicable set of pragmas for SMS is: > * =A0 =A0 =A0 Report what you can > =A0 =A0 =A0 =A0* =A0 =A0 =A0 Report as fact what you know > =A0 =A0 =A0 =A0* =A0 =A0 =A0 Report what you are told as hearsay > > OMA SMS SpamRep attributes were largely extracted from GSM MAP and=20 > SMPP protocol fields. =A0But it is recognized that many attributes are no= t always available. =A0It is PREFERRED that accurate corpus be attached, bu= t this isn't always possible. =A0In OMA SMS SpamRep there is metadata (i.e.= , DecodedUDIndicator and UDHAttached) that indicates whether or not, for ex= ample, the attached SMS corpus contains verbatim UD and UDH. =A0Another imp= ortant metadata field (sometimes discernable from the message corpus) is Sp= amRep's 'ReportingNode' {SMS_Router, IP-SM-GW, SMS Router, IP-SM-GW, SMS-SC= , Mobile_Device, Subscriber, Email_Gateway, Unknown, Other} attribute. > > OMA SpamRep SMS reporting attempts to address the myriad challenges of SM= S abuse reporting discussed above, and others. > > Regards, > > Alex > > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Sunday, July 11, 2010 4:34 PM > To: Alex Bobotek > Cc: zengw@huawei.com; marf@ietf.org > Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00":=20 > XML vs Headers > > One of the main issues with the draft as it is, is the basic principle=20 > of MARF as it was designed - section 2, the machine readable section,=20 > should not contain any data that can be derived from the message=20 > itself. Because we don't know what standard you are using for defining=20 > SMS / MMS formats, I can't figure out whether the various message=20 > fields are already included in the original message. > > Yakov > > On Sun, Jul 11, 2010 at 4:19 PM, Alex Bobotek wrote: >> I believe that a single standard for mobile reporting (OMA and/or=20 >> IETF) should be our goal, and am very interested in seeing OMA and=20 >> IETF develop standards that do not fragment use and implementation,=20 >> whether by having one or both bodies produce applicable standard(s). >> >> SpamRep was motivated by a desire to provide reporting from more than=20 >> end users: =A0to provide a standard format for mobile reporting. =A0Yes,= =20 >> it is important to have a mobile spec that can be incorporated into=20 >> phones by device manufacturers otherwise uninvolved in anti-abuse. =A0 >> However, the SMS portion was writer to specifically support the=20 >> following (and hopefully other) classes of reporting: >> >> * =A0Manual reporting from an SMS UA to a network node >> * =A0Automated reporting from an SMS UA to a network node >> * =A0Automated/manual reporting from an SS7 or SMPP network node such=20 >> as an SMSC >> * =A0Intercarrier abuse notifications >> >> SMS abuse reporting presents many challenges that are less prominent=20 >> in email, notably that there are inherently many gateways (protocol >> conversions) in the delivery path, and very little backtrace=20 >> information (as in email headers). >> >> In drafting the SMS portion of SpamRep, I found supporting multiple=20 >> reporter classes to be a challenge, but not an impossibility. =A0 >> Separate specifications seem to be an unnecessary and disadvantageous ap= proach. >> >> While contributing to OMA SpamRep, OMA contributors (myself included)=20 >> been following ARF/MARF, even using it as a baseline for many initial=20 >> SpamRep requirements and features. =A0Two key differences between=20 >> SpamRep and MARF are: >> >> * SMTP vs HTTP (at least typically) for transport >> * XML vs RFC 5322 (email) style headers for report and message=20 >> metadata >> >> IMO, either transport-independence (costly in that transport features=20 >> such as encryption and authentication may be leveraged) or adaptation=20 >> to multiple transports (my preference) is desirable and entirely feasibl= e. >> >> The key difference is that SpamRep is XML-based while=20 >> thdraft-cai-smsc-mmsc-reporting-marf-00 draft and MARF is header-based. >> At the root of this is that email works this way, while many other=20 >> communications systems use XML. =A0Does anyone have any suggestions on=20 >> how to drive convergence? >> >> >> >> Regards, >> >> Alex >> >> >> >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf=20 >> Of Wenjun (Kevin) Zeng >> Sent: Sunday, July 11, 2010 10:41 AM >> To: 'Yakov Shafranovich'; marf@ietf.org >> Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" >> >> Hi Yakov and all, >> >> A couple of clarifications. >> >> 1. Although OMA SpamRep was originally motivated by feedback loop=20 >> between the end user and their network provider, the actual=20 >> specification only specifies two logical entities, i.e., a SpamRep=20 >> server and a SpamRep client where the client could be UA, MTA, SMSC=20 >> etc. >> >> 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF=20 >> restricted to email delivery of report only? >> >> Thanks. >> >> -Kevin >> >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf=20 >> Of Yakov Shafranovich >> Sent: Sunday, July 11, 2010 10:53 AM >> To: marf@ietf.org >> Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" >> >> This is in regards to the following draft: >> >> http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt >> >> As per emails to the list and the SpamRep documentation at the OMA,=20 >> this draft is trying to address the gap between MARF and the OMA=20 >> SpamRep requirements. One key point to note is that the MARF model is=20 >> focused on feedback loops between the ISP and the original email=20 >> sender, while the OMA SpamRep activity is focused on the end user and=20 >> their network provider. The analogous use case in the email space is=20 >> a "report spam" button for end users which creates a report for their=20 >> ISP. >> >> 1. Section 1.2 "requirements" - this seems to repeat the main MARF=20 >> draft requirements and seems to be different from the OMA=20 >> requirements. There is no need to repeat the MARF requirements=20 >> verbatim, it may be sufficient to reference them. The OMA=20 >> requirements should be referenced, and some of the OMA SpamRep=20 >> requirements which cannot be solved with MARF should be addressed explic= itly here. >> Ideally this section should clearly state that this draft seeks to=20 >> address OMA requirements X and Y, but not Z. >> >> 2. There needs to be a reference in the draft to the standard that=20 >> defines SMS/MMS message formats. This is needed in order for us to=20 >> see how it differs from email. Additionally, you need to specify=20 >> whether these SMS/MMS spam report will be delivered via email. If=20 >> not, this may not fall within MARF or IETF scope of work. >> >> 3. As per the MARF draft, there is a specific format to be followed=20 >> when defining fields for the registry. You need to specify which=20 >> abuse type it references, whether it is included once or multiple=20 >> times, and whether it is historical. That format should be followed. >> Additionally, ABNF would not hurt. >> >> 4. The draft keeps referencing abuse detected by the message center. >> However, the OMA SpamRep requirements talk about the end user=20 >> reporting spam. >> >> 5. One of the basic principles underpinning MARF is that the data=20 >> included in section 2 of the report, should be data that cannot be=20 >> otherwise derived from the original message. Many of the fields that=20 >> I see listed seem to be ones that will be included in the original=20 >> message itself. There is no need to repeat them again in section 2 of=20 >> the report. >> >> Some field specific comments: >> 6. "Message ID" - in the email world, this is automatically generated=20 >> in the headers of the MARF report itself. >> 7. "Message Center ID" - in the email world the sender of the MARF=20 >> report would be in the headers. >> 8. "Message Type" - MARF is specific for email, IM reporting has its=20 >> own formatting. You will need to create a registry or tightly define=20 >> this. Also, is this information that would be included in the=20 >> original message? >> 9. Fields 4.4 - 4.15 - are these included in the original message? Is=20 >> there a need to repeat them in part 2? >> 10. Abuse types - is there a need for all of these? Prior discussion=20 >> here seems to indicate that most of these are not necessary and some=20 >> overlap. For example, message flooding and DOS are the same. >> 11. Abuse detection methods - this is similar to the authentication=20 >> results header we currently discussed regarding DKIM. There needs to=20 >> be a document covering this. >> 12. Sections 4.18-4.23 - is any of this data included in the original=20 >> message? Also, are any of these currently used? >> 13. Regarding feedback types - I would recommend looking at the=20 >> possibility of defining a new feedback type called "sms" or "mobile" >> and re-using as much as possible of existing MARF. For example, abuse=20 >> keywords, etc. could be specified using URIs. >> >> Yakov >> _______________________________________________ >> marf mailing list >> marf@ietf.org >> https://www.ietf.org/mailman/listinfo/marf >> >> _______________________________________________ >> marf mailing list >> marf@ietf.org >> https://www.ietf.org/mailman/listinfo/marf >> > _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yigang.cai@alcatel-lucent.com Fri Jul 16 14:01: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 120863A698E for ; Fri, 16 Jul 2010 14:01:31 -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 8sQzULorscnH for ; Fri, 16 Jul 2010 14:01:29 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 2C93C3A6407 for ; Fri, 16 Jul 2010 14:01:29 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o6GL1dLJ019582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 16:01:39 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6GL1cla000513; Fri, 16 Jul 2010 16:01:38 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 16 Jul 2010 16:01:29 -0500 From: "Cai, Yigang (Yigang)" To: Alex Bobotek , Yakov Shafranovich Date: Fri, 16 Jul 2010 16:01:28 -0500 Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers Thread-Index: AcshUY5ehQhupkwGRCqJhwMMuSA1zgAEYjBwAPFyN6A= Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B71D24@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <001f01cb2120$2d2fab80$878f0280$@com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "marf@ietf.org" Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML vs Headers 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 Jul 2010 21:01:31 -0000 Alex and All, I agree with most of your points. In addition, I have following comments: (1) There are multiple SMS protocols even in a single network, such as 3GPP= MAP, SMPP, CDMA SMDPP, SIP, Parley, etc. It is challenge to retrieve commo= n fields from these protocols. (2) SMSC/MMSC currently already developed some useful criteria to indicate = spams, and which may not be a field in the protocol. But it is worth to inc= lude these fields optionally in abuse reporting.=20 (3) The reporting may or may not contain the copy of original messages (ema= il is easier to be attached). Most time, if abuse parameters/headers have s= ufficient indication, there is no need to include message body. SMSC/MMSC/e= mail server can include part of message body which is considered as spam - = current SMSC/MMSC already support the identification of spam phrase. =20 Thanks, Yigang -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Ale= x Bobotek Sent: Sunday, July 11, 2010 11:09 PM To: Yakov Shafranovich Cc: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML = vs Headers Yakov, I'm not certain whether your comment was intended to addresses the SpamRep,= draft-cai-smsc-mmsc-reporting-marf-00 or both. However, field definition = and mapping is a challenge for any SMS standard. Even in a most common typ= e of SMSC (SMPP<---->GSM MAP), an abusive message may be received in MAP or= SMPP protocols. =20 The Sad Fact of SMS Mangling during (and after) Transport The lack of a single transport protocol over the numerous hops in SMS trans= port has its challenges; the "original message" often does not exist. GSM = OTA-->GSM MAP-->SMPP-->SMPP-->GSM MAP-->GSM OTA gateway and protocol conver= sions are common. And GSM and SMPP standards are by no means the only ones= in play, nor is there necessarily any indication of the route a message ma= y have traversed or what protocol conversions or modifications may have bee= n performed. Beyond this, there is segmentation/reassembly, and a UA may r= ender SMS text into Unicode or some other format for local storage, and dis= card much of an original message's (perhaps GSM MAP) information. Even whe= re unadulterated copies of a message may exist, their fidelity may be uncer= tain. For example, what was the original UDH information? Without a compl= ete set of GSM MAP and/or SMPP attributes and perhaps original padding, a f= ull corpus cannot be constructed. And simply dropping, say, a UDH header a= ttribute in GSM MAP may substantially mangle a message. =20 So how should this be handled? Should there be different protocols for rep= orting from SMSCs, SMPP, GSM MAP, clients, SIP IPSM Gateways, STPs, user ag= ents, etc.? I think not. This uncertainty as to the fidelity of 'corpus' = is seemingly incompatible with a pragma of excluding from metadata (e.g, Se= ction 2) anything which may be contained in message corpus. A further comp= lication is the lack of delivery path info in SMS (no Received headers). S= pamRep further allows for variant formats which, at times place similar inf= ormation in XML and other times in corpus. =20 IMHO, an applicable set of pragmas for SMS is: * Report what you can * Report as fact what you know * Report what you are told as hearsay OMA SMS SpamRep attributes were largely extracted from GSM MAP and SMPP pro= tocol fields. But it is recognized that many attributes are not always ava= ilable. It is PREFERRED that accurate corpus be attached, but this isn't a= lways possible. In OMA SMS SpamRep there is metadata (i.e., DecodedUDIndic= ator and UDHAttached) that indicates whether or not, for example, the attac= hed SMS corpus contains verbatim UD and UDH. Another important metadata fi= eld (sometimes discernable from the message corpus) is SpamRep's 'Reporting= Node' {SMS_Router, IP-SM-GW, SMS Router, IP-SM-GW, SMS-SC, Mobile_Device, S= ubscriber, Email_Gateway, Unknown, Other} attribute. OMA SpamRep SMS reporting attempts to address the myriad challenges of SMS = abuse reporting discussed above, and others. =20 Regards, Alex -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org] Sent: Sunday, July 11, 2010 4:34 PM To: Alex Bobotek Cc: zengw@huawei.com; marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00": XML = vs Headers One of the main issues with the draft as it is, is the basic principle of M= ARF as it was designed - section 2, the machine readable section, should no= t contain any data that can be derived from the message itself. Because we = don't know what standard you are using for defining SMS / MMS formats, I ca= n't figure out whether the various message fields are already included in t= he original message. Yakov On Sun, Jul 11, 2010 at 4:19 PM, Alex Bobotek wrote: > I believe that a single standard for mobile reporting (OMA and/or=20 > IETF) should be our goal, and am very interested in seeing OMA and=20 > IETF develop standards that do not fragment use and implementation,=20 > whether by having one or both bodies produce applicable standard(s). > > SpamRep was motivated by a desire to provide reporting from more than=20 > end users: =A0to provide a standard format for mobile reporting. =A0Yes,= =20 > it is important to have a mobile spec that can be incorporated into=20 > phones by device manufacturers otherwise uninvolved in anti-abuse. =A0 > However, the SMS portion was writer to specifically support the=20 > following (and hopefully other) classes of reporting: > > * =A0Manual reporting from an SMS UA to a network node > * =A0Automated reporting from an SMS UA to a network node > * =A0Automated/manual reporting from an SS7 or SMPP network node such as= =20 > an SMSC > * =A0Intercarrier abuse notifications > > SMS abuse reporting presents many challenges that are less prominent=20 > in email, notably that there are inherently many gateways (protocol > conversions) in the delivery path, and very little backtrace=20 > information (as in email headers). > > In drafting the SMS portion of SpamRep, I found supporting multiple=20 > reporter classes to be a challenge, but not an impossibility. =A0 > Separate specifications seem to be an unnecessary and disadvantageous app= roach. > > While contributing to OMA SpamRep, OMA contributors (myself included)=20 > been following ARF/MARF, even using it as a baseline for many initial=20 > SpamRep requirements and features. =A0Two key differences between=20 > SpamRep and MARF are: > > * SMTP vs HTTP (at least typically) for transport > * XML vs RFC 5322 (email) style headers for report and message=20 > metadata > > IMO, either transport-independence (costly in that transport features=20 > such as encryption and authentication may be leveraged) or adaptation=20 > to multiple transports (my preference) is desirable and entirely feasible= . > > The key difference is that SpamRep is XML-based while=20 > thdraft-cai-smsc-mmsc-reporting-marf-00 draft and MARF is header-based. > At the root of this is that email works this way, while many other=20 > communications systems use XML. =A0Does anyone have any suggestions on=20 > how to drive convergence? > > > > Regards, > > Alex > > > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf=20 > Of Wenjun (Kevin) Zeng > Sent: Sunday, July 11, 2010 10:41 AM > To: 'Yakov Shafranovich'; marf@ietf.org > Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" > > Hi Yakov and all, > > A couple of clarifications. > > 1. Although OMA SpamRep was originally motivated by feedback loop=20 > between the end user and their network provider, the actual=20 > specification only specifies two logical entities, i.e., a SpamRep=20 > server and a SpamRep client where the client could be UA, MTA, SMSC=20 > etc. > > 2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF=20 > restricted to email delivery of report only? > > Thanks. > > -Kevin > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf=20 > Of Yakov Shafranovich > Sent: Sunday, July 11, 2010 10:53 AM > To: marf@ietf.org > Subject: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" > > This is in regards to the following draft: > > http://www.ietf.org/id/draft-cai-smsc-mmsc-reporting-marf-00.txt > > As per emails to the list and the SpamRep documentation at the OMA,=20 > this draft is trying to address the gap between MARF and the OMA=20 > SpamRep requirements. One key point to note is that the MARF model is=20 > focused on feedback loops between the ISP and the original email=20 > sender, while the OMA SpamRep activity is focused on the end user and=20 > their network provider. The analogous use case in the email space is a=20 > "report spam" button for end users which creates a report for their=20 > ISP. > > 1. Section 1.2 "requirements" - this seems to repeat the main MARF=20 > draft requirements and seems to be different from the OMA=20 > requirements. There is no need to repeat the MARF requirements=20 > verbatim, it may be sufficient to reference them. The OMA requirements=20 > should be referenced, and some of the OMA SpamRep requirements which=20 > cannot be solved with MARF should be addressed explicitly here. > Ideally this section should clearly state that this draft seeks to=20 > address OMA requirements X and Y, but not Z. > > 2. There needs to be a reference in the draft to the standard that=20 > defines SMS/MMS message formats. This is needed in order for us to see=20 > how it differs from email. Additionally, you need to specify whether=20 > these SMS/MMS spam report will be delivered via email. If not, this=20 > may not fall within MARF or IETF scope of work. > > 3. As per the MARF draft, there is a specific format to be followed=20 > when defining fields for the registry. You need to specify which abuse=20 > type it references, whether it is included once or multiple times, and=20 > whether it is historical. That format should be followed. > Additionally, ABNF would not hurt. > > 4. The draft keeps referencing abuse detected by the message center. > However, the OMA SpamRep requirements talk about the end user=20 > reporting spam. > > 5. One of the basic principles underpinning MARF is that the data=20 > included in section 2 of the report, should be data that cannot be=20 > otherwise derived from the original message. Many of the fields that I=20 > see listed seem to be ones that will be included in the original=20 > message itself. There is no need to repeat them again in section 2 of=20 > the report. > > Some field specific comments: > 6. "Message ID" - in the email world, this is automatically generated=20 > in the headers of the MARF report itself. > 7. "Message Center ID" - in the email world the sender of the MARF=20 > report would be in the headers. > 8. "Message Type" - MARF is specific for email, IM reporting has its=20 > own formatting. You will need to create a registry or tightly define=20 > this. Also, is this information that would be included in the original=20 > message? > 9. Fields 4.4 - 4.15 - are these included in the original message? Is=20 > there a need to repeat them in part 2? > 10. Abuse types - is there a need for all of these? Prior discussion=20 > here seems to indicate that most of these are not necessary and some=20 > overlap. For example, message flooding and DOS are the same. > 11. Abuse detection methods - this is similar to the authentication=20 > results header we currently discussed regarding DKIM. There needs to=20 > be a document covering this. > 12. Sections 4.18-4.23 - is any of this data included in the original=20 > message? Also, are any of these currently used? > 13. Regarding feedback types - I would recommend looking at the=20 > possibility of defining a new feedback type called "sms" or "mobile" > and re-using as much as possible of existing MARF. For example, abuse=20 > keywords, etc. could be specified using URIs. > > Yakov > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yigang.cai@alcatel-lucent.com Fri Jul 16 14:09: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 7431E3A69BB for ; Fri, 16 Jul 2010 14:08:46 -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=[AWL=0.000, 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 0kWSiNupvu79 for ; Fri, 16 Jul 2010 14:08:43 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id E996B3A6B67 for ; Fri, 16 Jul 2010 14:08:33 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o6GL8Teh022631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jul 2010 16:08:29 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6GL8S3V023638 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Jul 2010 16:08:28 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 16 Jul 2010 16:08:28 -0500 From: "Cai, Yigang (Yigang)" To: Alex Bobotek , John Levine , "marf@ietf.org" Date: Fri, 16 Jul 2010 16:08:27 -0500 Thread-Topic: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" Thread-Index: Acshgi+sJbmdX2ERQaeJ/l2ZbZoeQAAAfNBwAOmoJoA= Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B71D2D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <001f01cb2120$2d2fab80$878f0280$@com> <20100712052206.2387.qmail@joyce.lan> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-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: Fri, 16 Jul 2010 21:09:05 -0000 >From mobile UA, your comment is true. But from message center, it could be = different, and I see there is a need of convergence. Yigang -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Ale= x Bobotek Sent: Monday, July 12, 2010 1:45 AM To: John Levine; marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" I'm in agreement with John that MARF/Email and SpamRep/SMS are so far apart= that it would be difficult to force them to converge. Feedback and abuse = management from a mobile SMS user agent has requirements for which HTTP (or= any request/response protocol) is more advantageous than SMTP. This is IM= O true for any UA-based feedback, but especially so in the mobile case. =20 SpamRep is a request/response transaction protocol in which some processing= (with potential side effects) may be required prior to an application-laye= r response. As written, it is not completely compatible with store & forwa= rd SMTP relay. It would be awkward to mail back an asynchronous response t= o a device that has limited Internet connectivity, and some sort of extensi= on to SMTP would likely be necessary for handling a MIME response. Lemonad= e-like optimizations that prevent over-the-air transmission of messages alr= eady in possession of the receiving system are also needed. SMTP is not an= ideal transport for SpamRep. =20 Emailing back protocol responses to cellular mobile devices (even if not ov= er port 25, and especially if not immediate) isn't an attractive architectu= re. A substantial subset of SpamRep could, in theory, operate over a messa= ge transport protocol such as SMTP. =20 So it's probably best to use SpamRep for SMS. =20 Note that SpamRep does support Email abuse reporting over HTTP. Perhaps an= y overlap in this area should be discussed. Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Joh= n Levine Sent: Sunday, July 11, 2010 10:22 PM To: marf@ietf.org Subject: Re: [marf] Review of "draft-cai-smsc-mmsc-reporting-marf-00" >2. OMA SpamRep delivers Spam Reports through HTTP protocol. Is MARF=20 >restricted to email delivery of report only? MARF defines a MIME type. To date, it's always been sent as the body of an= email message, but HTTP also transmits MIME objects. For that matter, since SpamRep is also a MIME type, you can send those, at = least the ones that don't ask for an immediate response, by e-mail. Given how little SMTP and SMS have in common, I'd be more inclined to keep = them separate and encourage places that can accept both to accept them both= by mail and HTTP. R's, John _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From yigang.cai@alcatel-lucent.com Fri Jul 16 14:22: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 926433A6857 for ; Fri, 16 Jul 2010 14:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 FHGbXNeBBdNw for ; Fri, 16 Jul 2010 14:22:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 0E7A93A6407 for ; Fri, 16 Jul 2010 14:22:24 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o6GLMatQ001807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Jul 2010 16:22:36 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6GLMIts011455 for ; Fri, 16 Jul 2010 16:22:36 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 16 Jul 2010 16:22:33 -0500 From: "Cai, Yigang (Yigang)" To: "Torabi, Mohammad (Moh)" , "Zeltsan, Zachary (Zachary)" Date: Fri, 16 Jul 2010 16:22:32 -0500 Thread-Topic: [marf] Time slot at IETF 78 Thread-Index: AcsfGe/+dLoh6LYkSP21ruOHa+ar/wAW1z5QAAEgvRAAAhZiUABITI5gAHqYHDAACFEJwACfW7sQ Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B71D42@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688DA9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><5710F82C0E73B04FA559560098BF95B124F9688DAC@USNAVSXCHMBSA3.ndc.alcatel-lucent.com><6F428EFD2B8C2F49A2FB1317291A76C1134068FF5C@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9688DAE@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6F428EFD2B8C2F49A2FB1317291A76C11340690BF8@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> 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_5710F82C0E73B04FA559560098BF95B124F9B71D42USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "'marf@ietf.org'" Subject: Re: [marf] Time slot at IETF 78 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 Jul 2010 21:22:35 -0000 --_000_5710F82C0E73B04FA559560098BF95B124F9B71D42USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Moh, Please see my responses on Murry's comments. Yigang ________________________________ From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Tuesday, July 13, 2010 12:32 PM To: Torabi, Mohammad (Moh); 'alex@bobotek.net' Cc: 'marf@ietf.org' Subject: Re: [marf] Time slot at IETF 78 Hello Mohammad, I disagree with the first argument presented in (1) below. SpamRep defines= the format for reporting from a SpamRep Client to a SpamRep Server. It do= esn't stipulate what specific devices those are. There's nothing in SpamRe= p that stipulates, for example, that a SpamRep Client could not be an email= server, email gateway, SMSC, MMSC, web portal, or any other application. = It simply names the two roles for the purposes of specifying what to send a= nd expect in the same way RFC5321 says the client uses four-letter verbs as= commands and the server uses three-digit numbers as replies. [Cai, Yigang (Yigang)] He is right. I will modify my analysis of gaps. Transport is a separate issue. SpamRep mandates use of HTTP POST as its tr= ansport, which seems to be a reasonable first approach especially since the= payload will usually be large and the usable space of an SMPP message is r= ather small. That said, one could propose a supplemental transport mechani= sm that deals with fragmentation and reassembly of a SpamRep report into pi= eces that fit inside a batch of SMPP messages. This is a whole other work = area though, and one could argue that it "belongs" to OMA and not IETF. [Cai, Yigang (Yigang)] Actually our products do not care of transports, eit= her way work for us. Given the scope you're attempting to cover in (3) below, perhaps a faster r= oute forward would be to make a draft that updates draft-ietf-marf-base to = permit the third MIME part to be of the MIME type defined by SpamRep. That= MIME type already covers the ability to report on SMS and MMS spam, and wo= uld use MARF (and thus email) as the transport. It seems to me that would = cover all of your requirements except for the transport one discussed above= . [Cai, Yigang (Yigang)] I don't understand his point here. We would like to = re-use MIME type in MARF. But I will re-study them. -MSK From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Tor= abi, Mohammad (Moh) Sent: Tuesday, July 13, 2010 7:08 AM To: 'alex@bobotek.net' Cc: 'marf@ietf.org' Subject: Re: [marf] Time slot at IETF 78 There are two areas of work and this draft to fill some gaps in these two a= reas: OMA SpamRep, IETF MARF and this Draft proposal: 1. OMA Work Area OMA draft of "Mobile Spam Reporting Technical Specification" (OMA-TS-SpamRe= p-V1_0-20100601-D) defines spam reporting (SpamRep) messages between client= and server. It provides a capability wherein media content that is receive= d on a device can be designated, either by the user or automatically by the= SpamRep client, as Spam and a report containing information about the Spam= message is sent to a Server for further processing. Furthermore, the work = and the protocol are applicable to email, SMS, MMS and IM message spam repo= rting from end user device to/from the server. However, it does not specify= the spam reporting from a message center (email server, email gateway, SMS= C, MMSC, web portal, and other applications). This is an area that market (= operators/service providers) may be interested in. Furthermore, the OMA wor= k does not address how to carry SpamRep XML Document in existing mobile pro= tocols from mobile device to/from the server - SIP, MAP, SMPP, etc. 2. IETF Work Area IETF has produced two drafts so far on the subject: draft-ietf-marf-base-06= & draft-ietf-marf-dkim-reporting-00. draft-ietf-marf-base-06: This draft specifies an email spam reporting/feedb= ack protocol and attributes from email operator/server when discovering eit= her incoming or outgoing email suspicious. However, it does not address spa= m reporting from end user or end user device. Furthermore, it does not cove= r other message types (SMS, MMS, IM) draft-ietf-marf-dkim-reporting-00: This draft presents an extension to the = DomainKeys Identified Mail (DKIM) specifications to allow public keys for v= erification to include a reporting address to be used for reporting message= verification issues. It extends an Internet Message reporting format to be= followed when generating such reports. It also extends MARF-Base to add fe= atures required for DKIM reporting. 3. Our proposal (draft-cai-smsc-mmsc-reporting-marf-00.txt) This proposal (to IETF MARF in IETF 78) addresses one area of gap and that = is for the message centers, SMSC and MMSC spam reporting, to filter and det= ect spam messages (machine only) and report them to network spam control se= rver. This draft will be an extent to MARF's Base Draft. It defines an exte= nsible format and MIME type that may be used by SMSC or MMSC to report feed= back about received SMS and MMS with message abuses. -M -----Original Message----- From: Alex Bobotek [mailto:alex@bobotek.net] Sent: Saturday, July 10, 2010 7:49 PM To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh) Cc: marf@ietf.org Subject: RE: [marf] Time slot at IETF 78 Could someone help explain what gap in OMA SpamRep is addressed by this? Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Zeltsan, Zachary (Zachary) Sent: Friday, July 09, 2010 9:19 AM To: 'Yakov Shafranovich' Cc: Torabi, Mohammad (Moh); marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Sent on Moh's behalf... -----Original Message----- From: Torabi, Mohammad (Moh) Sent: Friday, July 09, 2010 11:26 AM To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich' Cc: marf@ietf.org Subject: RE: [marf] Time slot at IETF 78 Hi Yakov, This work is trying to address a gap that is seen in the ongoing work of IETF's MARF and OMA's SpamRep WA. The draft is submitted by individuals as is the usual procedure to follow in IETF. However, all authors/contributors are Alcatel-Lucent employees. Regards, Moh -----Original Message----- From: Zeltsan, Zachary (Zachary) Sent: Friday, July 09, 2010 8:16 AM To: 'Yakov Shafranovich' Cc: marf@ietf.org; Torabi, Mohammad (Moh) Subject: RE: [marf] Time slot at IETF 78 Yakov, Moh, who is one of the draft's co-authors, has been involved in the OMA work and is in a better position to answer questions related to the OMA effort. (I have copied this message to Moh). Zachary -----Original Message----- From: Yakov Shafranovich [mailto:yakov@shaftek.org] Sent: Thursday, July 08, 2010 11:44 PM To: Zeltsan, Zachary (Zachary) Cc: marf@ietf.org Subject: Re: [marf] Time slot at IETF 78 Zachary, Before commenting on the technical aspects, can you tell us the background for this? Is this part of the OMA or MAAWG efforts, or is this something that you are submitting privately to the IETF? What is Alcatel's role here? Thanks, Yakov On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary) wrote: > Barry, > Murray, > > Could you please give us a time slot (10 minutes) at the IETF 78 for > presenting the recently-published draft An Extensible Format for SMSC/MMSC > Feedback Reports? (The draft is at > http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ). > > With thanks, > > Zachary Zeltsan > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf --_000_5710F82C0E73B04FA559560098BF95B124F9B71D42USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Moh,
 
Please see my responses on Murry's=20 comments.
 
Yigang
 

From: marf-bounces@ietf.org=20 [mailto:marf-bounces@ietf.org] On Behalf Of Murray S.=20 Kucherawy
Sent: Tuesday, July 13, 2010 12:32 PM
To:=20 Torabi, Mohammad (Moh); 'alex@bobotek.net'
Cc:=20 'marf@ietf.org'
Subject: Re: [marf] Time slot at IETF=20 78

Hello=20 Mohammad,

 

I disagree with the f= irst=20 argument presented in (1) below.  SpamRep defines the format for=20 reporting from a SpamRep Client to a SpamRep Server.  It doesn’= ;t=20 stipulate what specific devices those are.  There’s nothing in= SpamRep=20 that stipulates, for example, that a SpamRep Client could not be an email= =20 server, email gateway, SMSC, MMSC, web portal, or any other application.&= nbsp;=20 It simply names the two roles for the purposes of specifying what to send= and=20 expect in the same way RFC5321 says the client uses four-letter verbs as= =20 commands and the server uses three-digit numbers as replies.
[C= ai, Yigang=20 (Yigang)] He is right. I will modify my analysis of=20 gaps. 

 

Transport is a separa= te=20 issue.  SpamRep mandates use of HTTP POST as its transport, which se= ems=20 to be a reasonable first approach especially since the payload will usual= ly be=20 large and the usable space of an SMPP message is rather small.  That= =20 said, one could propose a supplemental transport mechanism that deals wit= h=20 fragmentation and reassembly of a SpamRep report into pieces that fit ins= ide a=20 batch of SMPP messages.  This is a whole other work area though, and= one=20 could argue that it “belongs” to OMA and not IETF.
[C= ai, Yigang=20 (Yigang)] Actually our products do not care of transports, either wa= y=20 work for us. 

 

Given the scope you&#= 8217;re=20 attempting to cover in (3) below, perhaps a faster route forward would be= to=20 make a draft that updates draft-ietf-marf-base to permit the third MIME p= art=20 to be of the MIME type defined by SpamRep.  That MIME type already c= overs=20 the ability to report on SMS and MMS spam, and would use MARF (and thus e= mail)=20 as the transport.  It seems to me that would cover all of your=20 requirements except for the transport one discussed above.
[C= ai, Yigang=20 (Yigang)] I don't understand his point here. We would like to re-use= MIME=20 type in MARF. But I will re-study=20 them. 

 

-MSK

 

 

From:=20 marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of=20 Torabi, Mohammad (Moh)
Sent: Tuesday, July 13, 2010 7:08=20 AM
To: 'alex@bobotek.net'
Cc:=20 'marf@ietf.org'
Subject: Re: [marf] Time slot at IETF=20 78

 

There are two areas of work and this draft to fil= l some=20 gaps in these two areas: OMA SpamRep, IETF MARF and this Draft=20 proposal:

1.        = ; OMA=20 Work Area

OMA draft of “Mobile Spam Reporting Technic= al=20 Specification” (OMA-TS-SpamRep-V1_0-20100601-D) defines spam report= ing=20 (SpamRep) messages between client and server. It provides a capability wh= erein=20 media content that is received on a device can be designated, either by t= he=20 user or automatically by the SpamRep client, as Spam and a report contain= ing=20 information about the Spam message is sent to a Server for further proces= sing.=20 Furthermore, the work and the protocol are applicable to email, SMS, MMS = and=20 IM message spam reporting from end user device to/from the server. Howeve= r, it=20 does not specify the spam reporting from a message center (email server, = email=20 gateway, SMSC, MMSC, web portal, and other applications). This is an area= that=20 market (operators/service providers) may be interested in. Furthermore, t= he=20 OMA work does not address how to carry SpamRep XML Document in existing m= obile=20 protocols from mobile device to/from the server – SIP, MAP, SMPP,=20 etc.

 

2.        = ; IETF=20 Work Area

IETF has produced two drafts so far on the subjec= t:=20 draft-ietf-marf-base-06 &=20 draft-ietf-marf-dkim-reporting-00.

draft-ietf-marf-base-06: This draft specif= ies an=20 email spam reporting/feedback protocol and attributes from email=20 operator/server when discovering either incoming or outgoing email suspic= ious.=20 However, it does not address spam reporting from end user or end user dev= ice.=20 Furthermore, it does not cover other message types (SMS, MMS,=20 IM)

draft-ietf-marf-dkim-reporting-00: This dr= aft=20 presents an extension to the DomainKeys Identified Mail (DKIM) specificat= ions=20 to allow public keys for verification to include a reporting address to b= e=20 used for reporting message verification issues. It extends an Internet Me= ssage=20 reporting format to be followed when generating such reports. It also ext= ends=20 MARF-Base to add features required for DKIM reporting.

 

3. Our proposal=20 (draft-cai-smsc-mmsc-reporting-marf-00.txt)

This proposal (to IETF MARF in IETF 78) addresses= one=20 area of gap and that is for the message centers, SMSC and MMSC spam repor= ting,=20 to filter and detect spam messages (machine only) and report them to netw= ork=20 spam control server. This draft will be an extent to MARF’s Base Dr= aft. It=20 defines an extensible format and MIME type that may be used by SMSC or MM= SC to=20 report feedback about received SMS and MMS with message abuses.

 

-M

 

-----Original Message-----
From: Alex Bobotek= =20 [mailto:alex@bobotek.net]
Sent: Saturday, July 10, 2010 7:49 PM
To= :=20 Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh)Cc:=20 marf@ietf.org
Subject: RE: [marf] Time slot at IETF 78

 

Could someone help explain what gap in OMA SpamRe= p is=20 addressed by this?

 

 

Regards,

 

Alex

 

-----Original Message-----

From: marf-bounces@ietf.org=20 [mailto:marf-bounces@ietf.org] On Behalf Of

Zeltsan, Zachary (Zachary)

Sent: Friday, July 09, 2010 9:19 AM

To: 'Yakov Shafranovich'

Cc: Torabi, Mohammad (Moh); marf@ietf.org

Subject: Re: [marf] Time slot at IETF 78

 

Sent on Moh's behalf...

 

-----Original Message-----

From: Torabi, Mohammad (Moh)

Sent: Friday, July 09, 2010 11:26 AM

To: Zeltsan, Zachary (Zachary); 'Yakov=20 Shafranovich'

Cc: marf@ietf.org

Subject: RE: [marf] Time slot at IETF 78

 

Hi Yakov,

This work is trying to address a gap that is seen= in the=20 ongoing work of

IETF's MARF and OMA's SpamRep WA. The draft is su= bmitted=20 by individuals

as is the usual procedure to follow in IETF. Howe= ver,=20 all

authors/contributors are Alcatel-Lucent=20 employees.

 

Regards,

 

Moh

 

-----Original Message-----

From: Zeltsan, Zachary (Zachary)

Sent: Friday, July 09, 2010 8:16 AM

To: 'Yakov Shafranovich'

Cc: marf@ietf.org; Torabi, Mohammad (Moh)

Subject: RE: [marf] Time slot at IETF 78

 

Yakov,

 

Moh, who is one of the draft's co-authors, has be= en=20 involved in the OMA

work and is in a better position to answer questi= ons=20 related to the OMA

effort. (I have copied this message to=20 Moh).

 

Zachary

 

-----Original Message-----

From: Yakov Shafranovich [mailto:yakov@shaftek.or= g]=20

Sent: Thursday, July 08, 2010 11:44 PM=

To: Zeltsan, Zachary (Zachary)

Cc: marf@ietf.org

Subject: Re: [marf] Time slot at IETF 78

 

Zachary,

 

Before commenting on the technical aspects, can y= ou tell=20 us the

background for this? Is this part of the OMA or M= AAWG=20 efforts, or is

this something that you are submitting privately = to the=20 IETF? What is

Alcatel's role here?

 

Thanks,

Yakov

 

On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary= =20 (Zachary)

<zachary.zeltsan@alcatel-lucent.com>=20 wrote:

> Barry,

> Murray,

> 

> Could you please give us a time slot (10 min= utes)=20 at the IETF 78 for

> presenting the recently-published draft An=20 Extensible Format for

SMSC/MMSC

> Feedback Reports? (The draft is at

>=20 http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/=20 ).

> 

> With thanks,

> 

> Zachary Zeltsan

> 

>=20 _______________________________________________

> marf mailing list

> marf@ietf.org

>=20 https://www.ietf.org/mailman/listinfo/marf

> 

> 

_______________________________________________=

marf mailing list

marf@ietf.org

https://www.ietf.org/mailman/listinfo/marf

--_000_5710F82C0E73B04FA559560098BF95B124F9B71D42USNAVSXCHMBSA_-- From sm@resistor.net Fri Jul 16 19:00: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 B65F33A6783 for ; Fri, 16 Jul 2010 19:00:59 -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 6jR6O4m15QwC for ; Fri, 16 Jul 2010 19:00:57 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 364B93A6407 for ; Fri, 16 Jul 2010 19:00:57 -0700 (PDT) Received: from sm-PC.resistor.net ([10.0.0.15]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o6H20rg0028234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 19:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1279332066; x=1279418466; bh=H53torsshNZVZ4e8e5pTJ8bQyCE/dcTXPNLqw05CRBI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=PtiL0SuWVbcH9itOdCqPPwrWoHc3zJbGr8pSzch34VYC866QMlVTUnryBvPJ44jIg zC7rpzGew+2/PjaezHtlu7ZiIKdeaO3aOF6rRvyz2WiwHsvH9Uezva/0o91cqkDHYZ PFlA6RBjlyy/NYBLtlWiDGDqSFiVo1xc7z0r8jJ0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1279332066; x=1279418466; bh=H53torsshNZVZ4e8e5pTJ8bQyCE/dcTXPNLqw05CRBI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=3ZTbBPNRWrsWwHyTnUROfoiKT7fZEmXbGlWLogmMT/3BSSFIXR32zy3rngDiLpcH1 K683cPLKtXjb9Z6WJd6Ah97JKiMi8jzhmZKodHVj6ufnQI+4Eyy2tpu9PnpWWYMDGN NtWm33shqfEVwVhFxMBN/6Thl5Y58N2NKYp6nHUQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ZNwyq6HAxUdZlAgcQYMYGDGteTsLe6k9HndZ3l2NmLZKsguF+4FdqLtru+AtvznMA aZYc/pKZPRBVV1ryxyg8akYb/5muj8MbiJRUuRYBUTybWHbZNC8cQPIAkbio8Mb5fKN j4MQHHcdiahZ4/W9knr1QcPRr328MZaPbnnaheo= Message-Id: <6.2.5.6.2.20100716185636.087fcb20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Jul 2010 18:59:36 -0700 To: "Cai, Yigang (Yigang)" From: SM In-Reply-To: <5710F82C0E73B04FA559560098BF95B124F9B71CF9@USNAVSXCHMBSA3. ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9B71CF9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Sat, 17 Jul 2010 02:00:59 -0000 Hi Yiyang, At 01:18 PM 7/16/2010, Cai, Yigang (Yigang) wrote: >That is one of my purposes in the draft. BTW, could you advise me >what is IMHO? That's short for "in my humble opinion". Regards, -sm From yigang.cai@alcatel-lucent.com Fri Jul 16 19:15: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 B5D273A6783 for ; Fri, 16 Jul 2010 19:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 XfYfoUMiiI+5 for ; Fri, 16 Jul 2010 19:15:48 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D51E33A6407 for ; Fri, 16 Jul 2010 19:15:47 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o6H2Fw0M026471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 21:15:59 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o6H2Fu7e012723; Fri, 16 Jul 2010 21:15:58 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 16 Jul 2010 21:15:42 -0500 From: "Cai, Yigang (Yigang)" To: SM Date: Fri, 16 Jul 2010 21:15:41 -0500 Thread-Topic: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-00 Thread-Index: AcslU+3ANxkEDn9HTMW07CFqzAmWlQAAfnEw Message-ID: <5710F82C0E73B04FA559560098BF95B124F9B71D8D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <5710F82C0E73B04FA559560098BF95B124F9688D98@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <5710F82C0E73B04FA559560098BF95B124F9B71CF9@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <6.2.5.6.2.20100716185636.087fcb20@resistor.net> In-Reply-To: <6.2.5.6.2.20100716185636.087fcb20@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "marf@ietf.org" Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-reporting-marf-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: Sat, 17 Jul 2010 02:15:48 -0000 THANKS!=20 -----Original Message----- From: SM [mailto:sm@resistor.net]=20 Sent: Friday, July 16, 2010 9:00 PM To: Cai, Yigang (Yigang) Cc: marf@ietf.org Subject: Re: [marf] FW: New Version Notification for draft-cai-smsc-mmsc-re= porting-marf-00 Hi Yiyang, At 01:18 PM 7/16/2010, Cai, Yigang (Yigang) wrote: >That is one of my purposes in the draft. BTW, could you advise me what=20 >is IMHO? That's short for "in my humble opinion". Regards, -sm=20 From jdfalk-lists@cybernothing.org Mon Jul 26 09:53: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 E67123A6ABB for ; Mon, 26 Jul 2010 09:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MANGLED_SPAM=2.3, 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 dmzTb0xqK-Ka for ; Mon, 26 Jul 2010 09:53:46 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 789A23A6A95 for ; Mon, 26 Jul 2010 09:53:46 -0700 (PDT) Received: from dhcp-27c1.meeting.ietf.org (dhcp-27c1.meeting.ietf.org [130.129.39.193]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o6QGs5ZC001025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Jul 2010 10:54:07 -0600 References: <4C3CA77E.4060504@tana.it> In-Reply-To: <4C3CA77E.4060504@tana.it> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Mon, 26 Jul 2010 18:54:04 +0200 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1081) Subject: Re: [marf] The case of forwarding spam reports to 3rd parties, in reporting-discovery 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 Jul 2010 16:53:48 -0000 I'd been leaving this for discussion during the meeting tomorrow, but = just re-read it and realized I can answer these questions now. On Jul 13, 2010, at 7:50 PM, Alessandro Vesely wrote: > Forwarding to the connection provider is more akin to reporting = network incidents. It suits botnets and other "intractable" spammers, = and may be better dealt with using IODEF-style reporting. Whatever the = style, the current [DRAFT] wording is that "feedback generators SHOULD = NOT send reports to ADMDs that are not responsible for the reported = message", thus it would be enough to hold that a carrier /is/ in some = sense responsible for the message transmission. The carrier (which I'd call an "access provider") is responsible for the = connection to the source of the message. I suppose that's not the same = ADMD, so far as mail transport is concerned, so this may require = clarification. (Note that I'm referring to current practice, there, so = it's a matter of adequately describing the practice rather than = justifying its validity.) > Reputation trackers are needed to avoid that cooperative senders = actually become opt-out operators with licence to spam. This topic is = not yet well understood --at least by me. However, feedback is a = fundamental ingredient of any reputation systems, so preventing it is = not a good idea. However, there is no equivalent of the WHOIS LIR = assignments databases in order to ascertain the involvement of a = reputation tracker. How are we going to make up for that? [AR] doesn't adequately depict the relationship between mailbox = providers and reputation trackers. There are two ways that complaint feedback reports get to a reputation = tracker today. One is that the end user can configure their MUA to send = the feedback to the reputation tracker directly, generally by installing = a plug-in; this is how spamcop operates. The other is that the end = user's mailbox provider enters into a relationship with the reputation = tracker, either by contract (which is what we do for senderscore) or by = purchasing a particular vendor's anti-spam software (i.e. = Cisco/Ironport, which then feeds senderbase.) It could be argued that either of these two latter scenarios actually = place the reputation tracker within the mailbox provider's ADMD, so far = as mail transport is concerned. > [DRAFT] = http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery > [AR] = http://wiki.asrg.sp.am/wiki/Abuse_Reporting#The_Feedback_Loop_.28FBL.29_an= d_other_usage_of_abuse_reports From vesely@tana.it Tue Jul 27 05:25: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 5427B3A6BDB for ; Tue, 27 Jul 2010 05:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, 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 9eR8DDrajijs for ; Tue, 27 Jul 2010 05:25:35 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 7FAC03A6BC4 for ; Tue, 27 Jul 2010 05:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1280233556; bh=miBs3GnGZnJVVhzxlxERzlNk1ZcriuYwvP9BiwKoa38=; l=6043; h=Message-ID:Date:From:Mime-Version:To:References:In-Reply-To; b=fDzLrPt6kU9YT0nq1IZXbyNxUzjp1FnUTV0bwzbRyd1SCsx4ziUorAn2x07KJMN0s 6Fo98V8Iv8Fr40GzGZpTJDFZEIjl2EoL4VTjFgYtk4NoQkOSL5LKpo0TAVM5JQnjGy S5ebhOeDii8beo3SmtohOHVz9/ZCLFfPokt2ctDQ= 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, 27 Jul 2010 14:25:56 +0200 id 00000000005DC035.000000004C4ED054.000017F7 Message-ID: <4C4ED053.3010007@tana.it> Date: Tue, 27 Jul 2010 14:25:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-6135-1280233556-0001-2" To: marf@ietf.org References: <4C3CA77E.4060504@tana.it> In-Reply-To: Subject: Re: [marf] The case of forwarding spam reports to 3rd parties, in reporting-discovery 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 Jul 2010 12:25:37 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-6135-1280233556-0001-2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 26/Jul/10 18:54, J.D. Falk wrote: > On Jul 13, 2010, at 7:50 PM, Alessandro Vesely wrote: > >> Forwarding to the connection provider [...] > > The carrier (which I'd call an "access provider") is responsible > for the connection to the source of the message. I suppose that's > not the same ADMD, so far as mail transport is concerned, so this > may require clarification. (Note that I'm referring to current > practice, there, so it's a matter of adequately describing the > practice rather than justifying its validity.) I attach my attempt. I haven't mentioned abusix [AX] explicitly, as "specific projects' databases". Do they deserve a reference? BTW, they are currently working with an "x-arf" project [XA], formatted using yaml. >> Reputation trackers [...] > > [AR] doesn't adequately depict the relationship between mailbox providers and reputation trackers. > > There are two ways that complaint feedback reports get to a > reputation tracker today. One is that the end user can configure > their MUA to send the feedback to the reputation tracker directly, > generally by installing a plug-in; this is how spamcop operates. I didn't know about their plug-in and helper scripts [SC]. IMHO, their Reporting Service plays the role that a "Last MX" should cover, rather than that of a reputation tracker proper --well, they also track reputations, but those activities, in their own words, "operate independently of each other, [although] they also rely on each other to operate effectively". I've updated [AR] to take that into account. Is it any better? > The other is that the end user's mailbox provider enters into a > relationship with the reputation tracker, either by contract (which > is what we do for senderscore) or by purchasing a particular > vendor's anti-spam software (i.e. Cisco/Ironport, which then feeds > senderbase.) How would you depict that? > It could be argued that either of these two latter scenarios > actually place the reputation tracker within the mailbox provider's > ADMD, so far as mail transport is concerned. Hm.. "within" suggests access to data available at the mailbox provider's. For the Reporting Service, this is limited to a message's topmost header fields. Do SenderScore's contracts or Ironport provide for more data exchange? >> [DRAFT] http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery >> [AR] http://wiki.asrg.sp.am/wiki/Abuse_Reporting#The_Feedback_Loop_.28FBL.29_and_other_usage_of_abuse_reports [AX] http://abusix.com/ [XA] http://www.x-arf.org/specification.html [SC] http://www.spamcop.net/fom-serve/cache/166.html --=_north-6135-1280233556-0001-2 Content-Type: text/plain; name="report-discovery-patch-a.txt"; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="report-discovery-patch-a.txt" LS0tIGRyYWZ0LWpkZmFsay1tYXJmLXJlcG9ydGluZy1kaXNjb3ZlcnktMDEueG1sCTIwMTAt MDYtMjYgMTI6MzY6NTIuMDAwMDAwMDAwICswMjAwCisrKyBkcmFmdC1qZGZhbGstbWFyZi1y ZXBvcnRpbmctZGlzY292ZXJ5LTBhLnhtbAkyMDEwLTA3LTI3IDEyOjU1OjQ0LjAwMDAwMDAw MCArMDIwMApAQCAtMzQ4LDYgKzM0OCwyMiBAQAogCQkJCXRoYXQgYWRkcmVzcy4gIE90aGVy d2lzZSwgaWYgYSAicGFzcyIgaXMgb2J0YWluZWQgZm9yIHRoZQogCQkJCUhFTE8vRUhMTyBu YW1lLCB0aGF0IGRvbWFpbiBuYW1lLjwvdD4KIAkJCTwvc2VjdGlvbj4KKwkJCTxzZWN0aW9u IHRpdGxlPSJBY2Nlc3MgcHJvdmlkZXIgb2YgdHJhbnNtaXR0ZXIncyBJUCI+CisJCQkJPHQ+ IFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBTTVRQIGNsaWVudCB0aGF0IGhhcyB0cmFuc21pdHRl ZCB0aGUKKwkJCQlyZXBvcnRlZCBtZXNzYWdlIGJlbG9uZ3MgdG8gYSBibG9jayB0aGF0IG9u ZSBvZiB0aGUgZml2ZSBSZWdpb25hbAorCQkJCUludGVybmV0IFJlZ2lzdHJpZXMgaGFzIGFs bG9jYXRlZCB0byBhbiBhY2Nlc3MgcHJvdmlkZXIuICBDaG9vc2luZworCQkJCXRoZSAxc3Qg bGV2ZWwgKGxhcmdlc3QpIHJhbmdlIG1vc3Qgb2Z0ZW4gcmVzdWx0cyBpbiBhIGRpZmZlcmVu dAorCQkJCW9yZ2FuaXphdGlvbiAtLXRoZSBuZXR3b3JrIHRoYXQgaG9zdHMgdGhlIHRyYW5z bWl0dGVyLiAgQ29udGFjdHMKKwkJCQljYW4gYmUgb2J0YWluZWQgcXVlcnlpbmcgZWl0aGVy IFdIT0lTIG9yIHNwZWNpZmljIHByb2plY3RzJworCQkJCWRhdGFiYXNlcyBkZXNpZ25lZCBm b3IgdGhpcyB2ZXJ5IHRhc2suPC90PgorCQkJCTx0PiBJbiBhZGRpdGlvbiwgdmFsaWRhdGlu ZyB0aGUgSVAgYWRkcmVzcyB1c2luZyB0aGUgImlwcmV2IgorCQkJCW1ldGhvZCBtYXkgbGVh ZCB0byBvbmUgb3IgbW9yZSBBRE1EcyB0aGF0IHRoZSByZWxldmFudCBJUCBpcworCQkJCWFm ZmlsaWF0ZWQgd2l0aC48L3Q+CisJCQkJPHQ+IEluIGJvdGggY2FzZXMsIHRoZSByZXN1bHRp bmcgQURNRHMgbWF5IGNvcnJlc3BvbmQgdG8KKwkJCQlvcmdhbml6YXRpb25zIHRoYXQgYXJl IG9ubHkgaW5kaXJlY3RseSByZXNwb25zaWJsZSBmb3Igc2VuZGluZyB0aGUKKwkJCQlyZXBv cnRlZCBtZXNzYWdlLCBidXQgbWF5IGFjdCBhcyBhcmJpdHJhdG9ycyBmb3IgdGhlIGFidXNl IGNhc2UgYXQKKwkJCQloYW5kcy48L3Q+CisJCQk8L3NlY3Rpb24+CiAJCTwvc2VjdGlvbj4K IAogCQk8c2VjdGlvbiBhbmNob3I9IklBTkEiIHRpdGxlPSJJQU5BIENvbnNpZGVyYXRpb25z Ij4KQEAgLTM4Miw2ICszOTgsMTEgQEAKIAkJCQlhdCBhbiBBRE1EIHRoYXQgaGFuZGxlZCBh IGdpdmVuIG1lc3NhZ2UgY291bGQgaGF2ZSBpbnRlcmNlcHRlZCB0aGUKIAkJCQltZXNzYWdl IHdoZW4gdGhleSBzaWduZWQgb3IgcmVsYXllZCBpdCwgaWYgdGhleSB3YW50ZWQgdG8sCiAJ CQkJdGhlcmVmb3JlIGl0IGlzIGxlc3Mgb2YgYSBjb25jZXJuIHRvIGZvcndhcmQgYWJ1c2Ug cmVwb3J0cyB0aGVyZS48L3Q+CisJCQkJPHQ+IFRoaXJkIHBhcnRpZXMgdGhhdCBhcmUgb25s eSBpbmRpcmVjdGx5IHJlc3BvbnNpYmxlIGZvciB0aGUKKwkJCQl0cmFuc21pc3Npb24gb2Yg YSBtZXNzYWdlIGFyZSB1bmFibGUgdG8gaW50ZXJjZXB0IHRoZSBtZXNzYWdlLCBlLmcuCisJ CQkJaW4gY2FzZSBvZiBlbmNyeXB0ZWQgU01UUCBzZXNzaW9ucy4gIFRoZWlyIGNvbXBsaWFu Y2Ugd2l0aCByZWxldmFudAorCQkJCXBvbGljaWVzIHNob3VsZCBiZSBhc2NlcnRhaW5lZCBz dGVtbWluZyBmcm9tIHRoZWlyIGluc3RpdHV0aW9uYWwKKwkJCQlyb2xlLCBpbiB0aGVzZSBj YXNlcy48L3Q+CiAJCQkJPHQ+IENvbnRhY3QgYWRkcmVzc2VzIGZvciBhIGdpdmVuIGRvbWFp biBuYW1lIHNob3VsZCBiZWFyIHN1Y2gKIAkJCQluYW1lIGFzIHRoZWlyIGRvbWFpbiBwYXJ0 cy4gIEdlbmVyYXRvcnMgbWF5IHRyZWF0IG5vbi1jb25mb3JtaW5nCiAJCQkJYWRkcmVzc2Vz IHdpdGggZ3JlYXQgc3VzcGljaW9uLCBwb3NzaWJseSBhdm9pZGluZyB0byByZWxheSB0byB0 aGVtLgo= --=_north-6135-1280233556-0001-2-- From msk@cloudmark.com Thu Jul 29 04:17: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 620FB28C0F1 for ; Thu, 29 Jul 2010 04:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=-0.419, 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 X3Gsoi5Qx5GN for ; Thu, 29 Jul 2010 04:16:54 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 37CBC3A67E6 for ; Thu, 29 Jul 2010 04:16: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; Thu, 29 Jul 2010 04:17:10 -0700 From: "Murray S. Kucherawy" To: "'marf@ietf.org'" Date: Thu, 29 Jul 2010 04:17:07 -0700 Thread-Topic: OMA SpamRep document Thread-Index: AcsvD5TZ3FgP0ksQSsm4JGICaIdZAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AC8E AiDY BLSP BsMi DOSm DmR+ DvsN D6Jk E6zb F7j0 GGpp Gg7s HTW5 IvUm JAW/ JDe4; 1; bQBhAHIAZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {245C8190-6C95-49F8-83DB-2C3796895B1D}; bQBzAGsAQABjAGwAbwB1AGQAbQBhAHIAawAuAGMAbwBtAA==; Thu, 29 Jul 2010 11:17:07 GMT;TwBNAEEAIABTAHAAYQBtAFIAZQBwACAAZABvAGMAdQBtAGUAbgB0AA== x-cr-puzzleid: {245C8190-6C95-49F8-83DB-2C3796895B1D} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01F716664DEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] OMA SpamRep document 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, 29 Jul 2010 11:17:10 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01F716664DEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As was discussed in the MARF meeting this week, here's a link to the OMA Sp= amRep document's current form. http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/P= ermanent_documents/OMA-TS-SpamRep-V1_0-20100708-D.zip It is under what's called Consistency Review, which is vaguely similar to a= combination of WGLC and IETF LC, so it's late to be providing feedback to = them, but if you have something major you'd like to bring to their attentio= n you can send it to me or to Alex Bobotek (AT&T) who also presented this w= eek. You should certainly read this if you're interested in participating in the= effort to work toward a merged format specification. -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01F716664DEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As was discussed in the MARF meeting this week, here&#= 8217;s a link to the OMA SpamRep document’s current form.

 

http://membe= r.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Permanent_doc= uments/OMA-TS-SpamRep-V1_0-20100708-D.zip

 

It is under what’s called Consistency Review, wh= ich is vaguely similar to a combination of WGLC and IETF LC, so it’s late to= be providing feedback to them, but if you have something major you’d lik= e to bring to their attention you can send it to me or to Alex Bobotek (AT&T= ) who also presented this week.

 

You should certainly read this if you’re interes= ted in participating in the effort to work toward a merged format specification.

 

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C01F716664DEXCHC2corpclo_-- From johnl@iecc.com Sat Jul 31 10:18: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 5DD0A3A69FF for ; Sat, 31 Jul 2010 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.886 X-Spam-Level: X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_20=-0.74, 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 b09SVkP-he5q for ; Sat, 31 Jul 2010 10:18:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id E22F93A69A4 for ; Sat, 31 Jul 2010 10:18:21 -0700 (PDT) Received: (qmail 78529 invoked from network); 31 Jul 2010 17:13:57 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 31 Jul 2010 17:13:57 -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=k1007; olt=johnl@user.iecc.com; bh=c6G5K25ArRmWGLHc35UL71d+6i18rTJSEjBMvK7ma8k=; b=V5a1y7+mqK3dC7QiKs+pG03uw+USeU+6NiLTjlJW7oUfHRDbhRrM7NYTqh+irqi2Epe9LPnc7MFTLwTZn/LAhmvNaHDM148waom6Vp5ruBR7JLeS4eMx56V/orx8GtSGEBGlN6qpycNiqU0DuKmuKuUQeMPiBLVzFuVxUofOHwg= 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=k1007; bh=c6G5K25ArRmWGLHc35UL71d+6i18rTJSEjBMvK7ma8k=; b=os62+k5M2RicrVQb0xQgShPEWe3UIHVm5cN0tPUeaRaP4+fv7bUU20U+u4Iq/h7UjRCP3xXIuenx7DY31NWF4i3C7tOeg5CX5an2/O1HxH5oEw+1Euer7o93mFLT6rh2RXkQORHJEYDLjIvlmbBb9yzZSQ8jQovupCsZ8oqG9cE= Date: 31 Jul 2010 17:18:46 -0000 Message-ID: <20100731171846.44858.qmail@joyce.lan> 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] OMA SpamRep document 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, 31 Jul 2010 17:18:23 -0000 >It is under what's called Consistency Review, which is vaguely >similar to a combination of WGLC and IETF LC, so it's late to be >providing feedback to them, but if you have something major you'd >like to bring to their attention you can send it to me or to Alex >Bobotek (AT&T) who also presented this week. Do you know what the plan is for filling in the parts that say they'll be finished later? It looks to me like it has the usual kitchen sink problem of a spec designed by a committee, but most of the stuff is optional so you can just handle the useful bits. R's, John From alex@bobotek.net Sat Jul 31 22:59:29 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 00DC53A6AE2 for ; Sat, 31 Jul 2010 22:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.273 X-Spam-Level: * X-Spam-Status: No, score=1.273 tagged_above=-999 required=5 tests=[AWL=-3.438, BAYES_50=0.001, DRUGS_MUSCLE=0.01, FRT_SOMA2=2.199, HTML_MESSAGE=0.001, MANGLED_SOMA=2.5] 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 LwwVhr8hhh0I for ; Sat, 31 Jul 2010 22:59:19 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 64EE73A6ADD for ; Sat, 31 Jul 2010 22:58:45 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta02.emeryville.ca.mail.comcast.net with comcast id otvh1e0020S2fkCA2txVu2; Sun, 01 Aug 2010 05:57:29 +0000 Received: from bobo1.bobotek.net ([71.227.197.27]) by omta09.emeryville.ca.mail.comcast.net with comcast id otxU1e0030bxBZT8VtxUCh; Sun, 01 Aug 2010 05:57:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB313E.6C1222DE" Date: Sat, 31 Jul 2010 22:57:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: marf-base and OMA SpamRep convergence and OMA SpamRep comment Thread-Index: AcsvD5TZ3FgP0ksQSsm4JGICaIdZAwCC4IAA References: From: "Alex Bobotek" To: "Murray S. Kucherawy" , Cc: DAVID.K.SMITH@att.com Subject: [marf] marf-base and OMA SpamRep convergence and OMA SpamRep comment 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: Sun, 01 Aug 2010 05:59:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB313E.6C1222DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's some more on Open Mobile Alliance's(OMA's) 'SpamRep' mobile spam reporting draft standard. =20 =20 In the spirit of avoiding industry-fragmentation from competing abuse-reporting standards, I put some thought into whether and how marf-base and SpamRep might converge, particularly in the area of mobile abuse reporting. "Towards Converged Message Abuse Reporting", presented at IETF78.MARF, identifies some key convergence issues along with a proposed roadmap: http://www.ietf.org/proceedings/78/slides/marf-0.pdf. I'd like to encourage any in MARF WG to explore and comment on this here in marf@ietf.org. =20 =20 ------------------------------------ =20 Also, as Murray posted, OMA's SpamRep abuse reporting standard is now under review. Here are some links and more information. The OMA documents are public, however only OMA members can formally submit change requests; but of course Murray and I (who are employed by OMA members and can submit change requests) are interested in everyone's comments. If your company is a member, you can apply for a login (not needed to simply view docs) at http://www.openmobilealliance.org . =20 =20 OMA has the concept of an "enabler." The SpamRep enabler includes: =20 * A draft technical specification: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/Permanent_documents/OMA-AD-SpamRep-V1_0-20090911-D.zip=20 * An XSD for the XML: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/Permanent_documents/OMA-SUP-XSD_spam_rep-V1_0-20100707-D.zip=20 * An architecture document: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/Permanent_documents/OMA-AD-SpamRep-V1_0-20090911-D.zip=20 * Test requirements: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/Permanent_documents/OMA-ETR-SpamRep-V1_0-20100628-D.zip=20 =20 Regards, =20 Alex Bobotek alex@bobotek.net =20 =20 =20 From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, July 29, 2010 4:17 AM To: 'marf@ietf.org' Subject: [marf] OMA SpamRep document =20 As was discussed in the MARF meeting this week, here's a link to the OMA SpamRep document's current form. =20 http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe p/Permanent_documents/OMA-TS-SpamRep-V1_0-20100708-D.zip =20 It is under what's called Consistency Review, which is vaguely similar to a combination of WGLC and IETF LC, so it's late to be providing feedback to them, but if you have something major you'd like to bring to their attention you can send it to me or to Alex Bobotek (AT&T) who also presented this week. =20 You should certainly read this if you're interested in participating in the effort to work toward a merged format specification. =20 -MSK ------_=_NextPart_001_01CB313E.6C1222DE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here’s some = more on Open Mobile Alliance’s(OMA’s) ‘SpamRep’ mobile spam reporting draft standard. 

 

In the spirit of = avoiding industry-fragmentation from competing abuse-reporting standards, I put = some thought into whether and how marf-base and SpamRep might converge, = particularly in the area of mobile abuse reporting.  “Towards Converged = Message Abuse Reporting”, presented at IETF78.MARF,  identifies some = key convergence issues along with a proposed roadmap:  http://www.= ietf.org/proceedings/78/slides/marf-0.pdf.  I’d like to encourage any in MARF WG to explore and comment on = this here in marf@ietf.org.  =

 

------------------------------------

 

Also, as Murray = posted, OMA’s SpamRep abuse reporting standard is now under review.  Here are = some links and more information.  The OMA documents are public, however only = OMA members can formally submit change requests; but of course Murray and I = (who are employed by OMA members and can submit change requests) are interested = in everyone’s comments.  If your company is a member, you can = apply for a login (not needed to simply view docs) at http://www.openmobilealliance.= org . 

 

OMA has the concept = of an “enabler.”  The SpamRep enabler includes:

 

·         A draft = technical specification:  http://m= ember.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Permane= nt_documents/OMA-AD-SpamRep-V1_0-20090911-D.zip

·         An XSD for = the XML:  ht= tp://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/P= ermanent_documents/OMA-SUP-XSD_spam_rep-V1_0-20100707-D.zip

·         An = architecture document:  http://m= ember.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Permane= nt_documents/OMA-AD-SpamRep-V1_0-20090911-D.zip

·         Test requirements:  http://= member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Perman= ent_documents/OMA-ETR-SpamRep-V1_0-20100628-D.zip

 

Regards,

 

Alex = Bobotek

alex@bobotek.net

 

 

 

From:= marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of = Murray S. Kucherawy
Sent: Thursday, July 29, 2010 4:17 AM
To: 'marf@ietf.org'
Subject: [marf] OMA SpamRep document

 

As was discussed in the MARF meeting this week, = here’s a link to the OMA SpamRep document’s current form.

 

http://m= ember.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Permane= nt_documents/OMA-TS-SpamRep-V1_0-20100708-D.zip

 

It is under what’s called Consistency Review, = which is vaguely similar to a combination of WGLC and IETF LC, so it’s late = to be providing feedback to them, but if you have something major you’d = like to bring to their attention you can send it to me or to Alex Bobotek = (AT&T) who also presented this week.

 

You should certainly read this if you’re = interested in participating in the effort to work toward a merged format = specification.

 

-MSK

------_=_NextPart_001_01CB313E.6C1222DE--