Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPITfromoperator)

<luc.mathan@orange-ftgroup.com> Thu, 09 July 2009 14:11 UTC

Return-Path: <luc.mathan@orange-ftgroup.com>
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 <rucus@core3.amsl.com>; 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 <rucus@core3.amsl.com>; 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 <rucus@ietf.org>; 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, 09 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: luc.mathan@orange-ftgroup.com
To: pars.mutaf@gmail.com
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\)" <rucus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rucus>, <mailto:rucus-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rucus>
List-Post: <mailto:rucus@ietf.org>
List-Help: <mailto:rucus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rucus>, <mailto:rucus-request@ietf.org?subject=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] 
> De la part de Avasarala Ranjit-A20990
> Envoyé : jeudi 9 juillet 2009 14:04
> À : Pars Mutaf; David Schwartz
> Cc : Rucus BoF
> Objet : Re: [Rucus] Operator-assisted SPIT filtering (was Re: 
> SPITfromoperator)
> 
> 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. 
> 
> 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<dschwartz@xconnect.net>
> 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
> >
> >
> _______________________________________________
> 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
>