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

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]] 
> 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
> 
> 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

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.

> 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.

That is one viable approach.

> 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.

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

> > 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.

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.

> 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.

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


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