September 03, 2008 | Comments: (0)
Google's Chrome's a Shining Beta
This belongs filed in the "I wish I had thought of that" department: a browser that isolates each window/tab to protect it from all the others, and actually frees resources when the tabs and windows are closed.
Brilliant!
I bet that most people would have expected this behavior to be de rigueur for browsers, but it's not. With the rich applications on the web and the implications for cross-site impacts, this is a natural evolution.
Unlike the Wall Street Journal's Walt Mossberg, I haven't been able to test it for a week, but the idea already has me smitten. However, unfortunately for me, I have to run it inside Parallels running Windows on my Mac, since the native Mac version isn't available, yet. C'mon, Google, I thought you at least would provide parity with your software!
If you haven't checked out Chrome, yet, but want to know more, you can read the comic book information, watch the videos. Or just do what I did and go download it. Let me know what you think. I have found a few stutters in performance (ironically, some with Gmail windows), but overall it's a great beta effort and I'm looking forward to it getting better.
(If you're on a Mac, you have to visit the download site from Windows; that page won't let you download from a Mac-based browser!)
Posted by Stephen Hultquist on September 3, 2008 11:03 PM
September 03, 2008 | Comments: (0)
Email Deliverability: Steps to Take
What can you do to make sure email gets through?
You've read about how the business critical function of email is no longer reliable. You have also read about how email services are making the delivery of email impossible to know. So, what can you do?
The good news is that there are some things that you can do. The bad news is that they may not be enough, and sometimes they aren't possible without explicit support from your email service provider. Before I get into the details, though, let me give you the technical structure of modern email.
Today's Internet-base email system continues to rely on the venerable Simple Mail Transfer Protocol (SMTP) first introduced in RFC 821 by Jon Postel in August, 1982. While it has been augmented over the years, the basic structure of SMTP remains as it always was, based on an inherent trust between Internet services which has been completely broken by the overwhelming volume of unsolicited email (aka "spam") on the Internet today. The fundamental problem is that SMTP does not provide for the authentication of the sender of a given email, so the recipient server doesn't know with any accuracy who is sending the message. As a result, it must make a series of guesses to determine suitability for delivery. Those guesses are fraught with risk both that they will miss unsolicited email and that they will mark valid email as spam. This combination of problem has led us to the deliverability problems we see today.
There are a few things that you want to do to increase your chances of having email delivered. The first is obvious: Obey the rules. Don't send unsolicited bulk email. If you manage a mailing list, make sure that people opt-in. Double opt-in (where the requestors receive an email to verify their request) are the most secure. Beyond that, though, make sure your system is configured in a way that gives you the best chance for delivery, including configuring SPF and DKIM.
SPF
Sender Policy Framework (SPF) provides a method for any domain owner to identify the IP addresses from which email may be sent for their domain. Using DNS TXT records, SPF lists all IP addresses and/or hostnames from which email may be originated. While not completely secure due to ways that DNS plain text answers can be manipulated, it is a good first line of offense for deliverability.
DKIM
DomainKeys Identified Mail (DKIM) is a more advanced method using cryptographic authentication to identify the originator and (optionally) intermediaries in the transit of an email message. Although around as a proposed Internet standard since 2005, its use is still sporadic, creating difficulties for both senders and receivers. For example, the design of DKIM is such that the sending mail server must support it and append the sender's key to the outgoing email. Shared email systems such as those offered by Google, Yahoo!, AOL, and others must provide the DKIM header content (a digital signature based on the contents of the message) that will be authenticated by the recipient server against the senders DNS-published public key. This service is not universally available, although it is a much more robust mechanism for authenticating senders than is SPF.
As you look for email service providers or speak with your service provider about deliverability, DKIM should be near the top of your list for services that you require from them.
In my next post, I'll dig deeper into the world of certified email delivery and the challenges of unraveling deliverability issues.
Stephen Hultquist is a contributing editor to InfoWorld Test Center and an on-demand CIO for emerging and other fast-moving companies.
Posted by Stephen Hultquist on September 3, 2008 06:34 PM
August 21, 2008 | Comments: (0)
E-mail deliverability: things that go bump in the night
When you send e-mail, you expect it to get through. When someone sends you e-mail, you expect to receive it. Over the past few years, the explosive growth of spam -- that unsolicited e-mail sent by the dregs of Internet society -- has forced legitimate e-mail senders to pass through ever-more-challenging hoops to keep from being classified as spam.
In fact, seminars and books have been written on how to make sure your e-mail doesn't trigger spam filters or otherwise get your e-mail on the wrong side of the Internet law.
But, historically, these issues were of concern for those who sent large batches of legitimate business e-mail, such as newsletters and the like. However, this has now changed.
In my previous post on e-mail deliverability, I wrote about clients of mine who are experiencing difficulties getting e-mail delivered. They are organizations who have never sent mass e-mail of any kind. The content of their e-mail gets 0 scores from Spam Assassin, is sent as one-to-one e-mail, and is sent from a relatively new domain name.
Yet, a relatively high percentage of their e-mail (sometimes as high as 50 percent) does not get to the recipient, instead either finding its way to the recipient's junk folder or just disappearing into some Internet black hole along the way.
Why?
There are a number of elements that go into e-mail delivery these days, some of which explicitly and intentionally break standard protocols. Because illegitimate e-mail is so voluminous, e-mail determined to be spam often does not receive the proper e-mail server response messages. Instead, e-mail determined to be bulk mail is simply dropped without reply. This breaks SMTP and makes troubleshooting exceedingly difficult -- and at times impossible.
Enough people report that this is a problem that it's worth a more extensive exploration. In the next post, I'll look at how some of the solutions are worse than the problem, and break other de facto standards of Internet behavior.
Posted by Stephen Hultquist on August 21, 2008 03:30 PM
August 18, 2008 | Comments: (0)
E-mail deliverability: when critical isn't reliable
Software as a service (Saas) e-mail services delivered by Google in the Google Apps platform, by Zoho, by Microsoft partners in the Hosted Exchange program, by those using the Amazon EC2 services, and others are effective approaches for many businesses to take.
However, there's a prickly little problem that is becoming more and more serious. Your e-mail may go undelivered and you'll never know it ... and you may not be able to figure out why!
Some years ago in the pages of InfoWorld, Brian Livingston reported on the challenges facing e-mail. Unfortunately, not only have things not changed much for the better, they are definitely headed in the other direction. So much so, that the content of messages has become much less the focus of deliverability and the reputation of the IP address of the sending server has come to mean a lot.
This is a real issue for SaaS-delivered e-mail.
I became aware of this issue while working with a company who had just created their domain for the first time on a SaaS platform. They were writing only one-to-one e-mails to those who had requested e-mail from them. But a large number of their e-mails were randomly going missing. No error messages, no bounces, just into the black hole.
Obviously, this is a very big deal.
In researching this, I ran into a disappointing and worrisome set of information about the impact of the war against spam. Over the course of the next few posts to this blog, I'll let you in on what I've discovered. In the meantime, please share your experiences with me either by e-mail or in the comments on this blog. I plan to share the experiences of others during the course of this series.
When business-critical functions aren't reliable, there's a problem. And the industry needs to fix it.
Posted by Stephen Hultquist on August 18, 2008 09:46 PM
June 06, 2008 | Comments: (0)
Real performance is hard to find
"The server is down," he said as I walked into the office on Thursday. "No it isn't," I answered. "What is your trouble?" He went on to explain his issue and it turned out to be a network connectivity issue from his desk.
Sound familiar? Such scenarios happen around the world every day. End users thinking that they understand what's going on in the technological infrastructure while the technical staff fights off all the wrong reporting to try to get to the bottom of things.
How do you do it?
As an on-demand strategic technology consultant (think CIO on-demand), I see this kind of issue all the time. It seems that a lot of non-IT people think that their ability to install Microsoft Office on their home PC or help their family members with their home network means that they can make technology decisions at their companies. Unfortunately for all involved, nothing could be further from the truth.
However, that means that the demands on the technology staff are greater than ever. How do you address that?
As food for thought, I learned recently about SevOne, and their new flagship product, the SevOne Performance Management Appliance.
Performance management has been a real pain in the neck for a long time. The systems are very difficult to use, and visibility is poor. Modern drill-down Web interfaces don't exist. The architecture hasn't changed much in the past decade.
Until now, it seems.
SevOne's appliance implements a distributed application already in-use at such large networks as Matria Healthcare and Comcast. For instance, Jay Scott, performance engineer at Matria mentions the ability to drill into the reports to get to the core of the issue as being quite a contrast to legacy solutions that require running reports until you find the one you need.
Jeff Gill, senior director of Network Surveillance for Comcast notes that SevOne allows them to redistribute national performance data to regional and local technical support, effectively getting the information into the hands of staff that can address the issues.
I see this as an important evolution in managing the infrastructure.
What do you do? How do you get visibility into the real issues? Do you see a solution like SevOne as providing valuable insight?
Stephen Hultquist is a contributing editor to InfoWorld Test Center and an on-demand CIO for emerging and other fast-moving companies.
Posted by Stephen Hultquist on June 6, 2008 02:24 AM
May 13, 2008 | Comments: (0)
A couple weeks ago, I posted an article about the partnership between Salesforce.com and Google, and discussed the implications of it in terms of reality versus the hype about whether or not Microsoft would be threatened by it as most pundits liked to discuss. Of course, when the Microsoft offer for Yahoo imploded last week, the same folks rambled on with the same focus: Microsoft needs something in order to compete with Google.
Perhaps so. But doing it by buying an on-line search company misses the boat completely. Are these guys really that ignorant?
Perhaps, as the old joke goes, Microsoft really isn't a technology company, but an investment bank. Regardless, what really is the wise place to put your investments? Into the dubious and volatile world of on-line advertising revenues? Or into the more promising world of delivery highly usable software as a service?
The answer is obvious.
Perhaps most people do not remember when Hotmail was independent. In 1998, Microsoft bought Hotmail because their own on-line efforts had failed miserably. In 2000, Microsoft migrated Hotmail from FreeBSD to Windows 2000, and published a paper on it. Anyone who used Hotmail during those years can remember the painful transition.
The real question is, "Has Microsoft learned from their past mistakes?" And the answer seems to be a resounding "NO!"
The emergence of interfaces that are actually intuitive (does an iPhone manual actually exist?) and the Vista flop (underscored by InfoWorld's "Save XP" campaign and the plans of multiple large companies to forgo upgrading) point Microsoft in the right direction: better software products that embrace the trajectory that already exists in terms of intuitive interfaces, multi-source mash-ups, and reliability.
Small companies get lost when they focus outside their core competencies. Big companies do, too, but often miss what they are doing. Microsoft, what's your core competency? Focus there and build the best products in the world!
Update: Thanks to Ian for pointing out my inadvertent error in stating that HotMail was running on OpenBSD. Of course, it was running on FreeBSD (as the Microsoft paper cited above mentions. My apologies. I do understand the important distinction!Posted by Stephen Hultquist on May 13, 2008 05:24 PM
TOP STORIES
ADDITIONAL RESOURCES
- Best Practices for Successful SOA Governance
- Application Grid: Oracle's Vision for Next-Generation Application Servers and Infrastructure
- Do you have the power to resolve technical issues with one call?
- Sun Microsystems: The Green Tide Is Coming.
- More Effective Antivirus Protection
- Stop Spam, Phishing and Viruses
