From pars.mutaf@gmail.com Wed Jul 8 08:34:15 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6D13A6B6B for ; Wed, 8 Jul 2009 08:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=1.223, 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 Zp4LhHXTnZKS for ; Wed, 8 Jul 2009 08:34:14 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id CED753A6B5C for ; Wed, 8 Jul 2009 08:33:52 -0700 (PDT) Received: by ewy26 with SMTP id 26so1710511ewy.37 for ; Wed, 08 Jul 2009 08:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ntW5Jq2iaI3aSVphPYpC28XxjjpQUrY8vqTd4Hy1oEg=; b=H/zKebohr1BXvmBuwNO4zBkPRvjiHYKX+r4QyA5YCrniyY5YI5lOZCBaH50uZrTs3F a3D/5X5Ma0YJKK72yuqtnUmW8tIYDI2kP0BdxkPIfDjhyjzsdsRBI1bdVSgNqu5SwcLG Yo+0x6TC1+baZCOo4a2cVpvdanCitTmCfbluw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=JIe+MkuOMyj7dA1iv5ua+JZmqMKFW7+K5wUKRcbRmukFS3SBU2NRPXA9Q2FpVw5V9k VygFAADbTrtIQ+sOlmSdui1isc63WNKqI8JryCm4/sD8rg3T3Y87whw7q2w5pJUmiOSx 6a1CHWTZLPGJ4MED2CV6C6OwzZ8g6yl5xU8XQ= MIME-Version: 1.0 Received: by 10.211.199.11 with SMTP id b11mr8187857ebq.57.1247067257386; Wed, 08 Jul 2009 08:34:17 -0700 (PDT) Date: Wed, 8 Jul 2009 18:34:17 +0300 Message-ID: <18a603a60907080834x46599d2fmb54763f0857df09c@mail.gmail.com> From: Pars Mutaf To: Rucus BoF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Rucus] SPIT from operator X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:34:15 -0000 Hello, I my country, subscribers receive a lot of SPIT from their operators. In my cell phone experience, the operator itself is the most serious SPIT problem. This makes me think that SPIT solutions must be operator independent. Would you have any comments on that? What is the situation in other countries? Which solutions can be applied? Thanks pars From joachim.charzinski@nsn.com Thu Jul 9 00:01:01 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE37C3A6AD0 for ; Thu, 9 Jul 2009 00:01: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=[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 7+Ng17BjOnFb for ; Thu, 9 Jul 2009 00:01:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 82C803A6873 for ; Thu, 9 Jul 2009 00:01:00 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6971QLT008708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Jul 2009 09:01:26 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6971M5Y009706; Thu, 9 Jul 2009 09:01:26 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 09:01:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 09:01:30 +0200 Message-ID: In-Reply-To: <18a603a60907080834x46599d2fmb54763f0857df09c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] SPIT from operator Thread-Index: Acn/4aNzP2t2hudtSm+f+cGRNKCrpAAe6uyA References: <18a603a60907080834x46599d2fmb54763f0857df09c@mail.gmail.com> From: "Charzinski, Joachim (NSN - DE/Munich)" To: "ext Pars Mutaf" , "Rucus BoF" X-OriginalArrivalTime: 09 Jul 2009 07:01:25.0538 (UTC) FILETIME=[1314E820:01CA0063] Subject: Re: [Rucus] SPIT from operator X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 07:01:02 -0000 Hi Pars, > This makes me think that SPIT solutions must be operator independent. I think this is generalizing too much. Solutions against the type of=20 SPIT you mention will have to be operator independent (possibly also=20 involving some regulatory power that forces operators to respect=20 entries on "don't call" lists). The same will be true for the kind of=20 Spam distribution services we find with the postal service ("distribute=20 this to every household with a street address") - wherever the operator=20 actually makes money from Spam or SPIT, it will be necessary to have an=20 operator independent solution for fighting Spam and SPIT.=20 On the other hand, it is probably the operators that are currently=20 preventing large scale SPIT by performing ingress address filtering and=20 enforcing rate caps on SIP signalling. Also, in a traditional telephony=20 environment, it would be the operator that strips off the origin address = for anonymous calls, so the operator has more power in filtering SPIT=20 than the end user / end device would have.=20 Therefore I think we need two solutions that help both parties - the=20 operator and the end user - to fight SPIT independently. They may even=20 cooperate, but they cannot completely substitute one another.=20 > What is the situation in other countries?=20 I am living in germany, and I used to get a lot of cold calls, most of=20 them machine assisted but actually connecting to a personal agent. Only=20 a few calls were completely automated. My cold calls frequency has = dropped=20 drastically since I started asking the callers for permission to record=20 the calls for usage in court. They seem to have deleted my number from=20 their address lists.=20 If operators didn't interfer (see the above mentioned rate caps and=20 address filters), we would probably get a lot more calls, as there are=20 a lot of VoIP contracts around where you can reach most of the fixed=20 phone network within a flat rate.=20 Best regards Joachim.=20 -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf = Of ext Pars Mutaf Sent: Wednesday, July 08, 2009 5:34 PM To: Rucus BoF Subject: [Rucus] SPIT from operator Hello, I my country, subscribers receive a lot of SPIT from their operators. In my cell phone experience, the operator itself is the most serious SPIT problem. This makes me think that SPIT solutions must be operator independent. Would you have any comments on that? What is the situation in other countries? Which solutions can be applied? Thanks pars _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus ---------------------------------------------------------- Joachim Charzinski Nokia Siemens Networks Research, Technology and Platforms=20 Research & Technology / Network Evolution =20 St.-Martin-Str. 53 Post box: D-80240 Muenchen D-81541 Muenchen Germany Tel: +49 89 636 79902 Joachim.Charzinski@nsn.com=20 http://www.nokiasiemensnetworks.com/global/ Think before you print Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 WEEE-Reg.-Nr.: DE 52984304 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri = Kivinen Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 From pars.mutaf@gmail.com Thu Jul 9 03:46:21 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03A13A6B40 for ; Thu, 9 Jul 2009 03:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.612, 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 VUfIQXpR8tkQ for ; Thu, 9 Jul 2009 03:46:20 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 3891E3A67E3 for ; Thu, 9 Jul 2009 03:46:19 -0700 (PDT) Received: by ewy26 with SMTP id 26so76808ewy.37 for ; Thu, 09 Jul 2009 03:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w4RI7r7nIc/0nBkOJB889D5Ggc/n6b7NWyT3AJGf7L8=; b=Gt3ZxfKru3i0mJm0cC5b7xZp1L49FTOXMQf9f6+9+IEnL8476D4WMgFYFuwYFg0xGk rigaw33zFwsvp5JOYBmBOMgeiLbp0w6rOWs5s6ZCTn9+s+BC9EpihMX1hcTsxlKHbCxU HBrCwzFFXSUJa3qgBLikh3AR9e8hhan1A38SI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=X2FqyhZKwXyXkUdJ2+KpHbs9I3Yyehm+qvjj/MWe490+SnayhtMH2cjWwOCY0q9S3Q 88HGGIrTr4tJidd3YJloNnoMlDq42t+FbagAqHXk+yz9LUH70EuoUfoSyEM/j84P+/j0 xYEYxqknbBZ7CVAj0XMCaiyNaM2TKdK81z47Q= MIME-Version: 1.0 Received: by 10.210.132.3 with SMTP id f3mr757778ebd.64.1247136403882; Thu, 09 Jul 2009 03:46:43 -0700 (PDT) In-Reply-To: References: <18a603a60907080834x46599d2fmb54763f0857df09c@mail.gmail.com> Date: Thu, 9 Jul 2009 13:46:43 +0300 Message-ID: <18a603a60907090346i21790a3eu677e6f7d1c77249e@mail.gmail.com> From: Pars Mutaf To: "Charzinski, Joachim (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rucus BoF Subject: Re: [Rucus] SPIT from operator X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 10:46:21 -0000 Hi Joachim, To clarify, I don't receive calls but messages from the operator about new services, new songs available as ring tone, and various non-sense stuff. I would like to filter these messages on my cell phone. As far as I know, there this no easy way t= o inform the operator that I'm not interested in these messages. We seem to agree that the cell phone should be able to filter operator's SP= IT. Please see below for more... On Thu, Jul 9, 2009 at 10:01 AM, Charzinski, Joachim (NSN - DE/Munich) wrote: > Hi Pars, > >> This makes me think that SPIT solutions must be operator independent. > > I think this is generalizing too much. Solutions against the type of > SPIT you mention will have to be operator independent (possibly also > involving some regulatory power that forces operators to respect > entries on "don't call" lists). The same will be true for the kind of > Spam distribution services we find with the postal service ("distribute > this to every household with a street address") - wherever the operator > actually makes money from Spam or SPIT, it will be necessary to have an > operator independent solution for fighting Spam and SPIT. > > On the other hand, it is probably the operators that are currently > preventing large scale SPIT by performing ingress address filtering and > enforcing rate caps on SIP signalling. Also, in a traditional telephony > environment, it would be the operator that strips off the origin address > for anonymous calls, so the operator has more power in filtering SPIT > than the end user / end device would have. I am not sure that the operator is willing to filter SPIT. This is open to discussion. By the way, I note here that in your operator-based filtering approach, the operator should forward the messages marked as SPIT to the target cell phon= e anyways. This is because the false positive probability is never zero. The target user should make the decision whether or not a message is SPIT before deleting a message from inbox. As a consequence, this makes be believe that operator-based filtering is no= t really necessary. Just forward all messages to the target cell phone, the target cell phone can filter them and store the ones marked as SPIT for eventual user inspection. I missed something? Thanks pars > > Therefore I think we need two solutions that help both parties - the > operator and the end user - to fight SPIT independently. They may even > cooperate, but they cannot completely substitute one another. > >> What is the situation in other countries? > > I am living in germany, and I used to get a lot of cold calls, most of > them machine assisted but actually connecting to a personal agent. Only > a few calls were completely automated. My cold calls frequency has droppe= d > drastically since I started asking the callers for permission to record > the calls for usage in court. They seem to have deleted my number from > their address lists. > If operators didn't interfer (see the above mentioned rate caps and > address filters), we would probably get a lot more calls, as there are > a lot of VoIP contracts around where you can reach most of the fixed > phone network within a flat rate. > > Best regards > > Joachim. > > > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of= ext Pars Mutaf > Sent: Wednesday, July 08, 2009 5:34 PM > To: Rucus BoF > Subject: [Rucus] SPIT from operator > > Hello, > > I my country, subscribers receive a lot of SPIT from their operators. > In my cell phone experience, the operator itself is the most serious > SPIT problem. > > This makes me think that SPIT solutions must be operator independent. > > Would you have any comments on that? What is the situation in other > countries? Which solutions can be applied? > > Thanks > > pars > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > > ---------------------------------------------------------- > Joachim Charzinski > > Nokia Siemens Networks > Research, Technology and Platforms > Research & Technology / Network Evolution > > St.-Martin-Str. 53 > Post box: D-80240 Muenchen > D-81541 Muenchen > Germany > Tel: +49 89 636 79902 > > Joachim.Charzinski@nsn.com > http://www.nokiasiemensnetworks.com/global/ > > Think before you print > > Nokia Siemens Networks GmbH & Co. KG > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 > WEEE-Reg.-Nr.: DE 52984304 > > Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens N= etworks Management GmbH > Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke > Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kiv= inen > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 > From dschwartz@xconnect.net Thu Jul 9 03:52:02 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0968D3A6A7B for ; Thu, 9 Jul 2009 03:52:02 -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] 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 3IufjMfsr3Tc for ; Thu, 9 Jul 2009 03:52:00 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id 35C303A6A93 for ; Thu, 9 Jul 2009 03:51:59 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 9 Jul 2009 13:52:24 +0300 From: David Schwartz To: Pars Mutaf , "Charzinski, Joachim (NSN - DE/Munich)" Date: Thu, 9 Jul 2009 13:52:21 +0300 Thread-Topic: [Rucus] SPIT from operator Thread-Index: AcoAgpUQG3Bft5DFTG6kaNdRTmFy/wAAGvEg Message-ID: <6EA53FAD386F9D46B97D49BFE148D5148CE24C@ISR-JLM-MAIL1.xconnect.co.il> In-Reply-To: <18a603a60907090346i21790a3eu677e6f7d1c77249e@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rucus BoF Subject: Re: [Rucus] SPIT from operator X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 10:52:02 -0000 It's a shame Dan Wings proposal (http://tools.ietf.org/html/draft-wing-sipp= ing-spam-score-02) never went anywhere. Basically, it argues that the opera= tor simply "marks" or "scores" a call and passes it on to the recipient for= him/her to make the actual accept/reject decision. D. -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of P= ars Mutaf Sent: Thursday, July 09, 2009 1:47 PM To: Charzinski, Joachim (NSN - DE/Munich) Cc: Rucus BoF Subject: Re: [Rucus] SPIT from operator Hi Joachim, To clarify, I don't receive calls but messages from the operator about new services, new songs available as ring tone, and various non-sense stuff. I would like to filter these messages on my cell phone. As far as I know, there this no easy way t= o inform the operator that I'm not interested in these messages. We seem to agree that the cell phone should be able to filter operator's SP= IT. Please see below for more... On Thu, Jul 9, 2009 at 10:01 AM, Charzinski, Joachim (NSN - DE/Munich) wrote: > Hi Pars, > >> This makes me think that SPIT solutions must be operator independent. > > I think this is generalizing too much. Solutions against the type of > SPIT you mention will have to be operator independent (possibly also > involving some regulatory power that forces operators to respect > entries on "don't call" lists). The same will be true for the kind of > Spam distribution services we find with the postal service ("distribute > this to every household with a street address") - wherever the operator > actually makes money from Spam or SPIT, it will be necessary to have an > operator independent solution for fighting Spam and SPIT. > > On the other hand, it is probably the operators that are currently > preventing large scale SPIT by performing ingress address filtering and > enforcing rate caps on SIP signalling. Also, in a traditional telephony > environment, it would be the operator that strips off the origin address > for anonymous calls, so the operator has more power in filtering SPIT > than the end user / end device would have. I am not sure that the operator is willing to filter SPIT. This is open to discussion. By the way, I note here that in your operator-based filtering approach, the operator should forward the messages marked as SPIT to the target cell phon= e anyways. This is because the false positive probability is never zero. The target user should make the decision whether or not a message is SPIT before deleting a message from inbox. As a consequence, this makes be believe that operator-based filtering is no= t really necessary. Just forward all messages to the target cell phone, the target cell phone can filter them and store the ones marked as SPIT for eventual user inspection. I missed something? Thanks pars > > Therefore I think we need two solutions that help both parties - the > operator and the end user - to fight SPIT independently. They may even > cooperate, but they cannot completely substitute one another. > >> What is the situation in other countries? > > I am living in germany, and I used to get a lot of cold calls, most of > them machine assisted but actually connecting to a personal agent. Only > a few calls were completely automated. My cold calls frequency has droppe= d > drastically since I started asking the callers for permission to record > the calls for usage in court. They seem to have deleted my number from > their address lists. > If operators didn't interfer (see the above mentioned rate caps and > address filters), we would probably get a lot more calls, as there are > a lot of VoIP contracts around where you can reach most of the fixed > phone network within a flat rate. > > Best regards > > Joachim. > > > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of= ext Pars Mutaf > Sent: Wednesday, July 08, 2009 5:34 PM > To: Rucus BoF > Subject: [Rucus] SPIT from operator > > Hello, > > I my country, subscribers receive a lot of SPIT from their operators. > In my cell phone experience, the operator itself is the most serious > SPIT problem. > > This makes me think that SPIT solutions must be operator independent. > > Would you have any comments on that? What is the situation in other > countries? Which solutions can be applied? > > Thanks > > pars > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > > ---------------------------------------------------------- > Joachim Charzinski > > Nokia Siemens Networks > Research, Technology and Platforms > Research & Technology / Network Evolution > > St.-Martin-Str. 53 > Post box: D-80240 Muenchen > D-81541 Muenchen > Germany > Tel: +49 89 636 79902 > > Joachim.Charzinski@nsn.com > http://www.nokiasiemensnetworks.com/global/ > > Think before you print > > Nokia Siemens Networks GmbH & Co. KG > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 > WEEE-Reg.-Nr.: DE 52984304 > > Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens N= etworks Management GmbH > Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke > Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kiv= inen > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From ranjit@motorola.com Thu Jul 9 04:00:36 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF573A69E2 for ; Thu, 9 Jul 2009 04:00:36 -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 9X54Zhcse3IT for ; Thu, 9 Jul 2009 04:00:35 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id B3F9A3A67E3 for ; Thu, 9 Jul 2009 04:00:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1247137254!24065141!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 14174 invoked from network); 9 Jul 2009 11:00:55 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-14.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2009 11:00:55 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id n69B0sme011638 for ; Thu, 9 Jul 2009 04:00:54 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n69B0s8p026017 for ; Thu, 9 Jul 2009 06:00:54 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n69B0qN4025994 for ; Thu, 9 Jul 2009 06:00:53 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 19:00:30 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B07DACF3C@ZMY16EXM66.ds.mot.com> In-Reply-To: <6EA53FAD386F9D46B97D49BFE148D5148CE24C@ISR-JLM-MAIL1.xconnect.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] SPIT from operator Thread-Index: AcoAgpUQG3Bft5DFTG6kaNdRTmFy/wAAGvEgAAAi9JA= References: <18a603a60907090346i21790a3eu677e6f7d1c77249e@mail.gmail.com> <6EA53FAD386F9D46B97D49BFE148D5148CE24C@ISR-JLM-MAIL1.xconnect.co.il> From: "Avasarala Ranjit-A20990" To: "David Schwartz" , "Pars Mutaf" , "Charzinski, Joachim (NSN - DE/Munich)" X-CFilter-Loop: Reflected Cc: Rucus BoF Subject: Re: [Rucus] SPIT from operator X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:00:36 -0000 Hi Actually operator can come up with a service of helping the teminating = users (called users) to identify the unwanted callers and help them = register the unwanted caller identity with the network. Once registered, = the calls from the particular caller who was registered as "unwanted" = would be prevented from calling. This could be one way of reducing SPIT. The draft: = http://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-= icb-00 proposes a solution of appending a SIP Reason header with new = protocol value "block" to indicate to network to block the calling user = from future calling. We are in the process of updating this document and hence comments are = welcome. Thanks Regards Ranjit -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf = Of David Schwartz Sent: Thursday, July 09, 2009 4:22 PM To: Pars Mutaf; Charzinski, Joachim (NSN - DE/Munich) Cc: Rucus BoF Subject: Re: [Rucus] SPIT from operator It's a shame Dan Wings proposal = (http://tools.ietf.org/html/draft-wing-sipping-spam-score-02) never went = anywhere. Basically, it argues that the operator simply "marks" or = "scores" a call and passes it on to the recipient for him/her to make = the actual accept/reject decision. D. -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf = Of Pars Mutaf Sent: Thursday, July 09, 2009 1:47 PM To: Charzinski, Joachim (NSN - DE/Munich) Cc: Rucus BoF Subject: Re: [Rucus] SPIT from operator Hi Joachim, To clarify, I don't receive calls but messages from the operator about = new services, new songs available as ring tone, and various non-sense = stuff. I would like to filter these messages on my cell phone. As far as = I know, there this no easy way to inform the operator that I'm not = interested in these messages. We seem to agree that the cell phone should be able to filter operator's = SPIT. Please see below for more... On Thu, Jul 9, 2009 at 10:01 AM, Charzinski, Joachim (NSN - = DE/Munich) wrote: > Hi Pars, > >> This makes me think that SPIT solutions must be operator independent. > > I think this is generalizing too much. Solutions against the type of=20 > SPIT you mention will have to be operator independent (possibly also=20 > involving some regulatory power that forces operators to respect=20 > entries on "don't call" lists). The same will be true for the kind of=20 > Spam distribution services we find with the postal service=20 > ("distribute this to every household with a street address") -=20 > wherever the operator actually makes money from Spam or SPIT, it will=20 > be necessary to have an operator independent solution for fighting = Spam and SPIT. > > On the other hand, it is probably the operators that are currently=20 > preventing large scale SPIT by performing ingress address filtering=20 > and enforcing rate caps on SIP signalling. Also, in a traditional=20 > telephony environment, it would be the operator that strips off the=20 > origin address for anonymous calls, so the operator has more power in=20 > filtering SPIT than the end user / end device would have. I am not sure that the operator is willing to filter SPIT. This is open = to discussion. By the way, I note here that in your operator-based filtering approach, = the operator should forward the messages marked as SPIT to the target = cell phone anyways. This is because the false positive probability is = never zero. The target user should make the decision whether or not a message is = SPIT before deleting a message from inbox. As a consequence, this makes be believe that operator-based filtering is = not really necessary. Just forward all messages to the target cell = phone, the target cell phone can filter them and store the ones marked = as SPIT for eventual user inspection. I missed something? Thanks pars > > Therefore I think we need two solutions that help both parties - the=20 > operator and the end user - to fight SPIT independently. They may even = > cooperate, but they cannot completely substitute one another. > >> What is the situation in other countries? > > I am living in germany, and I used to get a lot of cold calls, most of = > them machine assisted but actually connecting to a personal agent.=20 > Only a few calls were completely automated. My cold calls frequency=20 > has dropped drastically since I started asking the callers for=20 > permission to record the calls for usage in court. They seem to have=20 > deleted my number from their address lists. > If operators didn't interfer (see the above mentioned rate caps and=20 > address filters), we would probably get a lot more calls, as there are = > a lot of VoIP contracts around where you can reach most of the fixed=20 > phone network within a flat rate. > > Best regards > > Joachim. > > > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf = > Of ext Pars Mutaf > Sent: Wednesday, July 08, 2009 5:34 PM > To: Rucus BoF > Subject: [Rucus] SPIT from operator > > Hello, > > I my country, subscribers receive a lot of SPIT from their operators. > In my cell phone experience, the operator itself is the most serious=20 > SPIT problem. > > This makes me think that SPIT solutions must be operator independent. > > Would you have any comments on that? What is the situation in other=20 > countries? Which solutions can be applied? > > Thanks > > pars > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > > ---------------------------------------------------------- > Joachim Charzinski > > Nokia Siemens Networks > Research, Technology and Platforms > Research & Technology / Network Evolution > > St.-Martin-Str. 53 > Post box: D-80240 Muenchen > D-81541 Muenchen > Germany > Tel: +49 89 636 79902 > > Joachim.Charzinski@nsn.com > http://www.nokiasiemensnetworks.com/global/ > > Think before you print > > Nokia Siemens Networks GmbH & Co. KG > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 > WEEE-Reg.-Nr.: DE 52984304 > > Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia = Siemens=20 > Networks Management GmbH Gesch=E4ftsleitung / Board of Directors: = Lydia=20 > Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of=20 > supervisory board: Lauri Kivinen Sitz der Gesellschaft: M=FCnchen /=20 > Registered office: Munich > Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From pars.mutaf@gmail.com Thu Jul 9 04:41:21 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F013A6A95 for ; Thu, 9 Jul 2009 04:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, 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 WDxLrsZOBB-5 for ; Thu, 9 Jul 2009 04:41:20 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 446753A691A for ; Thu, 9 Jul 2009 04:41:20 -0700 (PDT) Received: by ewy26 with SMTP id 26so112376ewy.37 for ; Thu, 09 Jul 2009 04:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=F0SrX8771STUOQqmNaiIgiyuxVVFY8FSV2AK8YhlLWQ=; b=H42sS2pNHxliL2yDVwFEFMarHdKCRr3PPxC+K07VTmjDjQQJGptuUeKbn3yqZ3In9e HWa5f9BVGhWv5eWwlzv017U1rTqTohjE5RXuziM74dQUPwsQqOndDVbcCpqPs+RNgsqA ANKDCnsPXNuZNhmv2ot8BTWfezVUoNrSTi9ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=poJ5sqmy7KpaIHFl8KhMEt5s0YMRTWjvW5SaVNVGDsYAWkndtPd/8HZsf55LBkFXsR iOf+Yo5SXFqWO/a6s0e1/dXhJFlpPTe4Agi3R8yaSPZavH7O8Vd+jhYZIpQ6BygKS6rf seeGHi4K/T7WdMl9IUxwd591V3oOSftbthTM4= MIME-Version: 1.0 Received: by 10.211.177.16 with SMTP id e16mr635808ebp.30.1247139705069; Thu, 09 Jul 2009 04:41:45 -0700 (PDT) Date: Thu, 9 Jul 2009 14:41:45 +0300 Message-ID: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com> From: Pars Mutaf To: David Schwartz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rucus BoF Subject: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT from operator) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:41:22 -0000 On Thu, Jul 9, 2009 at 1:52 PM, David Schwartz wrot= e: > It's a shame Dan Wings proposal (http://tools.ietf.org/html/draft-wing-si= pping-spam-score-02) never went anywhere. Basically, it > argues that the operator simply "marks" or "scores" a call and passes it = on to the recipient for him/her to make the actual > accept/reject decision. Sorry I believe I missed that document. What is the advantage of operator marking and forwarding the message, over the cell phone marking the message and storing marked as SPIT? Perhaps the operator would have more information about SPITers and can perform better filtering on behalf of users? (I'm not sure about that). This could be clarified? Or it is an energy conservation issue? Thanks, pars > > D. > > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of= Pars Mutaf > Sent: Thursday, July 09, 2009 1:47 PM > To: Charzinski, Joachim (NSN - DE/Munich) > Cc: Rucus BoF > Subject: Re: [Rucus] SPIT from operator > > Hi Joachim, > > To clarify, I don't receive calls but messages from the operator about > new services, > new songs available as ring tone, and various non-sense stuff. I would > like to filter > these messages on my cell phone. As far as I know, there this no easy way= to > inform the operator that I'm not interested in these messages. > > We seem to agree that the cell phone should be able to filter operator's = SPIT. > > Please see below for more... > > On Thu, Jul 9, 2009 at 10:01 AM, Charzinski, Joachim (NSN - > DE/Munich) wrote: >> Hi Pars, >> >>> This makes me think that SPIT solutions must be operator independent. >> >> I think this is generalizing too much. Solutions against the type of >> SPIT you mention will have to be operator independent (possibly also >> involving some regulatory power that forces operators to respect >> entries on "don't call" lists). The same will be true for the kind of >> Spam distribution services we find with the postal service ("distribute >> this to every household with a street address") - wherever the operator >> actually makes money from Spam or SPIT, it will be necessary to have an >> operator independent solution for fighting Spam and SPIT. >> >> On the other hand, it is probably the operators that are currently >> preventing large scale SPIT by performing ingress address filtering and >> enforcing rate caps on SIP signalling. Also, in a traditional telephony >> environment, it would be the operator that strips off the origin address >> for anonymous calls, so the operator has more power in filtering SPIT >> than the end user / end device would have. > > I am not sure that the operator is willing to filter SPIT. This is > open to discussion. > > By the way, I note here that in your operator-based filtering approach, t= he > operator should forward the messages marked as SPIT to the target cell ph= one > anyways. This is because the false positive probability is never zero. > The target user should make the decision whether or not a message is SPIT > before deleting a message from inbox. > > As a consequence, this makes be believe that operator-based filtering is = not > really necessary. Just forward all messages to the target cell phone, the > target cell phone can filter them and store the ones marked as SPIT for > eventual user inspection. > > I missed something? > > Thanks > > pars > > > > >> >> Therefore I think we need two solutions that help both parties - the >> operator and the end user - to fight SPIT independently. They may even >> cooperate, but they cannot completely substitute one another. >> >>> What is the situation in other countries? >> >> I am living in germany, and I used to get a lot of cold calls, most of >> them machine assisted but actually connecting to a personal agent. Only >> a few calls were completely automated. My cold calls frequency has dropp= ed >> drastically since I started asking the callers for permission to record >> the calls for usage in court. They seem to have deleted my number from >> their address lists. >> If operators didn't interfer (see the above mentioned rate caps and >> address filters), we would probably get a lot more calls, as there are >> a lot of VoIP contracts around where you can reach most of the fixed >> phone network within a flat rate. >> >> Best regards >> >> Joachim. >> >> >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf O= f ext Pars Mutaf >> Sent: Wednesday, July 08, 2009 5:34 PM >> To: Rucus BoF >> Subject: [Rucus] SPIT from operator >> >> Hello, >> >> I my country, subscribers receive a lot of SPIT from their operators. >> In my cell phone experience, the operator itself is the most serious >> SPIT problem. >> >> This makes me think that SPIT solutions must be operator independent. >> >> Would you have any comments on that? What is the situation in other >> countries? Which solutions can be applied? >> >> Thanks >> >> pars >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> >> ---------------------------------------------------------- >> Joachim Charzinski >> >> Nokia Siemens Networks >> Research, Technology and Platforms >> Research & Technology / Network Evolution >> >> St.-Martin-Str. 53 >> Post box: D-80240 Muenchen >> D-81541 Muenchen >> Germany >> Tel: +49 89 636 79902 >> >> Joachim.Charzinski@nsn.com >> http://www.nokiasiemensnetworks.com/global/ >> >> Think before you print >> >> Nokia Siemens Networks GmbH & Co. KG >> Sitz der Gesellschaft: M=FCnchen / Registered office: Munich >> Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 >> WEEE-Reg.-Nr.: DE 52984304 >> >> Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH >> Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke >> Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Ki= vinen >> Sitz der Gesellschaft: M=FCnchen / Registered office: Munich >> Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 >> > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > From pars.mutaf@gmail.com Thu Jul 9 04:49:51 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6E63A6CC1 for ; Thu, 9 Jul 2009 04:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 rPsvYL4hUbpg for ; Thu, 9 Jul 2009 04:49:50 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id B69C328C19D for ; Thu, 9 Jul 2009 04:49:07 -0700 (PDT) Received: by ewy26 with SMTP id 26so117689ewy.37 for ; Thu, 09 Jul 2009 04:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a6vOJ3IvlAvdhaqg4TgwutJx4uIdgLwx2egrKlm1p38=; b=rMpDxN6uiW1Ukqm/F1RwIvKPnYhrJPX9H6LkESyWIKHUtNTXygNN4LGLzZiOGw8yiN iFed/qnlQ7mQKCWx3FPk9Ms2lkvT2qRxwsIRlXBf5SN5YQVujfadoBE6ott6f0Kcex+G LQqLMK/eXeuPKW3yMSf0U19B0+jEJENfoogfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TQEQpdm36yOw609cHauyTO+qBldN3rNEbHaK4NB8DSe41pW5FuUblzOZ524Cmh2/5q DwvOlGtBPpszbnuH2vmMm1tR+EzkP5DgtBXPWOWLVcKfAvRouygo1M2tyNfXJMFB2uKr uq9ptW73SQa85yxhWGGxgvX3QCECIi3qgYx88= MIME-Version: 1.0 Received: by 10.210.43.11 with SMTP id q11mr9482043ebq.15.1247140171938; Thu, 09 Jul 2009 04:49:31 -0700 (PDT) In-Reply-To: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com> References: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com> Date: Thu, 9 Jul 2009 14:49:31 +0300 Message-ID: <18a603a60907090449i50853e2ane40291095aaf83f7@mail.gmail.com> From: Pars Mutaf To: Avasarala Ranjit-A20990 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rucus BoF Subject: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT from operator) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:49:51 -0000 Hello, On Thu, Jul 9, 2009 at 2:00 PM, Avasarala Ranjit-A20990 wrote: > Hi > > Actually operator can come up with a service of helping the teminating us= ers (called users) to identify the unwanted callers and help them register = the unwanted caller identity with the network. Once registered, the calls f= rom the particular caller who was registered as "unwanted" would be prevent= ed from calling. This could be one way of reducing SPIT. > > The draft: http://tools.ietf.org/html/draft-avasarala-sipping-reason-head= er-dynamic-icb-00 proposes a solution of appending a SIP Reason header with= new protocol value "block" to indicate to network to block the calling use= r from future calling. > > We are in the process of updating this document and hence comments are we= lcome. I am not sure to understand why the target cell phone doesn't drop the unwanted call itself. Thanks, pars > > Thanks > > Regards > Ranjit > > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of= David Schwartz > Sent: Thursday, July 09, 2009 4:22 PM > To: Pars Mutaf; Charzinski, Joachim (NSN - DE/Munich) > Cc: Rucus BoF > Subject: Re: [Rucus] SPIT from operator > > It's a shame Dan Wings proposal (http://tools.ietf.org/html/draft-wing-si= pping-spam-score-02) never went anywhere. Basically, it argues that the ope= rator simply "marks" or "scores" a call and passes it on to the recipient f= or him/her to make the actual accept/reject decision. > > D. > > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of= Pars Mutaf > Sent: Thursday, July 09, 2009 1:47 PM > To: Charzinski, Joachim (NSN - DE/Munich) > Cc: Rucus BoF > Subject: Re: [Rucus] SPIT from operator > > Hi Joachim, > > To clarify, I don't receive calls but messages from the operator about ne= w services, new songs available as ring tone, and various non-sense stuff. = I would like to filter these messages on my cell phone. As far as I know, t= here this no easy way to inform the operator that I'm not interested in the= se messages. > > We seem to agree that the cell phone should be able to filter operator's = SPIT. > > Please see below for more... > > On Thu, Jul 9, 2009 at 10:01 AM, Charzinski, Joachim (NSN - DE/Munich) wrote: >> Hi Pars, >> >>> This makes me think that SPIT solutions must be operator independent. >> >> I think this is generalizing too much. Solutions against the type of >> SPIT you mention will have to be operator independent (possibly also >> involving some regulatory power that forces operators to respect >> entries on "don't call" lists). The same will be true for the kind of >> Spam distribution services we find with the postal service >> ("distribute this to every household with a street address") - >> wherever the operator actually makes money from Spam or SPIT, it will >> be necessary to have an operator independent solution for fighting Spam = and SPIT. >> >> On the other hand, it is probably the operators that are currently >> preventing large scale SPIT by performing ingress address filtering >> and enforcing rate caps on SIP signalling. Also, in a traditional >> telephony environment, it would be the operator that strips off the >> origin address for anonymous calls, so the operator has more power in >> filtering SPIT than the end user / end device would have. > > I am not sure that the operator is willing to filter SPIT. This is open t= o discussion. > > By the way, I note here that in your operator-based filtering approach, t= he operator should forward the messages marked as SPIT to the target cell p= hone anyways. This is because the false positive probability is never zero. > The target user should make the decision whether or not a message is SPIT= before deleting a message from inbox. > > As a consequence, this makes be believe that operator-based filtering is = not really necessary. Just forward all messages to the target cell phone, t= he target cell phone can filter them and store the ones marked as SPIT for = eventual user inspection. > > I missed something? > > Thanks > > pars > > > > >> >> Therefore I think we need two solutions that help both parties - the >> operator and the end user - to fight SPIT independently. They may even >> cooperate, but they cannot completely substitute one another. >> >>> What is the situation in other countries? >> >> I am living in germany, and I used to get a lot of cold calls, most of >> them machine assisted but actually connecting to a personal agent. >> Only a few calls were completely automated. My cold calls frequency >> has dropped drastically since I started asking the callers for >> permission to record the calls for usage in court. They seem to have >> deleted my number from their address lists. >> If operators didn't interfer (see the above mentioned rate caps and >> address filters), we would probably get a lot more calls, as there are >> a lot of VoIP contracts around where you can reach most of the fixed >> phone network within a flat rate. >> >> Best regards >> >> Joachim. >> >> >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf >> Of ext Pars Mutaf >> Sent: Wednesday, July 08, 2009 5:34 PM >> To: Rucus BoF >> Subject: [Rucus] SPIT from operator >> >> Hello, >> >> I my country, subscribers receive a lot of SPIT from their operators. >> In my cell phone experience, the operator itself is the most serious >> SPIT problem. >> >> This makes me think that SPIT solutions must be operator independent. >> >> Would you have any comments on that? What is the situation in other >> countries? Which solutions can be applied? >> >> Thanks >> >> pars >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> >> ---------------------------------------------------------- >> Joachim Charzinski >> >> Nokia Siemens Networks >> Research, Technology and Platforms >> Research & Technology / Network Evolution >> >> St.-Martin-Str. 53 >> Post box: D-80240 Muenchen >> D-81541 Muenchen >> Germany >> Tel: +49 89 636 79902 >> >> Joachim.Charzinski@nsn.com >> http://www.nokiasiemensnetworks.com/global/ >> >> Think before you print >> >> Nokia Siemens Networks GmbH & Co. KG >> Sitz der Gesellschaft: M=FCnchen / Registered office: Munich >> Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 >> WEEE-Reg.-Nr.: DE 52984304 >> >> Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens >> Networks Management GmbH Gesch=E4ftsleitung / Board of Directors: Lydia >> Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of >> supervisory board: Lauri Kivinen Sitz der Gesellschaft: M=FCnchen / >> Registered office: Munich >> Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 >> > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > From dschwartz@xconnect.net Thu Jul 9 04:49:52 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03B53A699E for ; Thu, 9 Jul 2009 04:49: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 XJZcjXY56OtY for ; Thu, 9 Jul 2009 04:49:52 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id 1C6DC28C1E0 for ; Thu, 9 Jul 2009 04:49:28 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 9 Jul 2009 14:49:54 +0300 From: David Schwartz To: Pars Mutaf Date: Thu, 9 Jul 2009 14:49:53 +0300 Thread-Topic: Operator-assisted SPIT filtering (was Re: [Rucus] SPIT from operator) Thread-Index: AcoAikCcQocW+A4NSb2dP54NNAZsXAAABjLg Message-ID: <6EA53FAD386F9D46B97D49BFE148D5148CE25B@ISR-JLM-MAIL1.xconnect.co.il> In-Reply-To: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.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 Cc: Rucus BoF Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT from operator) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:49:53 -0000 Hi > What is the advantage of operator marking and forwarding the message, > over the cell phone marking the message > and storing marked as SPIT? The operator has much more information to base a decision on (including inp= ut he gets from the endpoint) than the endpoint has. The operator can "shar= e" information better with other users (including ones who did not actually= mark the particular caller) as well. Email systems have been doing this fo= r years where a spam indication by one of its members is propagated to othe= rs. > Perhaps the operator would have more information about SPITers and can > perform better filtering on behalf of users? (I'm not sure about > that). This could be clarified? My point is, that regardless of the actual SPAM indication harvesting techn= ique (e.g. the receiving user "blocked" the call), without the ability to w= arn others as well the information is of limited value - hence my reference= to the Wing draft. > Or it is an energy conservation issue? :) Thanks, pars From pars.mutaf@gmail.com Thu Jul 9 05:00:13 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C403F28C1CA for ; Thu, 9 Jul 2009 05:00:13 -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 sdPNvN7JT75l for ; Thu, 9 Jul 2009 05:00:13 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id C44CC28C1A9 for ; Thu, 9 Jul 2009 05:00:12 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so26262eye.65 for ; Thu, 09 Jul 2009 05:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k7Avw3hiT1mnwWutVq4RPOYaI98w/YBSm3OOXVAOCPY=; b=JlErPxd/zrS/HdZJxtAMsam6qyNfGjmdksiOw+POVHk6OZbml8q9qHpkwzA0gZFWAY ggl0eFKeGRL/EpuHOPHOBm3c3iHGE6Ssnl3QZav1BB7loa3Y742vOeUamane7qCUunVc H8gJ534gZyI+0XmPzOCN2ahfB3HweSnt39GJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bkdYpSxW0gp9sQBCTWN2mVaZ8RUCKp0BKuh1uU5RQrraJaybGBQzPEV9yoDwIkPhiO xxtkB4j5wBCjhBfwLI10Wybo8eXFgPslBVbMn3cLDGxvAR5JrctCdLdEbUHsVnj4hg4R IoBBS4Sp9G45oSKRxXuro5Ir4rbXUvp/cicLY= MIME-Version: 1.0 Received: by 10.210.52.15 with SMTP id z15mr843858ebz.75.1247140835816; Thu, 09 Jul 2009 05:00:35 -0700 (PDT) In-Reply-To: <6EA53FAD386F9D46B97D49BFE148D5148CE25B@ISR-JLM-MAIL1.xconnect.co.il> References: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com> <6EA53FAD386F9D46B97D49BFE148D5148CE25B@ISR-JLM-MAIL1.xconnect.co.il> Date: Thu, 9 Jul 2009 15:00:35 +0300 Message-ID: <18a603a60907090500k4cf6f75eu7627bc680b3138e2@mail.gmail.com> From: Pars Mutaf To: David Schwartz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rucus BoF Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT from operator) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:00:13 -0000 Hello, On Thu, Jul 9, 2009 at 2:49 PM, David Schwartz wrote: > > Hi > >> What is the advantage of operator marking and forwarding the message, >> over the cell phone marking the message >> and storing marked as SPIT? > > The operator has much more information to base a decision on (including input he gets from the endpoint) than the endpoint has. > The operator can "share" information better with other users (including ones who did not actually mark the particular caller) as well. > Email systems have been doing this for years where a spam indication by one of its members is propagated to others. Is there any reference for this? (if not too difficult to find any). In my view, there may exist messages marked as spam by one user, that may not be considered as spam by other users. I mean, users may have different spam criteria. In any case I would suggest that these points be clarified. They don't seem obvious to me. Thanks, pars > >> Perhaps the operator would have more information about SPITers and can >> perform better filtering on behalf of users? (I'm not sure about >> that). This could be clarified? > > My point is, that regardless of the actual SPAM indication harvesting technique (e.g. the receiving user "blocked" the call), without the ability to warn others as well the information is of limited value - hence my reference to the Wing draft. > >> Or it is an energy conservation issue? > > :) > > Thanks, > > pars > > From ranjit@motorola.com Thu Jul 9 05:00:55 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6714E28C187 for ; Thu, 9 Jul 2009 05:00:55 -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 wNH7ZOhV7FBr for ; Thu, 9 Jul 2009 05:00:54 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id BBCA028C173 for ; Thu, 9 Jul 2009 05:00:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-15.tower-55.messagelabs.com!1247140879!91013849!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 27468 invoked from network); 9 Jul 2009 12:01:20 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-15.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2009 12:01:20 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n69C1JM8006632 for ; Thu, 9 Jul 2009 05:01:19 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n69C1J4i026405 for ; Thu, 9 Jul 2009 07:01:19 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n69C1HKe026386 for ; Thu, 9 Jul 2009 07:01:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 20:00:55 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B07DACF61@ZMY16EXM66.ds.mot.com> In-Reply-To: <18a603a60907090449i50853e2ane40291095aaf83f7@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operator-assisted SPIT filtering (was Re: [Rucus] SPIT from operator) Thread-Index: AcoAjIXaet1xsen7Sb2lpSDtSIP+lgAAA7Kg References: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com> <18a603a60907090449i50853e2ane40291095aaf83f7@mail.gmail.com> From: "Avasarala Ranjit-A20990" To: "Pars Mutaf" X-CFilter-Loop: Reflected Cc: Rucus BoF Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT from operator) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:00:55 -0000 Hi Comments inline =20 Regards Ranjit -----Original Message----- From: Pars Mutaf [mailto:pars.mutaf@gmail.com]=20 Sent: Thursday, July 09, 2009 5:20 PM To: Avasarala Ranjit-A20990 Cc: David Schwartz; Charzinski, Joachim (NSN - DE/Munich); Rucus BoF; = Victor Pascual Avila Subject: Operator-assisted SPIT filtering (was Re: [Rucus] SPIT from = operator) Hello, On Thu, Jul 9, 2009 at 2:00 PM, Avasarala = Ranjit-A20990 wrote: > Hi > > Actually operator can come up with a service of helping the teminating = users (called users) to identify the unwanted callers and help them = register the unwanted caller identity with the network. Once registered, = the calls from the particular caller who was registered as "unwanted" = would be prevented from calling. This could be one way of reducing SPIT. > > The draft: = http://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-= icb-00 proposes a solution of appending a SIP Reason header with new = protocol value "block" to indicate to network to block the calling user = from future calling. > > We are in the process of updating this document and hence comments are = welcome. I am not sure to understand why the target cell phone doesn't drop the = unwanted call itself. The target call phone understands that the caller is unwanted = (E.g. telemarketer) only after speaking. So after speaking the target = call phone decides to block the caller from further calling. The target = call phone can also block the caller even without speaking (i.e. = dropping the call) and blocking the caller. Thanks, pars > > Thanks > > Regards > Ranjit > > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf = > Of David Schwartz > Sent: Thursday, July 09, 2009 4:22 PM > To: Pars Mutaf; Charzinski, Joachim (NSN - DE/Munich) > Cc: Rucus BoF > Subject: Re: [Rucus] SPIT from operator > > It's a shame Dan Wings proposal = (http://tools.ietf.org/html/draft-wing-sipping-spam-score-02) never went = anywhere. Basically, it argues that the operator simply "marks" or = "scores" a call and passes it on to the recipient for him/her to make = the actual accept/reject decision. > > D. > > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf = > Of Pars Mutaf > Sent: Thursday, July 09, 2009 1:47 PM > To: Charzinski, Joachim (NSN - DE/Munich) > Cc: Rucus BoF > Subject: Re: [Rucus] SPIT from operator > > Hi Joachim, > > To clarify, I don't receive calls but messages from the operator about = new services, new songs available as ring tone, and various non-sense = stuff. I would like to filter these messages on my cell phone. As far as = I know, there this no easy way to inform the operator that I'm not = interested in these messages. > > We seem to agree that the cell phone should be able to filter = operator's SPIT. > > Please see below for more... > > On Thu, Jul 9, 2009 at 10:01 AM, Charzinski, Joachim (NSN - = DE/Munich) wrote: >> Hi Pars, >> >>> This makes me think that SPIT solutions must be operator = independent. >> >> I think this is generalizing too much. Solutions against the type of=20 >> SPIT you mention will have to be operator independent (possibly also=20 >> involving some regulatory power that forces operators to respect=20 >> entries on "don't call" lists). The same will be true for the kind of = >> Spam distribution services we find with the postal service=20 >> ("distribute this to every household with a street address") -=20 >> wherever the operator actually makes money from Spam or SPIT, it will = >> be necessary to have an operator independent solution for fighting = Spam and SPIT. >> >> On the other hand, it is probably the operators that are currently=20 >> preventing large scale SPIT by performing ingress address filtering=20 >> and enforcing rate caps on SIP signalling. Also, in a traditional=20 >> telephony environment, it would be the operator that strips off the=20 >> origin address for anonymous calls, so the operator has more power in = >> filtering SPIT than the end user / end device would have. > > I am not sure that the operator is willing to filter SPIT. This is = open to discussion. > > By the way, I note here that in your operator-based filtering = approach, the operator should forward the messages marked as SPIT to the = target cell phone anyways. This is because the false positive = probability is never zero. > The target user should make the decision whether or not a message is = SPIT before deleting a message from inbox. > > As a consequence, this makes be believe that operator-based filtering = is not really necessary. Just forward all messages to the target cell = phone, the target cell phone can filter them and store the ones marked = as SPIT for eventual user inspection. > > I missed something? > > Thanks > > pars > > > > >> >> Therefore I think we need two solutions that help both parties - the=20 >> operator and the end user - to fight SPIT independently. They may=20 >> even cooperate, but they cannot completely substitute one another. >> >>> What is the situation in other countries? >> >> I am living in germany, and I used to get a lot of cold calls, most=20 >> of them machine assisted but actually connecting to a personal agent. >> Only a few calls were completely automated. My cold calls frequency=20 >> has dropped drastically since I started asking the callers for=20 >> permission to record the calls for usage in court. They seem to have=20 >> deleted my number from their address lists. >> If operators didn't interfer (see the above mentioned rate caps and=20 >> address filters), we would probably get a lot more calls, as there=20 >> are a lot of VoIP contracts around where you can reach most of the=20 >> fixed phone network within a flat rate. >> >> Best regards >> >> Joachim. >> >> >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On=20 >> Behalf Of ext Pars Mutaf >> Sent: Wednesday, July 08, 2009 5:34 PM >> To: Rucus BoF >> Subject: [Rucus] SPIT from operator >> >> Hello, >> >> I my country, subscribers receive a lot of SPIT from their operators. >> In my cell phone experience, the operator itself is the most serious=20 >> SPIT problem. >> >> This makes me think that SPIT solutions must be operator independent. >> >> Would you have any comments on that? What is the situation in other=20 >> countries? Which solutions can be applied? >> >> Thanks >> >> pars >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> >> ---------------------------------------------------------- >> Joachim Charzinski >> >> Nokia Siemens Networks >> Research, Technology and Platforms >> Research & Technology / Network Evolution >> >> St.-Martin-Str. 53 >> Post box: D-80240 Muenchen >> D-81541 Muenchen >> Germany >> Tel: +49 89 636 79902 >> >> Joachim.Charzinski@nsn.com >> http://www.nokiasiemensnetworks.com/global/ >> >> Think before you print >> >> Nokia Siemens Networks GmbH & Co. KG >> Sitz der Gesellschaft: M=FCnchen / Registered office: Munich >> Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 >> WEEE-Reg.-Nr.: DE 52984304 >> >> Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia = Siemens=20 >> Networks Management GmbH Gesch=E4ftsleitung / Board of Directors: = Lydia=20 >> Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of=20 >> supervisory board: Lauri Kivinen Sitz der Gesellschaft: M=FCnchen /=20 >> Registered office: Munich >> Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 >> > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > From ranjit@motorola.com Thu Jul 9 05:03:42 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4964828C1CF for ; Thu, 9 Jul 2009 05:03:42 -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 8b8UHZ-XOlR4 for ; Thu, 9 Jul 2009 05:03:41 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 67A4E28C1A9 for ; Thu, 9 Jul 2009 05:03:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1247141048!19864910!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7821 invoked from network); 9 Jul 2009 12:04:08 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2009 12:04:08 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n69C478v017422 for ; Thu, 9 Jul 2009 05:04:07 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n69C47tE006623 for ; Thu, 9 Jul 2009 07:04:07 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n69C46Ls006614 for ; Thu, 9 Jul 2009 07:04:06 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 20:03:43 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B07DACF64@ZMY16EXM66.ds.mot.com> In-Reply-To: <18a603a60907090500k4cf6f75eu7627bc680b3138e2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT fromoperator) Thread-Index: AcoAjOXyznYyUIi/R3225hp4aPFu2AAADoYA References: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com><6EA53FAD386F9D46B97D49BFE148D5148CE25B@ISR-JLM-MAIL1.xconnect.co.il> <18a603a60907090500k4cf6f75eu7627bc680b3138e2@mail.gmail.com> From: "Avasarala Ranjit-A20990" To: "Pars Mutaf" , "David Schwartz" X-CFilter-Loop: Reflected Cc: Rucus BoF Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT fromoperator) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:03:42 -0000 True. That is the reason why an Operator cannot mark any caller or call as spam. Only the target users can mark a particular caller or a call as unwanted or malicious and may want to block the caller from further calling.=20 Regards Ranjit -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of Pars Mutaf Sent: Thursday, July 09, 2009 5:31 PM To: David Schwartz Cc: Rucus BoF Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT fromoperator) Hello, On Thu, Jul 9, 2009 at 2:49 PM, David Schwartz wrote: > > Hi > >> What is the advantage of operator marking and forwarding the message, >> over the cell phone marking the message and storing marked as SPIT? > > The operator has much more information to base a decision on (including input he gets from the endpoint) than the endpoint has. > The operator can "share" information better with other users (including ones who did not actually mark the particular caller) as well. > Email systems have been doing this for years where a spam indication by one of its members is propagated to others. Is there any reference for this? (if not too difficult to find any). In my view, there may exist messages marked as spam by one user, that may not be considered as spam by other users. I mean, users may have different spam criteria. In any case I would suggest that these points be clarified. They don't seem obvious to me. Thanks, pars > >> Perhaps the operator would have more information about SPITers and=20 >> can perform better filtering on behalf of users? (I'm not sure about=20 >> that). This could be clarified? > > My point is, that regardless of the actual SPAM indication harvesting technique (e.g. the receiving user "blocked" the call), without the ability to warn others as well the information is of limited value - hence my reference to the Wing draft. > >> Or it is an energy conservation issue? > > :) > > Thanks, > > pars > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From luc.mathan@orange-ftgroup.com Thu Jul 9 07:11:19 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8D33A6C41 for ; Thu, 9 Jul 2009 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 NdvNdwqa34wX for ; Thu, 9 Jul 2009 07:11:17 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id B154C3A6A42 for ; Thu, 9 Jul 2009 07:11:16 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 16:11:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 16:11:41 +0200 Message-ID: <51D96D3F30495C4BAF8D190702F9B93327FC8D@ftrdmel1> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B07DACF64@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Operator-assisted SPIT filtering (was Re: SPITfromoperator) Thread-Index: AcoAjOXyznYyUIi/R3225hp4aPFu2AAADoYAAAIGTlA= References: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com><6EA53FAD386F9D46B97D49BFE148D5148CE25B@ISR-JLM-MAIL1.xconnect.co.il><18a603a60907090500k4cf6f75eu7627bc680b3138e2@mail.gmail.com> <750BBC72E178114F9DC4872EBFF29A5B07DACF64@ZMY16EXM66.ds.mot.com> From: To: X-OriginalArrivalTime: 09 Jul 2009 14:11:41.0162 (UTC) FILETIME=[2E6484A0:01CA009F] Cc: rucus@ietf.org Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPITfromoperator) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:11:19 -0000 When I hear that spit solutions must be "operator independent", I feel = that some basic facts from an email perspective need to be recalled, = because the points that are being discussed in this thread are only = relevant to a nice world with what is still very small amounts of spit. We would simply not be conversing by email right now if ISPs were not = filtering 80% to 99% of abusive emails (notice I did not say "spam" on = purpose) and preventing them from reaching your computer. Perhaps we = would still be using faxes (?) if the email filtering had been left as = an exclusive responsiblity of the end-user. Email would be dead, in = short. Of course the called party must have some control over the filtering, = based on his own criteria, which are not those of the operator. = Therefore a caller blacklist, managed by the end-user and hosted in the = terminal or by the operator, can be an interesting functionality, but = its usefulness will depend on how easy it is for the caller to adopt a = new identity. A mechanism for reporting spit to the operator or to a = third party (like law enforcement for instance) might perhaps be more = useful, but only if it can be established that the reported spit is = illegal. Legislation on spit is far from being clearly established yet, = anywhere in the world, and will probably be late by a couple of battles. The filtering criteria of the operator are different from the = end-user's. The goal of the operator is to protect the service from = being submerged by spit, thus destroying its business model (no business = model, no service, I'm sorry). Competing email operators do exchange = information on abusive email traffic (with FBLs - feedback loops), = because what is hurting one is hurting all email providers, small or = large. They also use real time blocklists (RBL) which they manage = themselves if they have the resources, or which are provided by third = parties. What is interesting is that even though legislation on spam is more = mature, email providers strictly speaking do not "block spam" at network = level, they block what they consider as "abusive email". That's for 2 = reasons: first, in most jurisdictions, fortunately, operators do not = have the right to filter content. The second reason is simply the huge = scale of the spam phenomenon. However, email is still a comunication = tool of acceptable quality and great usefulness to all, citizens and the = global economy alike. With most email providers, the amount of false = positives or false negatives is exceedingly small in relation to the = quantity of trash they have to process every second. And because they = know this, authorities tolerate the filtering applied by email providers = on their own criteria. I am sorry if all of the above is obvious, but my number one fear is to = see the mistakes of the smtp world be repeated in the sip world. With = voip calls gradually becoming so cheap as to become almost as free as = email, we must be extra careful, and we must not adopt exclusionary = stances before the problem is solved. I sincerely hope that spit will = never reach email spam levels and that more control on spit filtering = can be handed over to the user, but keeping the operator out would be a = mistake. Regards, Luc (true, I work for an operator; true, I am involved in www.maawg.org) > -----Message d'origine----- > De : rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org]=20 > De la part de Avasarala Ranjit-A20990 > Envoy=E9 : jeudi 9 juillet 2009 14:04 > =C0 : Pars Mutaf; David Schwartz > Cc : Rucus BoF > Objet : Re: [Rucus] Operator-assisted SPIT filtering (was Re:=20 > SPITfromoperator) >=20 > True. That is the reason why an Operator cannot mark any=20 > caller or call as spam. Only the target users can mark a=20 > particular caller or a call as unwanted or malicious and may=20 > want to block the caller from further calling.=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org]=20 > On Behalf Of Pars Mutaf > Sent: Thursday, July 09, 2009 5:31 PM > To: David Schwartz > Cc: Rucus BoF > Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT > fromoperator) >=20 > Hello, >=20 > On Thu, Jul 9, 2009 at 2:49 PM, David Schwartz > wrote: > > > > Hi > > > >> What is the advantage of operator marking and forwarding=20 > the message, >=20 > >> over the cell phone marking the message and storing marked as SPIT? > > > > The operator has much more information to base a decision on > (including input he gets from the endpoint) than the endpoint has. > > The operator can "share" information better with other users > (including ones who did not actually mark the particular=20 > caller) as well. > Email systems have been doing this for=20 > years where a spam indication by one of its members is=20 > propagated to others. >=20 > Is there any reference for this? (if not too difficult to find any). > In my view, there may exist messages marked as spam by one=20 > user, that may not be considered as spam by other users. > I mean, users may have different spam criteria. >=20 > In any case I would suggest that these points be clarified.=20 > They don't seem obvious to me. >=20 > Thanks, >=20 > pars >=20 > > > >> Perhaps the operator would have more information about SPITers and=20 > >> can perform better filtering on behalf of users? (I'm not=20 > sure about=20 > >> that). This could be clarified? > > > > My point is, that regardless of the actual SPAM indication=20 > harvesting > technique (e.g. the receiving user "blocked" the call),=20 > without the ability to warn others as well the information is=20 > of limited value - hence my reference to the Wing draft. > > > >> Or it is an energy conservation issue? > > > > :) > > > > Thanks, > > > > pars > > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus >=20 From ranjit@motorola.com Thu Jul 9 09:49:54 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F14B3A6808 for ; Thu, 9 Jul 2009 09:49:54 -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 1lNzjnR+Myoo for ; Thu, 9 Jul 2009 09:49:52 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 68C7E3A6D08 for ; Thu, 9 Jul 2009 09:49:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-6.tower-55.messagelabs.com!1247158218!13292287!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14356 invoked from network); 9 Jul 2009 16:50:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2009 16:50:19 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n69GoGb4001896 for ; Thu, 9 Jul 2009 09:50:18 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n69GoGQc006887 for ; Thu, 9 Jul 2009 11:50:16 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n69GoEd5006873 for ; Thu, 9 Jul 2009 11:50:15 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jul 2009 00:49:50 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B07DACFA5@ZMY16EXM66.ds.mot.com> In-Reply-To: <51D96D3F30495C4BAF8D190702F9B93327FC8D@ftrdmel1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Operator-assisted SPIT filtering (was Re:SPITfromoperator) Thread-Index: AcoAjOXyznYyUIi/R3225hp4aPFu2AAADoYAAAIGTlAAB71PEA== References: <18a603a60907090441u4d68d0f3x6aa72177811b4b6c@mail.gmail.com><6EA53FAD386F9D46B97D49BFE148D5148CE25B@ISR-JLM-MAIL1.xconnect.co.il><18a603a60907090500k4cf6f75eu7627bc680b3138e2@mail.gmail.com><750BBC72E178114F9DC4872EBFF29A5B07DACF64@ZMY16EXM66.ds.mot.com> <51D96D3F30495C4BAF8D190702F9B93327FC8D@ftrdmel1> From: "Avasarala Ranjit-A20990" To: , X-CFilter-Loop: Reflected Cc: rucus@ietf.org Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re:SPITfromoperator) X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:49:54 -0000 Hi Luc Actually operator is in the loop in the sense that by offering the = Communication Barring service. This is the enhancement to Incoming = Communication Barring service as defined in 3GPP TS 22.173. Here the = operator offers the enhanced ICB service and the terminating users = indicate to the network (operator) that a particular caller / call is = unwanted in nature and wish to block the caller from further calling. = Once the operator receives this request from the user, the operator = would create a black list (could be an additional one to if there is = already one existing) and add the caller details to the list. Next time when a call from the same caller arrives, the black list for = the called user is checked and if there is an entry for the calling = user, his or her call is rejected.=20 In SIP based networks, this mechanism can be achieved by proposing a new = protocol value "block" for the SIP Reason header which can be appended = to SIP BYE message or SIP 4xx message to block the caller either during = call termination or call alerting stages. The sip server at the = operator looks for the Reason header in the incoming BYE or 4xx message = and if the protocol value is "block" retrieves the block details and = updates the black list for the called user. More details on this mechanism are defined in = http://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-= icb-00. Comments welcome Thanks =20 Regards Ranjit -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf = Of luc.mathan@orange-ftgroup.com Sent: Thursday, July 09, 2009 7:42 PM To: pars.mutaf@gmail.com Cc: rucus@ietf.org Subject: Re: [Rucus] Operator-assisted SPIT filtering (was = Re:SPITfromoperator) When I hear that spit solutions must be "operator independent", I feel = that some basic facts from an email perspective need to be recalled, = because the points that are being discussed in this thread are only = relevant to a nice world with what is still very small amounts of spit. We would simply not be conversing by email right now if ISPs were not = filtering 80% to 99% of abusive emails (notice I did not say "spam" on = purpose) and preventing them from reaching your computer. Perhaps we = would still be using faxes (?) if the email filtering had been left as = an exclusive responsiblity of the end-user. Email would be dead, in = short. Of course the called party must have some control over the filtering, = based on his own criteria, which are not those of the operator. = Therefore a caller blacklist, managed by the end-user and hosted in the = terminal or by the operator, can be an interesting functionality, but = its usefulness will depend on how easy it is for the caller to adopt a = new identity. A mechanism for reporting spit to the operator or to a = third party (like law enforcement for instance) might perhaps be more = useful, but only if it can be established that the reported spit is = illegal. Legislation on spit is far from being clearly established yet, = anywhere in the world, and will probably be late by a couple of battles. The filtering criteria of the operator are different from the = end-user's. The goal of the operator is to protect the service from = being submerged by spit, thus destroying its business model (no business = model, no service, I'm sorry). Competing email operators do exchange = information on abusive email traffic (with FBLs - feedback loops), = because what is hurting one is hurting all email providers, small or = large. They also use real time blocklists (RBL) which they manage = themselves if they have the resources, or which are provided by third = parties. What is interesting is that even though legislation on spam is more = mature, email providers strictly speaking do not "block spam" at network = level, they block what they consider as "abusive email". That's for 2 = reasons: first, in most jurisdictions, fortunately, operators do not = have the right to filter content. The second reason is simply the huge = scale of the spam phenomenon. However, email is still a comunication = tool of acceptable quality and great usefulness to all, citizens and the = global economy alike. With most email providers, the amount of false = positives or false negatives is exceedingly small in relation to the = quantity of trash they have to process every second. And because they = know this, authorities tolerate the filtering applied by email providers = on their own criteria. I am sorry if all of the above is obvious, but my number one fear is to = see the mistakes of the smtp world be repeated in the sip world. With = voip calls gradually becoming so cheap as to become almost as free as = email, we must be extra careful, and we must not adopt exclusionary = stances before the problem is solved. I sincerely hope that spit will = never reach email spam levels and that more control on spit filtering = can be handed over to the user, but keeping the operator out would be a = mistake. Regards, Luc (true, I work for an operator; true, I am involved in www.maawg.org) > -----Message d'origine----- > De : rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] De la part = > de Avasarala Ranjit-A20990 Envoy=E9 : jeudi 9 juillet 2009 14:04 =C0 : = > Pars Mutaf; David Schwartz Cc : Rucus BoF Objet : Re: [Rucus]=20 > Operator-assisted SPIT filtering (was Re: > SPITfromoperator) >=20 > True. That is the reason why an Operator cannot mark any caller or=20 > call as spam. Only the target users can mark a particular caller or a=20 > call as unwanted or malicious and may want to block the caller from=20 > further calling. >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf = > Of Pars Mutaf > Sent: Thursday, July 09, 2009 5:31 PM > To: David Schwartz > Cc: Rucus BoF > Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT > fromoperator) >=20 > Hello, >=20 > On Thu, Jul 9, 2009 at 2:49 PM, David Schwartz > wrote: > > > > Hi > > > >> What is the advantage of operator marking and forwarding > the message, >=20 > >> over the cell phone marking the message and storing marked as SPIT? > > > > The operator has much more information to base a decision on > (including input he gets from the endpoint) than the endpoint has. > > The operator can "share" information better with other users > (including ones who did not actually mark the particular > caller) as well. > Email systems have been doing this for years where=20 > a spam indication by one of its members is propagated to others. >=20 > Is there any reference for this? (if not too difficult to find any). > In my view, there may exist messages marked as spam by one user, that=20 > may not be considered as spam by other users. > I mean, users may have different spam criteria. >=20 > In any case I would suggest that these points be clarified.=20 > They don't seem obvious to me. >=20 > Thanks, >=20 > pars >=20 > > > >> Perhaps the operator would have more information about SPITers and=20 > >> can perform better filtering on behalf of users? (I'm not > sure about > >> that). This could be clarified? > > > > My point is, that regardless of the actual SPAM indication > harvesting > technique (e.g. the receiving user "blocked" the call), without the=20 > ability to warn others as well the information is of limited value -=20 > hence my reference to the Wing draft. > > > >> Or it is an energy conservation issue? > > > > :) > > > > Thanks, > > > > pars > > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus >=20 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From hs@123.org Tue Jul 28 06:56:52 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42A33A6B4D for ; Tue, 28 Jul 2009 06:56: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=[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 BeK9QRb5J2ud for ; Tue, 28 Jul 2009 06:56:52 -0700 (PDT) Received: from brian.123.org (brian.123.org [78.47.108.129]) by core3.amsl.com (Postfix) with ESMTP id E35053A6C1A for ; Tue, 28 Jul 2009 06:56:51 -0700 (PDT) Received: from [130.129.17.240] (dhcp-11f0.meeting.ietf.org [130.129.17.240]) by brian.123.org (Postfix) with ESMTP id 9CE8BC38254 for ; Tue, 28 Jul 2009 15:56:36 +0200 (CEST) Message-ID: <4A6F0393.3070203@123.org> Date: Tue, 28 Jul 2009 15:56:35 +0200 From: Hendrik Scholz User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: rucus@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Rucus] IETF75: lunch on thursday? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 13:56:52 -0000 Hi! How about a small meeting over lunch on thursday? I'll be available after MMUSIC (morning session) and am open regarding the food. Cheers, Hendrik -- Hendrik Scholz From victor.pascual.avila@gmail.com Tue Jul 28 07:06:15 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714033A6FAC for ; Tue, 28 Jul 2009 07:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.679, 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 OTFI8k68lnRF for ; Tue, 28 Jul 2009 07:06:14 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 052703A6EF1 for ; Tue, 28 Jul 2009 07:06:05 -0700 (PDT) Received: by ewy26 with SMTP id 26so43479ewy.37 for ; Tue, 28 Jul 2009 07:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S4INawtJ8jLp8x2KzegUz9Sgg8d55UsqmFILsgxZO1w=; b=GDkibdBXfNjOFjILEc3pGr6NWCCD5s8Vjy1usETRwfH2B+35hReDjiQoYrGpuynTQW HbcDqjt/ryBGx3dItI6zpICbSE6gjtEtCrMpKbwJAp1EqFGlEBbB+4cs5gRvvTMA2RJb jjClxqw0/4HvIklHLxDG4O9a9+/4nlF8k/ruE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Gt0YQLfW8hU1LD3vW7Cji62IqEmcnpsOsQxJahhn4S2zVWxbKjaj+Lx0aWzGOfZ3cK R9OhcON/ixPAVTx01D0PCECQPXaqKnHlkzWPWgDuxHIvcLH12AxTSoCiotvOMbn1cnLO RCf2yl7napCBbmCWozuVi7ZDL6t2BMVjVW1hU= MIME-Version: 1.0 Received: by 10.216.90.8 with SMTP id d8mr998740wef.92.1248789955104; Tue, 28 Jul 2009 07:05:55 -0700 (PDT) In-Reply-To: <4A6F0393.3070203@123.org> References: <4A6F0393.3070203@123.org> Date: Tue, 28 Jul 2009 16:05:55 +0200 Message-ID: <618e24240907280705p2063757at7b0ce3d38ebf1143@mail.gmail.com> From: Victor Pascual Avila To: Hendrik Scholz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rucus@ietf.org Subject: Re: [Rucus] IETF75: lunch on thursday? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 14:06:15 -0000 On Tue, Jul 28, 2009 at 3:56 PM, Hendrik Scholz wrote: > Hi! > > How about a small meeting over lunch on thursday? > I'll be available after MMUSIC (morning session) and am open > regarding the food. I'm game. --=20 Victor Pascual =C3=81vila From Jan.Seedorf@nw.neclab.eu Tue Jul 28 07:26:17 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F16A3A6A93 for ; Tue, 28 Jul 2009 07:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.886, 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 QujwdCjW0s5x for ; Tue, 28 Jul 2009 07:26:16 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 483BF3A6F14 for ; Tue, 28 Jul 2009 07:26:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4D7D92C0203FF; Tue, 28 Jul 2009 16:26:17 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVt4npsNbBYg; Tue, 28 Jul 2009 16:26:17 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 1E5D32C01CB01; Tue, 28 Jul 2009 16:26:02 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 28 Jul 2009 16:26:00 +0200 Message-ID: In-Reply-To: <618e24240907280705p2063757at7b0ce3d38ebf1143@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] IETF75: lunch on thursday? thread-index: AcoPjNm6qjSIIMrlTheBrHu2zADV9wAAkMfQ References: <4A6F0393.3070203@123.org> <618e24240907280705p2063757at7b0ce3d38ebf1143@mail.gmail.com> From: "Jan Seedorf" To: "Victor Pascual Avila" , "Hendrik Scholz" Cc: rucus@ietf.org Subject: Re: [Rucus] IETF75: lunch on thursday? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 14:26:17 -0000 SG93IGFib3V0IHRoZSAiVGFjbyBCYXIiIGNsb3NlIGJ5PyBBdXRoZW50aWMgbG9jYWwgU3dlZGlz aCBmb29kIC4uLiA6KQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ1 Y3VzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydWN1cy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYNCj4gT2YgVmljdG9yIFBhc2N1YWwgQXZpbGENCj4gU2VudDogRGllbnN0YWcsIDI4LiBK dWxpIDIwMDkgMTY6MDYNCj4gVG86IEhlbmRyaWsgU2Nob2x6DQo+IENjOiBydWN1c0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW1J1Y3VzXSBJRVRGNzU6IGx1bmNoIG9uIHRodXJzZGF5Pw0KPiAN Cj4gT24gVHVlLCBKdWwgMjgsIDIwMDkgYXQgMzo1NiBQTSwgSGVuZHJpayBTY2hvbHo8aHNAMTIz Lm9yZz4gd3JvdGU6DQo+ID4gSGkhDQo+ID4NCj4gPiBIb3cgYWJvdXQgYSBzbWFsbCBtZWV0aW5n IG92ZXIgbHVuY2ggb24gdGh1cnNkYXk/DQo+ID4gSSdsbCBiZSBhdmFpbGFibGUgYWZ0ZXIgTU1V U0lDIChtb3JuaW5nIHNlc3Npb24pIGFuZCBhbSBvcGVuDQo+ID4gcmVnYXJkaW5nIHRoZSBmb29k Lg0KPiANCj4gSSdtIGdhbWUuDQo+IC0tDQo+IFZpY3RvciBQYXNjdWFsIMOBdmlsYQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSdWN1cyBtYWls aW5nIGxpc3QNCj4gUnVjdXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydWN1cw0K From stpeter@stpeter.im Tue Jul 28 14:06:27 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0AE3A68AE for ; Tue, 28 Jul 2009 14:06:27 -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 JyCWQj4sok6P for ; Tue, 28 Jul 2009 14:06:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7D1BE3A6827 for ; Tue, 28 Jul 2009 14:06:26 -0700 (PDT) Received: from squire.local (unknown [212.112.167.85]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 614F440C89; Tue, 28 Jul 2009 15:06:27 -0600 (MDT) Message-ID: <4A6F6851.2090001@stpeter.im> Date: Tue, 28 Jul 2009 23:06:25 +0200 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hendrik Scholz References: <4A6F0393.3070203@123.org> In-Reply-To: <4A6F0393.3070203@123.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rucus@ietf.org Subject: Re: [Rucus] IETF75: lunch on thursday? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 21:06:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/28/09 3:56 PM, Hendrik Scholz wrote: > Hi! > > How about a small meeting over lunch on thursday? > I'll be available after MMUSIC (morning session) and am open > regarding the food. I don't think that I have any lunch commitments on Thursday so I could probably join. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpvaFEACgkQNL8k5A2w/vzlUgCgzvmADOhCY8wUqKyEzr/WgdR3 bSoAniwlNE/PzbkW08wW2+DL7S1ANh+f =MEYC -----END PGP SIGNATURE----- From salvatore.loreto@ericsson.com Tue Jul 28 14:09:05 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B963A69BE for ; Tue, 28 Jul 2009 14:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 VGMZ8lUd1q8N for ; Tue, 28 Jul 2009 14:09:04 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 606473A68AE for ; Tue, 28 Jul 2009 14:08:40 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-21-4a6f68d8e4cc Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 8D.AA.00514.8D86F6A4; Tue, 28 Jul 2009 23:08:40 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 23:08:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 23:08:39 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9A7092537; Wed, 29 Jul 2009 00:08:39 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5F43321A07; Wed, 29 Jul 2009 00:08:39 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D691621925; Wed, 29 Jul 2009 00:08:27 +0300 (EEST) Message-ID: <4A6F68C2.4090007@ericsson.com> Date: Wed, 29 Jul 2009 00:08:18 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Peter Saint-Andre References: <4A6F0393.3070203@123.org> <4A6F6851.2090001@stpeter.im> In-Reply-To: <4A6F6851.2090001@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 28 Jul 2009 21:08:39.0902 (UTC) FILETIME=[949287E0:01CA0FC7] X-Brightmail-Tracker: AAAAAA== Cc: rucus@ietf.org Subject: Re: [Rucus] IETF75: lunch on thursday? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 21:09:05 -0000 I will probably join too. Sal Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/28/09 3:56 PM, Hendrik Scholz wrote: > >> Hi! >> >> How about a small meeting over lunch on thursday? >> I'll be available after MMUSIC (morning session) and am open >> regarding the food. >> > > I don't think that I have any lunch commitments on Thursday so I could > probably join. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkpvaFEACgkQNL8k5A2w/vzlUgCgzvmADOhCY8wUqKyEzr/WgdR3 > bSoAniwlNE/PzbkW08wW2+DL7S1ANh+f > =MEYC > -----END PGP SIGNATURE----- > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > From hs@123.org Thu Jul 30 00:05:59 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803CB3A6950 for ; Thu, 30 Jul 2009 00:05: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 PhZTNrMeWqKo for ; Thu, 30 Jul 2009 00:05:58 -0700 (PDT) Received: from brian.123.org (brian.123.org [78.47.108.129]) by core3.amsl.com (Postfix) with ESMTP id B0CD93A692A for ; Thu, 30 Jul 2009 00:05:58 -0700 (PDT) Received: from [194.97.181.241] (unknown [194.97.181.241]) by brian.123.org (Postfix) with ESMTP id 5FFDDC38256; Thu, 30 Jul 2009 09:05:57 +0200 (CEST) Message-ID: <4A714654.5090504@123.org> Date: Thu, 30 Jul 2009 09:05:56 +0200 From: Hendrik Scholz User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Salvatore Loreto References: <4A6F0393.3070203@123.org> <4A6F6851.2090001@stpeter.im> <4A6F68C2.4090007@ericsson.com> In-Reply-To: <4A6F68C2.4090007@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rucus@ietf.org, Jan Seedorf Subject: Re: [Rucus] IETF75: lunch on thursday? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 07:05:59 -0000 Hi! Somebody has to propose a time and place, thus let's meet outside the venue. When you exit through the doors we'll be on the left side. I'll be carrying the IETF71 messenger bag if that helps to locate us ;-) I propose we leave at 11:45. Jan mentioned a Taco place. I believe he meant the one close to the venue. It is about 150-200m away from the venue next to the pedestrian area (exit to the left). Cheers, Hendrik -- Hendrik Scholz From Jan.Seedorf@nw.neclab.eu Thu Jul 30 00:29:07 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1553A7166 for ; Thu, 30 Jul 2009 00:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.591, 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 YCYJprBtLtSD for ; Thu, 30 Jul 2009 00:29:07 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CB5D83A6A3A for ; Thu, 30 Jul 2009 00:28:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1AB3A2C0012C4; Thu, 30 Jul 2009 09:28:38 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GK4WbWzEmA0; Thu, 30 Jul 2009 09:28:38 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id EDD782C0012C5; Thu, 30 Jul 2009 09:28:22 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 30 Jul 2009 09:28:19 +0200 Message-ID: In-Reply-To: <4A714654.5090504@123.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] IETF75: lunch on thursday? Thread-Index: AcoQ5EQEpqARw7lURoy0kEWvWgVO7QAArNKg References: <4A6F0393.3070203@123.org> <4A6F6851.2090001@stpeter.im><4A6F68C2.4090007@ericsson.com> <4A714654.5090504@123.org> From: "Jan Seedorf" To: "Hendrik Scholz" , "Salvatore Loreto" Cc: rucus@ietf.org Subject: Re: [Rucus] IETF75: lunch on thursday? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 07:29:08 -0000 Hendrik, Thanks for the planning, 11:45 outside the entrance is fine for me. = Actually, there are two Taco Bars nearby (it seems to be a chain, = supporting my theory that Tacos are originally Swedish and were brought = to Mexico by early, pre-Columbus vikings). I was thinking about the one = on "vasagatan", but we can decide once we met outside the building. - Jan > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf > Of Hendrik Scholz > Sent: Donnerstag, 30. Juli 2009 09:06 > To: Salvatore Loreto > Cc: rucus@ietf.org; Jan Seedorf > Subject: Re: [Rucus] IETF75: lunch on thursday? >=20 > Hi! >=20 > Somebody has to propose a time and place, thus let's meet > outside the venue. When you exit through the doors we'll be > on the left side. I'll be carrying the IETF71 messenger bag > if that helps to locate us ;-) >=20 > I propose we leave at 11:45. > Jan mentioned a Taco place. I believe he meant the one > close to the venue. It is about 150-200m away from the venue > next to the pedestrian area (exit to the left). >=20 > Cheers, > Hendrik >=20 > -- > Hendrik Scholz > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus From victor.pascual.avila@gmail.com Thu Jul 30 01:25:38 2009 Return-Path: X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038F128C191 for ; Thu, 30 Jul 2009 01:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 Dw64P5X28CBB for ; Thu, 30 Jul 2009 01:25:37 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id E239428C144 for ; Thu, 30 Jul 2009 01:25:36 -0700 (PDT) Received: by ewy10 with SMTP id 10so558166ewy.37 for ; Thu, 30 Jul 2009 01:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z9sRr04AZ3d5w9VivHtpYn2I4+ggpUy9pu6Ar95Wq58=; b=joqBylDoCbqZWqUECetYxrIkrmsY46gpHs/RZI4BSMnFPlcx5wERC3QHTpyUOy9Ao1 fCSRpMxK7HlxCxYf/2gF/fsSnrPVq4CKBrqNpEO0N1dvJgxMuQoH6KQjAXSf63CT1QvA 78vXKMMy8q4jCvFc9NP06OL2hy9C1IWZV7neY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NQ4mvOVsyi/09DtBRPk9dG795bLSdHoJdUZ/qdkpNBC5dmUSKZk9lWiRyEyO91tY/G 4zgwbAfMLWUV2OlgC9pkYX4xhMvVNFyAuw3uciX/SbUAwSvmAiH/dDVNRNM921uJgXIq JSYOgrZuKWVBgsV9WymrGEAYaFwSgxSSsjU30= MIME-Version: 1.0 Received: by 10.216.52.194 with SMTP id e44mr184357wec.34.1248942332753; Thu, 30 Jul 2009 01:25:32 -0700 (PDT) In-Reply-To: References: <4A6F0393.3070203@123.org> <4A6F6851.2090001@stpeter.im> <4A6F68C2.4090007@ericsson.com> <4A714654.5090504@123.org> Date: Thu, 30 Jul 2009 10:25:32 +0200 Message-ID: <618e24240907300125n149a4438gefb014c3a348a385@mail.gmail.com> From: Victor Pascual Avila To: Jan Seedorf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rucus@ietf.org Subject: Re: [Rucus] IETF75: lunch on thursday? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:25:38 -0000 I'll be there Following are the minutes from our last f2f meeting: Updated Meeting Minutes from F2F at IETF#73 http://www.ietf.org/mail-archive/web/rucus/current/msg00347.html Actions coming out of informal RUCUS meeting at IETF 73 http://www.ietf.org/mail-archive/web/rucus/current/msg00352.html Cheers, -Victor On Thu, Jul 30, 2009 at 9:28 AM, Jan Seedorf wrot= e: > Hendrik, > > Thanks for the planning, 11:45 outside the entrance is fine for me. Actua= lly, there are two Taco Bars nearby (it seems to be a chain, supporting my = theory that Tacos are originally Swedish and were brought to Mexico by earl= y, pre-Columbus vikings). I was thinking about the one on "vasagatan", but = we can decide once we met outside the building. > > =C2=A0- Jan > >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf >> Of Hendrik Scholz >> Sent: Donnerstag, 30. Juli 2009 09:06 >> To: Salvatore Loreto >> Cc: rucus@ietf.org; Jan Seedorf >> Subject: Re: [Rucus] IETF75: lunch on thursday? >> >> Hi! >> >> Somebody has to propose a time and place, thus let's meet >> outside the venue. When you exit through the doors we'll be >> on the left side. I'll be carrying the IETF71 messenger bag >> if that helps to locate us ;-) >> >> I propose we leave at 11:45. >> Jan mentioned a Taco place. I believe he meant the one >> close to the venue. It is about 150-200m away from the venue >> next to the pedestrian area (exit to the left). >> >> Cheers, >> =C2=A0 Hendrik >> >> -- >> Hendrik Scholz >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > --=20 Victor Pascual =C3=81vila