The mail hosting companies are particularly delinquent in not making damn sure this is done for every "mom-and-pop.com" they host. If you're not a tech person, but run a small business doing something else, the ins and outs of this kind of thing is what you -should be getting- from an outsource mail service.

With the increasing growth of outsource email, it's getting really hard for spam detectors to distinguish between real spam, and email sent on behalf of one company by some outsourced mail/customer contact management company.

Here's the technology my ISP uses: http://www.escom.com/ (Disclosure: The developer is a friend-of-a-friend of long standing.)

I've advocated (including to my senator, Warner (D) of Virginia, a former telecom executive) that the FCC should require changes to make CallerID Verified. By this I mean that the Telco/switch has to verify the CallerID (e.g. using payment data?), and mark the CallerID information as either verified or suspect. This would not solve the problem, but would, I believe, help both consumers and Law Enforcement.

As long as spammers can forge CallerID, we won't be able to depend on CallerID to screen calls, and DoNotCall registry violations will be much harder to enforce. "Brigitte from Credit Card Services" calls usually have a City/State CallerID value, rather than the name of an individual or organization. But I get some legitimate calls (e.g. my dog's oncologist) that also show up as City/State. (I know to answer calls from Vienna, VA - at least until the Spammers start forging local CallerID values...) My former employer removed its telephone number from the CallerID information, I know if I get a call from "732" (New Jersey area code) that it's most likely one of my former co-workers.

But recently I've been getting Spam calls on my cell, usually (but not always) the CallerID says "unknown". Until this month, such calls were limited to the Land Line (and this is the single strongest argument for ditching the land line.)

ONLY if there are tests to catch the problems that exist in the earlier version!

Either (a) there was a test contemporaneous with the faulty component that wasn't run; or (b) a subsequent fault was discovered, a test for that fault is developed, and that test is subsequently associated with that component (version).

Testing is no cure for bad design or bad coding, which are the -root cause-. The specific design and code techniques to prevent vulnerabilities need to be better communicated and enforced (by open source code reviewers, as well as commercial developers).

That's not to argue testing is unimportant. But it's not the root cause of vulnerabilities, and it's not clear to me that we know how to test for a lot of vulnerabilities.

In my (limited) experience, when I've had a significant tech problem, my goal is to work with the Tier 1 guy to run quickly through his/her troubleshooting script and to get a hand-off to Tier 2, more expert support. Sometimes that's the level that can authorize on-site repairs, changes to routing tables on their end, etc. The other option, particularly if this isn't a residential/consumer account, is to talk to the sales rep. A good sales rep (not always an oxymoron!) can sometimes open doors for you from the inside.

And for what it's worth: I've had the least expensive business grade service from Cox (Northern VA) for over 10 years, and generally have been very pleased with both the reliability of the service and the support when I have had problems. The only real issue I had was "left hand not talking to right hand" when the residential cable installer was unaware of the business internet connection, and disconnected it. The second time that happened, I ran after the guy's truck, demanded he call his office to confirm I had both services (on separate contracts) and then reconnect the line. That same installer came out on a subsequent call and remembered that incident. (I was a bit distraught, since I was getting ready to leave to go to my mother's house after she had a very nasty fall, and basically said, "I don't need to be dealing with this s**t right now!")

An old Dogtag and a "P-38" can opener.

http://www.theverge.com/2015/5...

Relevant to my comment above: http://www.theverge.com/2015/5...

Given my great distrust of Verizon, I'm seriously considering abandoning/boycotting any site currently hosted by AOL, such as "Engadget, TechCrunch, and The Huffington Post."

My experience (35 years worth) differs from Mr Anonymous.

I explicitly will not hire any programmer who knows only one programming language (C and C++ count as 1 for that score.) Learning a different programming language introduces you to alternative ways to think about problems and solutions. Lisp or Scheme, Ada or Eiffel, COBOL or MUMPS, all provide a different perspective on software design, coding, test and integration.

Too many hiring managers play "buzzword bingos" in search of "flying purple unicorns," candidates whose buzzwords match their current search list. Sure, you can make a living chasing buzzwords that way, with a combination of (primarily) resume engineering and (secondarily) training. And some people who do this are actually pretty good developers. But many more don't know how to apply the technology, they're just able to produce toy programs learned from " for Idiots" who produce the stuff documented on http://thedailywtf.com/ But the people I want are those who can think creatively about a problem, using more tools than just one hammer, and who can learn new stuff on the job. What's the half-life of a technology these days, 3 years?

I documented the change of control, and noted Microsoft profited from enabling that change. If that's characterized as "misrepresenting" things, so be it.

When Corporate IT provides all employees with a charge number, from the CIO's budget, to use when the IT keeps the employee from being productive, then maybe I'll have more sympathy for corporate IT. How many times, for example, has your computer been forced to reboot in the middle of the day because IT decided to roll out some change? How many times have you had to go to the HelpDesk because something that worked before, suddenly stopped working? How many policies have been instituted that are a direct response to problems that are unique to Microsoft Windows? The real problem is not the transfer of control to IT, but rather the lack of accountability on IT departments for how their policies and actions negatively impact the larger community.

One advantage I've had as a Mac user in Windows-centric organizations is that IT didn't know how to mess with my computer, keeping me much more productive. Best example was Y2K remediation where I worked back in 1999. IT budgeted an hour to do each Windows machine. No one in my department was done in less than 2 hours and the worse case was the guy who was down for 3 days. For the Macs, IT budgeted 1/2 hour, most Mac users did it themselves in 10-15 minutes, and most of those changes actually were making sure -Microsoft Office- was up-to-date.

As always, Your Mileage May Vary.

If you look at Windows NT and beyond, it was all about removing capabilities from untrusted users, and placing them in the hands of IT staff/CIOs. That was a huge success for Microsoft, CIOs -control the budget- and decide what gets purchased. So they stuck with what empowered them, regardless of whether this was good for the user community, and whether the Microsoft monoculture created more problems -and more costs- than it solved. (After all, the measure of 'power' in many organizations is the size of the budget and staff, growing the CIO budget and hiring more IT workers equated to more CIO power.

So now, with the growth of non-PCs (phones, tablets, even IoT) in companies, Microsoft once again plays to (you could say 'panders to') the CIO and ability to control the device.

This could be quite a battle, with Apple/IBM (and presumably Google/Android soon) providing business services to the user community, versus Microsoft providing control (and familiarity) to the CIO community.

There's a difference, though, between a preference for COTS with vendor support, and a mandate for a specific COTS product. An Open Source product without anyone providing maintenance is a risk. An Open Source product where you can -compete- for maintenance is a real benefit. A COTS product where you pay whatever the vendor charges for maintenance is at least a predictable life-cycle cost, but that vendor has you by the short-hairs. I've seen products where the sustainment contract was a lot more than the purchase/license price, and there was nothing you could do about it.