Re: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00

Hi Hannes, 

> -----Original Message-----
> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] 
> On Behalf Of Hannes Tschofenig
> Sent: Tuesday, February 26, 2008 9:16 AM
> To: Jonathan Rosenberg
> Cc: rucus@ietf.org
> Subject: Re: [Rucus] comments on 
> draft-niccolini-sipping-spam-feedback-00
> 
> Hi Jonathan,
> 
> thanks for your feedback.
> 
> You are right that this mechanism does not make a lot of 
> sense if you consider an architecture that uses authorization 
> policies and whitelists in particular.

Not fully true. I would call authorization policies and whitelists as the first line of defense, but not the ultimate. Authorization policies and whitelists are also known from email spam mitigation. However, we all know that they help but they are not the overall cure for the spam problem.

> It makes some sense when you consider these statistical 
> learning techniques that require "good" and "bad" examples to learn.
> 
> This is obviously a -00 draft and I believe we should end up 
> with this work is more something along the lines of Peter's work
> 
> http://www.xmpp.org/extensions/inbox/error-abuse.html

Yet another early work at a different venue.

> where there is communication between proxies rather than 
> between the end host and the proxy. 

That is another area of interest which does not preclude what we are talking about

  Martin

> 
> Ciao
> Hannes
> 
> 
> 
> Jonathan Rosenberg wrote:
> > Thanks for writing this, its a good topic to discuss.
> >
> > One thing that wasn't clear; what is the benefit of signaling 
> > something as spam to my proxy, as opposed to just putting 
> the sender 
> > on a black list. We have mechanisms defined already for that, for 
> > example. I suspect its around sharing of the spam 
> classification with 
> > other users in the domain. Its worth discussing this.
> >
> > Seems easier if you just send the entire sip message as 
> content rather 
> > than picking apart pieces of it.
> >
> > The mechanism is clearly intended to be between a UA and a proxy in 
> > its own domain; however I didn't find that stated till much 
> deeper in 
> > the document. This should be clear up front.
> >
> > In terms of specific protocols, I think SUB/NOT is a very 
> poor choice. 
> > The proxy will require a subscription to EVERY UA, and the 
> events will 
> > be infrequent. This means a lot of overhead for little 
> data. I think 
> > you are much better off with an asynchronous push, either 
> PUBLISH or 
> > even non-sip. Maybe a REST interface or something.
> >
> > Thanks,
> > Jonathan R.
> >
> >
> >   
> 
> _______________________________________________
> Rucus mailing list
> Rucus@ietf.org
> http://www.ietf.org/mailman/listinfo/rucus
> 

stiemerling@nw.neclab.eu   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014  
_______________________________________________
Rucus mailing list
Rucus@ietf.org
http://www.ietf.org/mailman/listinfo/rucus