Subject: [Sipping] refresh of sipping-spam draft

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 10 Mar 2006 16:08:32 -0500

This draft has gotten very little discussion recently. I submitted an 
update just to refresh the document in the repository; there is no 
change in content. There are no issues per se, but the draft definitely 
needs some review and commentary.

http://www.ietf.org/internet-drafts/draft-ietf-sipping-spam-02.txt

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 14 Mar 2006 19:25:27 +0100

Jonathan,

A comment on section 3.7 ("Limited Use Addresses"): This section appears to 
be mixing two different aspects: to use multiple addresses for different 
occasions (example: 1 for each buddy) (1) and to 'invalidate' an address 
once it becomes SPAMed (2). These can be used together, but also separate.

Since (1) could be considered as "SPAM prevention" and (2) as "SPAM 
mitigation", it might be appropriate to put them in different sections.

Perhaps this is out of scope for this draft, but for sake of discussion - 
how would one implement 'address invalidation'?

I would argue that it is desirable to do the invalidation such that SPAM 
messages get blocked at the proxy, rather than at the UA. I wrote a draft 
about something called "TRUUs" (Temporarily Routable UA URI) a while ago, 
but perhaps this functionality could be combined with GRUUs instead: what if 
a UA would be allowed to change its instance-id and then re-REGISTER (while 
unregistering the previous binding)? Assuming the SPAMmer was using the GRUU 
address, I think this would enable the proxy to block further messages to 
this GRUU (404 not found)?

Regards,

Jeroen

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "IETF Sipping List" <[email-masked]>
Sent: Friday, March 10, 2006 10:08 PM
Subject: [Sipping] refresh of sipping-spam draft

> update just to refresh the document in the repository; there is no change 
> in content. There are no issues per se, but the draft definitely needs 
> some review and commentary.
>