The CO (switch) never cared. Despite having the ability to check/reject CLID values, no one ever has. Today, with SIP and soft switches, it's even easier, and they still don't do it. (I bet your voip.ms personal account could send out whatever it wants -- not a cutomer, so I don't know.)

There is no technological solution.

There is, and always has been. With a simple POTS line, there's no means for the caller to manipulate anything -- it's all set by the serving switch. With ISDN (PRI and to some extent BRI), the caller was allowed to set CLID fields to indicate which "extension" is calling, ANI would be set by the switch to indicate the billing number for the line, however, your phone doesn't show ANI (even if it's a ISDN phone.) ISDN was expensive, so only a business would have them, and businesses could be trusted to not abuse the feature. That has worked out so well. :-)

Every phone switch I'm aware of supports limiting what's allowed for CLID. It's obvious most (all?) telcos cannot be bothered to use this feature.

Actually, the MPAA/RIAA do have a court order in these cases... but just one for many IPs. When they have to file one case per address, it becomes a huge burden (and expensive) and they tend to walk away.

IF you take the call directly from a scammer, and the SIP call is completed...

And just who in their right mind allows random SIP traffic from the internet to reach their PBX? ABSOLUTELY FUCKING NO ONE! Page one, step one of toll-fraud: allow access only from authorized sources. So, if a SIP call is "completed", it came from your phone service provider.

If they're spoofing the caller-id, then you have NO WAY to know where it came from. Only a "trap and trace" can follow it back, hop by hop, to the origin -- one switch at a time, one provider at a time, all the way back to China (or where ever.) That's the basis for the hollywood phone trace, but in reality, it takes people combing through records to see what's going on. (unless it's crossing metered lines, in the US, it's almost a certainty no CDRs are being generated and/or recorded, and even then, only for the segment that's metered -- eg. your cellphone.)

"Secret" is the most basic of our (US) government clearances. It's an entirely clerical check. It's not like you're being authorized for nuclear launch codes, but something closer to knowing phone numbers and extensions for people's desks.

(I've had a "secret clearance"; it was the .gov's equiv of an NDA.)

They can be in full f'ing uniform and lie right to your face. What the cop (detective, etc.) says is "hearsay"; what you say is "evidence".

Hostkarma still had it in the logs.

You sent junk mail; you got blacklisted. Nothing more to see here.

Unless you've been keeping detailed records long BEFORE the event(s) that triggered your blacklisting, odds are you'll have no record of what actually caused it. With Yahoo, you may not even know who was sent what, so you don't know who might have clicked the "spam" button. (and it used to be far to easy for complete idiots to click spam instead of delete, and not have any idea the difference between them.)

NET-23-30-0-0-1 was assigned to Comcast Business two and a half years ago. Your (apparent) netblock [NET-23-31-69-152-1] was assigned to you about a year ago. If anti-spam outfits were, as you claim, blocking all Comcast addresses, you'd've been blocked from day-one. The fact that you weren't, and have now mysteriously been blocked very strongly suggests something occurred from within your netblock to cause it. That means ANY device within your network could be the "bad apple".

how are you going to come up with the [money]...

It's spelled mommy and daddy. If ever there were a better example of an excess of privilege and status, I'm not aware of it.

It's not a flag, it's a command. Support for the feature is signaled after the client hello (EHLO). It's not just hiding the indicator in the hello, but actively blocking the command.

The issue Goldenfrog whined about was a simple oversight from Cricket Wireless(?). That's the default behavior (even today) for Cisco firewalls -- which is why everyone with a clue disables (or at least tweaks) that idiotic inspection rule.

Wrong. Most MTAs (for a long time now) will attempt TLS if available.

some of the best IT "gurus" in the world don't have an expensive piece of paper hanging on the wall.

Sure they do, it has a Cisco logo on it. :-)

(I have two college degrees. They aren't hanging on any wall, 'tho -- they're in a file cabinet.)

Right. Manned by a pair of people inside a bunker that would take days to breach from the outside -- by design. One of the goes nuts and kills the other, he's got plenty of time to rig shit. Someone on the surface would have to notice this, and then get maintenance crews to the site(s) and into the silo(s) to physically disable the launchers. Every step in that chain is measured in multiple HOURS -- assuming anyone outside even notices before a missile comes flyin' out.

And if the stories are true, for a very long time, the silo launch codes were (still???) set to zero in protest to having those installed in the first place.

All this assumes a mad man in a silo couldn't figure out how to bypass the proven lax security measures and light one off on his/her own.

So I should be able to demand Verizon install ("host") my server(s) for free as well? Not going to happen.

Netflix is a FOR PROFIT BUSINESS. They can pay for services just like everybody else. (speaking as Verizon) Why should I bear the cost of hosting their business? It isn't costing me customers. And I'm sure as hell not going to give those asshats at Cogent anything; they're being paid boatloads by Netflix but won't buy the interconnects to support 'em.

Yes, there are small(ish) ISPs hopping on the Open Connect bandwagon. For them, it's a cost effective solution vs. the alternatives -- lost customers, or additional expensive bandwidth. Verizon (et. al) simply aren't going to play those games: Cogent can buy the bandwidth necessary to support their customers, or Netflix can find a different (preferably direct) path.