STIR/SHAKEN? On Mon, Apr 27, 2020, 14:34 Michael Thomas <[email protected]> wrote:
> > On 4/27/20 11:12 AM, Jon Lewis wrote: > > On Mon, 27 Apr 2020, William Herrin wrote: > > > >> On Sat, Apr 25, 2020 at 7:32 PM Matthew Black > >> <[email protected]> wrote: > >>> Good grief, selling a kit for $47. Since all robocalls employ Caller > >>> ID spoofing, just how does one prove who called? > >> > >> You don't. AFAICT, that's the point of Anne's comments. Finding them > >> is good enough. Paying off anyone who both finds them and appears well > >> connected with the law is cheaper than allowing the legal system to > >> become aware of their identities and activity. > >> > >> Blackmail 101 dude. Find someone with a secret and demand payment for > >> your silence. The best part is that if you're legitimately entitled to > >> the money because of the secret then it's not technically blackmail. > >> > >> Presumably the meat of the $47 kit is about how to tease out enough > >> clues to search public records and identify them. > > > > In my experience, the caller-id is always forged, and the call center > > reps hang up or give uselessly vague answers if I ask what company > > they're calling from. I suspect the only sure way to identify them is > > to do business with them, i.e. buy that extended warranty on your car, > > or at least start walking through the process until either payment is > > made or they tell you who you'll have to pay. I wonder, if you agree > > to buy the extended warranty, solely for the purpose of identifying > > them, can you immediately cancel it / dispute the charge? > > > > Then there are the 100% criminal ones calling from "Windows Technical > > Support" who want to trick you into giving them remote admin access to > > your PC. I assume that's a dry well and the best you can hope to do > > is waste as much of their time as yours and see how foul a mouth they > > have. > > > On the IETF list, I've been making the case that a DKIM-like solution > for SIP signalling would in fact give you the way to blame somebody, > which was DKIM's entire raison d'etre. Who cares what the actual fake > e.164 address is and whether the sending domain is allowed to assert it > or not? That is rather beside the point. All I care is that the > originating domain is supporting abuse, and I know what the domain is to > complain to, ignore, etc. > > Mike > > >
