Subject: [Sipping] comments on draft-wing-sipping-spam-score-00

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 Dec 2007 09:42:11 -0500

I think a key part of this is that you need to have a trust relationship 
with the sender of the score, otherwise its useless. As with any trust 
relationship, it requires authentication to make sure the guy you are 
talking to is the one you trust. This typically implies mutual TLS 
authentication between domains. It also means that you can't have more 
than one spam score at a time - just the one from the previous hop 
domain. So how would you authenticate and authorize the sources farther 
away, as this draft proposes?

It seems that, unless there is a standardized range and meaning of 
values it will be hard to take any action based on this value.

It would be good to give some examples of how an originating domain 
might compute the score.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 4 Dec 2007 15:53:59 +0100

Hi Jonathan,

thanks for your comments, it is good to see constructive ways
of discussing on this work.
 
> It seems that, unless there is a standardized range and 
> meaning of values it will be hard to take any action based on 
> this value.

This is exactly the point. This is not in the draft now but for more info
on this please refer to the email thread "Spit Score Semantics".
If we agree on this comments (Henning was also stimulating some text
in this direction) I will work with Dan to put something in the next
revision.

> It would be good to give some examples of how an originating 
> domain might compute the score.

We can put examples in an appendix or reference literature. Would
this be ok?

Thanks again,
Saverio

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 4 Dec 2007 10:41:24 -0500

The mechanism proposed has reasonable precedent in email, with various  
X-Spam-Score style headers inserted by the local mailserver. The  
problem in email is that every spam filter seems to have picked some  
other X- convention or re-use the same header with different formats.  
I don't think that's an experience that we want to repeat.

For example, your message arrived in my inbox with
X-Spam-Score: 	-3 () CU_OK_LISTUNSUB RBL_DNSWL_127.0.9.3

On Dec 4, 2007, at 9:42 AM, Jonathan Rosenberg wrote:

> I think a key part of this is that you need to have a trust  
> relationship with the sender of the score, otherwise its useless. As  
> with any trust relationship, it requires authentication to make sure  
> the guy you are talking to is the one you trust. This typically  
> implies mutual TLS authentication between domains. It also means  
> that you can't have more than one spam score at a time - just the  
> one from the previous hop domain. So how would you authenticate and  
> authorize the sources farther away, as this draft proposes?

Clearly, authentication would work (e.g., in the SIP Connect style),  
but the simpler approach taken today by email also works: The inbound  
proxy deletes all such headers and the UA has a trust relationship  
with its proxy. This does not work if the originating domain computes  
the scores; there, you'd need a trust relationship.

This seems pretty similar to PAI.

The limitations of this approach need to be clearly documented in the  
draft.

> values it will be hard to take any action based on this value.

This isn't true today for email spam scores, but it is still useful,  
given that the tests performed by one's inbound proxy tend not to  
change a whole lot over time. Spam Assassin inserts similar tokens  
into inbound email and it is then up to the scripts in the email "UA"  
to decide whether, for example, Chinese characters are a sign of spam  
or not.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Dec 2007 09:32:30 +0100

In the past we had the idea to provide the authentication part for the 
Spam score using SAML. That helps if you are verifying more than one 
Spam score and also a Spam score that was generated by a node more than 
one hop away.

Do you think we should re-visit some of that work again?

Ciao
Hannes

Jonathan Rosenberg wrote:
> implies mutual TLS authentication between domains. It also means that 
> you can't have more than one spam score at a time - just the one from 
> the previous hop domain. So how would you authenticate and authorize 
> the sources farther away, as this draft proposes?
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 4 Dec 2007 09:53:35 -0800

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Tuesday, December 04, 2007 7:41 AM
> To: Jonathan Rosenberg
> Cc: IETF Sipping List
> Subject: Re: [Sipping] comments on draft-wing-sipping-spam-score-00
> 

Yes, and my SpamAssassin uses a different syntax, as does
my employer's IronPort system.

The intent of this draft is to avoid this same diversity in
SIP.  That is, to create a standard for this scoring rather
than having every product invent its own proprietary indicator
and having every SIP proxy and SIP UA have to support a bunch
of those different proprietary indicators.

> with its proxy.

That is one viable approach.

> This does not work if the originating domain 
> computes  
> The limitations of this approach need to be clearly 
> documented in the draft.

Agreed, and I know it is not described in the draft right now.

> > values it will be hard to take any action based on this value.

I don't see any way to create a standard for what "80% likelyhood
of spam" could possibly mean, other than it is more likely to be
spam than another request that was scored with a lower value.

> into inbound email and it is then up to the scripts in the 
> email "UA"  to decide whether, for example, Chinese characters 
> are a sign of spam or not.

In that case, the UA is building its own score based on that
additional detailed information.  The draft currently allows 
such detailed information to be conveyed to the UA so the UA
can do that.

-d