December 20th, 2007

Google Apps 'founder' Rajen Sheth: We dialog with users through new code

Posted by David Berlind @ 8:38 pm

Categories: General, Google Apps To-Do List, IT Management, Software Infrastructure, Video, Web technology

Tags: Google Inc., Google Apps, E-mail, Productivity, Microsoft Office, Online Communications, Office Suites, Software, David Berlind

Last week, while in California, I had an opportunity to sit down with Rajen Sheth — the man at Google who is credited with coming up with the idea of Google Apps. That interview, along with a demo of some of Google Apps’ more novel features, can be viewed in the attached video.

When most people hear the phrase Google Apps, they see it as a colloquial reference to some of the browser-based applications that Google serves up through the Web such as Google Documents and Google Spreadsheets. However, that’s not really what Google Apps is.

Yes, Google Apps involves Google’s browser-based productivity applications such as Google Docs, Google Spreadsheets, and Gmail. But, more than that, Google Apps is a branded bundle of those and other applications (Page Creator, Web site hosting, calendaring, Google Talk, etc.) that Google targets at organizations. When accessed via Google Apps, that bundle of applications behaves in more of an organizational context than do Google’s applications on the standalone basis that the general public has access to. For example, the apps can be accessed directly through an organization’s Internet domain (eg: http://mail.yourdomain.com or http://docs.yourdomain.com) and, for every such domain, certain users get administrative privileges to globally configure most of Google Apps’ options for all of an organization’s users.

Google Apps is available in two flavors. First, the Standard Edition (GASE) : a version of Google Apps that’s free, but that bears advertising in the Gmail portion and that limits the e-mail storage to 5GB per user. Second, the Premier Edition (GAPE): a far more functional $50 per user per year version with no ads, 25GB of storage per user, 24×7 telephone support, a 99.9 percent uptime service level agreement for e-mail, access to plug-in software from third parties, and more.

In the big picture of the industry, Google Apps is viewed by many as the only suite of productivity software with a real shot at cutting Microsoft Office’s dominant market position down to size. Yes, Google Apps does some things more efficiently than does Microsoft Office. For example, as opposed to the downloads required by Microsoft Office, almost all updates to the service involve little more than pressing the refresh button on a browser (the downloadable Google Talk application is one exception). But even though Google Apps has loads of compelling features, most view its ability to compete with Microsoft Office as having more to with Google’s powerful brand name and its virtually unlimited warchest (a luxury that none of Microsoft Office’s competitors has had).

The result of that warchest is a value that makes it difficult for organizations not to try it out. With GASE being free and GAPE costing only $50 per user per year, just use of the e-mail service alone could end up yielding savings. The availability of GAPE’s 24×7 phone support is reminiscent of the free support provided in the 1980’s by Wordperfect to users of its namesake word processing software — free offering that Wordperfect was eventually forced to abandon in favor of a more expensive paid service. With its deep pockets, Google can much afford to offer Google Apps at any price and, according to Sheth, more than 500,000 organizations are currently using it.

In the interview, we cover a wide range of questions — everything from how Google manages to offer GAPE users a whopping 25GB of storage when most corporations can only offer their own users a fraction of that to questions regarding the potential consolidation of currently bifurcated functionality (for example, tagging taxonomies and HTML authoring). Along the way, Sheth shows me some really interesting functionality including an autofill feature in the spreadsheet that draws upon Google’s experimental Google Sets functionality. In the interview, Sheth says that Google uses code to dialog with its users. Updates to the service are very frequent and sometimes significant.

Sheth also shows off how Google has made Google Calendar extensible with Gadgets. In the example he shows, a Google Gadget automatically populates the calendar with new movie openings and locations. The idea, according to Sheth, is to offer the right extensibility in the right context. It made me think a bit about how FaceBook is in many cases a collection of functionality, a lot of it without context.

Check out the video, and let me know what you think.

October 31st, 2007

There's much more to GMail's support of IMAP than meets the eye

Posted by David Berlind @ 3:57 pm

Categories: General, Google Apps To-Do List, IT Management, Office 2.0, Personal Technology, Software Infrastructure, Web technology

Tags: Folder, Google Inc., Google Gmail, IMAP, E-mail Providers, E-mail, Internet, Online Communications, David Berlind

If you’re like me and you saw last week’s announcement from Google regarding GMail’s support of the IMAP mail retrieval protocol (and you know what IMAP is), then you probably reached the same conclusion I did: Given the way GMail lets you tag e-mails with labels (as opposed to the way most other e-mail systems handle e-mail organization via foldering), Google has come up with a way to synchronize labels in GMail with folders of the same name (as each label) in your e-mail client. Typical clients could be Outlook and Thunderbird, or a smartphone like a Treo, iPhone, or BlackBerry. If you reached that conclusion, you were right. But, based on my podcast interview with GMail associate product manager David Murray, there’s a bit more to the IMAP announcement than meets the eye.  Through the embedded player above, you can playback the audio, download it, or, if you’re already subscribed to ZDNet’s IT Matters series of podcasts (see how to subscribe), the interview should appear on your PC, MP3 player, or both (depending on how your subscription is set up).

Most e-mail clients support IMAP. But not most e-mail services (like GMail, until now). As opposed to the POP3 protocol that pretty much every e-mail service and server supports (the alternative to IMAP that e-mail clients can use to retrieve e-mail from e-mail servers and services), IMAP supports bidirectional synchronization of your inbox as well as any folders that you’ve created to keep your e-mail organized. I often lament how some of the various e-mail services out there don’t support IMAP. First, who doesn’t need some way of keeping their e-mail organized? Second, who wants to have separate organizational frameworks on their clients and servers that are completely unaware of each other?

Looking to not only address that pain, but also make its GMail service more appealing to enterprises, Google introduced IMAP support last week and is still in the process of making the feature available to 100 percent of its GMail service users, including users of Google Apps (a bundle of Google services that’s targeted at organizations and that integrates GMail with Google Docs, Google Calendar, and other Web-ware offerings).

What, beyond basic synchronization of GMail folders with client-side mail applications, can users look forward to.  One of the most interesting apsects of GMail’s IMAP support is the way in which the synchronization process deals with e-mail that’s dragged into a spam or junk mail folder on the client side.  For example, as I described in a blog post that I published earlier today, that act triggers the same business process on the server side as the one that would be triggered if, when opening a message via GMail’s Web interface, you pressed the Report Spam button. Likewise, whatever rules on GMail’s server that may have resulted in the false classification of an e-mail as spam are reconsidered when a user moves an e-mail that GMail put into the spam folder to a folder for legitimate mail.

Another VERY interesting feature of Google’s IMAP support is the way in which the tagging of an email with multiple tags results in that same email being filed in multiple folders on the client side.  Provided your email client somehow makes it possible to store an e-mail in multiple folders on the client-side (many don’t), the same is true in reverse.

Because of the way IMAP supports the nesting of folders, supporting IMAP meant that Google had to figure out a way to hierarchically nest labels.  So, along with the introduction of IMAP support, Google has introduced the slash (”/”) as a means of telling GMail that one label is a parent to another.   For example, in GMail, the parent-label “Northeast” could have child-labels as in “Northeast/Massachusetts” and “Northeast/Connecticut”.  On the client side, such a hierarchical taxonomy would be reflected in parent and child folders with no limit to nesting depth.

The introduction of hierarchical tagging begged two more globally directed questions for Google; First, will the hierarchical tagging be made available in other Google services (ie: Google Reader, Google Docs, etc.). Second, when will (note, not “if”, but “when”) Google’s customers be able to unify their taxonomy across those other applications so that users can see everything that’s tagged with the same label (eg: “Northeast/Massachusetts”) regardless of what service it comes from.

Google can’t not do this as there’s a strong likelihood that information workers will be collecting/receiving data through a variety of conduits (e-mail, RSS, shared documents, instant messaging, search, etc.) that they’ll want to group together under one heading.  As I’ve written before, once Google makes this move, it will be essentially the same thing as Yahoo’s del.icio.us with the one difference being that Google will undoubtedly AJAXify it’s search results so that search users can very easily and contextually apply their taxonomy to one or more entries on a search results page without having to reload any HTML.

When I asked Murray about this obvious next step for Google, he concurred that it all made sense but fell short of confirming that anything like that was in the works.   For the most part during the interview, Murray stuck to issues relating to GMail. But he did say “we are converging in terms of our offerings, [and] the UI affordances….we know that we don’t want people to have to reinvent the wheel or learn 20 different types of user interfaces.”

Speaking of AJAX, I asked Murray about the rumors that more GMail interface improvements were on the way and he confirmed that in the next couple of weeks, users of GMail should notice better overall performance to the Web interface thanks to a pre-fetching feature thats part of a complete refresh of all of GMail’s underlying AJAX engine.

There was no mention of any offline capabilities along the lines of what my fellow blogger Garett Rogers wrote about with respect to going offline with Google Calendar. But, I don’t think it’s possible that GMail’s AJAX engine would go through such a complete rewrite unless it had going offline via Google’s offline technology known as Google Gears (the way Google Reader currently does and Calendar will) in mind.  So, my sense is that we should expect that pretty soon and why not? One of the advantages of Web-based solutions like GMail, Salesforce.com, and others is that updates and bug fixes can be rolled out to end users whenever Google wants to.  Unlike with shrink-wrapped software where significant complexity is involved in pushing new code down to local clients, updates and fixes are available immediately to end users of Web-ware the next time they hit the refresh button on their browser.

Murray and I talked about the release cycle and according to him, a new release of GMail is going out almost every week now. Some of the changes (like the addition of IMAP support) are more obvious than others (eg: bug fixes).  According to Murray, Google takes problems with the user interface very seriously (not just in Gmail, but in all of Google’s services) and has the equivalent of an emergency response team that, like antibodies, converge on bugs and knock them out pretty quickly.  In a something of testimony to  the advantages of Web-based software over its shrink-wrapped competition, Murray claims that the engineering turn around time to address some bugs has been as little as 15 minutes.

Murray and I covered a lot of other ground as well.  For example I asked him whether or not Google might eventually embrace folders instead of labels in its GMail user interface and he talked about that being a major issue for other GMail users as well (expect some changes there!).   We also talked about APIs and whether Google might be opening Gmail up to developers any time soon.

October 31st, 2007

Connect the Google dots: In war on spam, GMail's IMAP support hints at 'auto-unsubscribe' standard

Posted by David Berlind @ 10:38 am

Categories: General, Google Apps To-Do List, IT Management, Legal, Personal Technology, Security, Software Infrastructure, Web technology

Tags: Google Inc., Google Gmail, Problem, Sender, IMAP, Murray, E-mail, Cyberthreats, Spam, Online Communications

Boy those folks at Google are clever when it comes to spam. The question is whether a technology that they probably have in the works in their labs will be one that can and will be embraced by other major participants in the Internet’s e-mail ecosystem. First, an introduction to the problem Google is looking to solve (one that it’s recent IMAP announcement is probably related to). Second, what Google is thinking about.

If you follow what I’ve been writing about spam for what seems like forever now (more than five years), you’ll know that I’ve talked about how beating spam requires a variety of new and universally deployed (in e-mail clients, servers, and services) protocols, all of which work together to reduce the ’surface area’ in the Internet’s e-mail system that makes spam possible.

One foundational protocol that gets discussed a lot is a universal sender authentication protocol, the purpose of which is verify that an incoming e-mail is really from the sender it purports to be from. One of the biggest vulnerabilities in the Internet’s e-mail system is how an e-mail can easily pretend to be from someone it’s not (like your bank or eBay — a weakness that has given rise to a form of spam known as phishing).

There are a number of authentication protocols floating around — none of which has been universally deployed into all e-mail systems. That sort of ubiquity can be achieved if only the four biggest e-mail technology providers (Microsoft, AOL, Google, and Yahoo a.k.a MAGY, pronounced “maggie”) would come to an agreement on one technology that they’ll all support. But, even if the four companies can come to some agreement, a universally deployed authentication protocol can only go so far in the war on spam.

Even though you may have established that an e-mail is indeed from the person or domain it claims to be from, that doesn’t necessarily mean it’s e-mail you want. Most of us get plenty of unwanted e-mail from legitimate senders. One man’s junk is another man’s treasure. The definition of spam, or unwanted e-mail (I’m refraining from usage of the phrase ‘unsolicited commercial e-mail’ because I think it’s too confining), varies from one Internet user to the next. What you want to allow into your inbox and what I want to allow may be two very different things.

One nasty side effect of the war on spam is what I call the ‘deliverability problem.’ Every time I write about spam, I get e-mails and Talkbacks from people who say they’ve found the ultimate solution. Invariably, these are solutions that do a really good job of filtering out spam without too much collateral damage (where some legitimate e-mail gets mistakenly classified as spam and is also filtered out). But when I ask them what their wonderful solution does to make sure the e-mail they’re sending to other people doesn’t get automatically shuffled into the recipients junk mail folder, that’s when they realize that they don’t have the ultimate solution. False positives are more troubling than the spam itself because of how easily a mission critical e-mail — one that hard dollars could be connected to — might never make it to its recipient. This is why standards are important. Sending and receiving e-mail systems need to be able to engage in a series of handshakes that, when taken together, will go a long way towards solving both the spam and deliverability problems.

Another nasty side effect of the war on spam is the casual, if not lazy, stereotyping of legitimate senders as spammers. By now, you have probably seen something like the “This is spam” button in the Web interfaces of the more popular online e-mail services from MAGY. Spam scholars know all too well that these buttons are kludges that can be very problematic. For example, most e-mail users assume (and rightly in many cases) that by pressing the This is Spam button while viewing an e-mail, they are issuing instructions to their e-mail server to blacklist future e-mails that, in some way, match the current e-mail.

One big problem is that the This is Spam button is a far more convenient way to unsubscribe from a newsletter or automatic mailing (like the one that you might get from FaceBook, LinkedIn, etc.) than the official process you’d normally go through to officially unsubscribe or stop those e-mails. Here again, some collateral damage results from Read the rest of this entry »

October 29th, 2007

What's worse? The spam itself? Or how anti-spam solutions block legitimate mail?

Posted by David Berlind @ 11:57 am

Categories: General, Google Apps To-Do List, IT Management, Personal Technology, Security, Software Infrastructure, Web technology

Tags: Folder, Anti-spam, Gartner Inc., E-mail, Spam, Viruses And Worms, Security, Online Communications, Spam And Phishing, David Berlind

After being in New York City last week and being busy almost the entire time, I spent a good part of the weekend catching up on e-mail. I have more inboxes than I care to admit and use more technologies than I should be using to see access them (Via the Web, Thunderbird, Outlook, etc). Somewhere on my to-do list is a day or two’s worth of purging and consolidation. These e-mail marathons usually include the tedious job of searching junk mail and spam folders for any legitimate e-mails. When it comes to e-mail, most of us (e-mail users and the e-mail solutions providers that serve them) have lost our sensibilities. The facts that (a) legitimate e-mail finds its way into our junk mail folders, (b) we must spend our time searching through junk mail folders for that legitimate e-mail, and (c) we somehow think this is normal, is proof that we’re gluttons for punishment.

So, let me make this abundantly clear: the very second you must access your junk e-mail folder to make sure there’s no legitimate e-mail in it is the very second in which your anti-spam technology has become entirely useless to you. After all, the whole idea of anti-spam technology is to make it so that you don’t have to wade through illegitimate e-mail in order to read your legitimate e-mail — all of your legitimate e-mail. One statistic that anti-spam solution providers pride themselves on is the fewest number of false positives. That is, they’ll boast that their systems make the fewest number of mistakes when it comes to misclassifying a legitimate e-mail as spam (and dumping that legit mail into your junk mail or spam folder). To me, this would be like an amusement park bragging about the fewest number of deaths.

Let’s be clear. Even one false positive is unacceptable. In fact, I’d argue that just one false-positive is even worse than a bunch. What’s harder to spot? One needle in a giant haystack? Or 20 or 30? If you’ve ever scanned a junk mail folder with 100’s of entries, only one of which is legit, spotting that one is actually harder than spotting a bunch because of the way we are so easily desensitized by seas of text. Ultimately however, it doesn’t matter. The fact that we have to look at all completely defeats the purpose of having a junk mail folder. We might as well just let the spam flow into inboxes because having to look in two folders for our e-mail is just the same as having to look in two inboxes. You still have to look.

OK, so you don’t have to look. That is, so long as there isn’t a chance that a critical e-mail may have ended up there. But what’s non-critical? Several recent scans of my junk mail folders revealed the following false positives and how that false positive affected me:

• Someone that I would drop everything for was coming to town on short notice and wrote to me to see if I wanted to get together with them. I missed the opportunity.
• A service that I pay for annually was about to expire and was reminding me via e-mail to renew. Luckily, I caught it before it expired.
• A vendor wrote to me with a correction to something I wrote on ZDNet. It took longer than either of us would have liked for me to correct the text.
• Readers write to me with tips for Technology Shakedowns or their own thoughts on what I’ve written. I like to write back to readers and thank them for writing to me on a timely basis. But that sometimes doesn’t happen because their e-mail is getting falsely accused of being spam.
• My bank actually sent me a real e-mail having to do with security measures. With so much phishing going on, it is nearly impossible to tell the difference between an e-mail from your real bank and some imposter pretending to be your bank. Fortunately, I look closely at anything that says it’s from my bank just in case it really is. But should I have to do this?
• Someone I had an appointment with had to change that appointment. I showed up at the originally scheduled time and bumped into a competitor. Can you say “uncomfortable”?

I could keep going but won’t. You get the picture. Once you realize that these sorts of mission critical e-mails are being routed to your spam folders, you have no choice but to keep an eye on those folders too.

It raises a serious question. What’s worse? The spam itself? Or, the nasty side-effect of anti-spam solutions whereby important e-mail isn’t getting to its recipients on time, if at all. For me, all it takes is one missed deadline. Or one canceled appointment. Or one missed critical business communication for me to realize that one of those snafus is far more costly to me as a businessperson than all of the spam taken together. Can’t decide? Put yourself in the sender’s shoes. Actually, you don’t have to do that.

Chances are, you send e-mail. What’s worse? The spam you’re getting or the fact that some mail you are sending is getting falsely classified as spam on the other end by an anti-spam system that you have no control over? During my junk mail folder cleansing operation this weekend, I decided to do something differently (perhaps you’re one of the lucky few who heard from me?). For every false positive (and there were many), I wrote back to the person with the following message or something similar:

Just fyi… outlook rejects your e-mails as spam. No idea why. Outlook doesn’t tell you.

So, first, a couple qualifiers. Here at CNET Networks, we use Spam Assassin at the server level and Outlook’s built-in filtering at the client level. When Spam Assassin catches something, it adds an attachment that tries to explain why the e-mail in question passed the corporately set “Is this spam?” test. When this attachment was present, I furnished that information as well. But for e-mail that makes it past Spam Assassin’s watchful eyes (and plenty of spam does), Outlook 2003 has its own anti-spam technology to serve as a backup. When Outlook 2003 thinks something is spam, it doesn’t tell you why the way Spam Assassin does.

I wasn’t about to dig around these e-mails to figure out. It’s not my job and I don’t have the time for every false positive that comes in (now that there are so many). But I’d hate to have to be the poor IT guy on the other side where now, they’ve been notified that their business-critical communications may not be getting through to the intended recipients. How many e-mails didn’t get through? Don’t know. What was causing the problem? Don’t know (even when Spam Assassin tells you, you have to be a rocket scientist to figure out what it means). It’s a complete breakdown of a system that senders everywhere are depending on.

This, my friends, is known as the “deliverability problem.” If you’ve noticed legitimate mail getting falsely classified as spam on your end, then you know it’s happening to your outbound e-mail on the other end. How many times have you said to someone “Didn’t you get my e-mail?” and had the other person say “No, maybe it got trapped by my spam filters.”

Invariably, in response to my rants about spam, my inbox and my junk mail folder get loaded with pitches from anti-spam solution providers who will swear until their blue in the face that I must try their system because of how much more accurate it is than the rest of the solutions on the market (especially mine). The funny thing is that even though they don’t realize it, they all say the exact same things. Here are some bullet points. Feel free to cut and paste if you work for an anti-spam vendor:

• Our system is patented (whoop dee doo. Some kid filed for and was awarded a patent for swinging sideways on an ordinary swing).
• It was developed through man years of research by security experts in Tel Aviv (that’s right, Tel Aviv attracts better spam researchers than any other city in the world).
• The inventor of our system has a Ph.D. (no comment, I don’t want hate mail from Ph.Ds unless my anti-spam system will falsely classify it as spam).
• I’ve seen this Dave and I’m telling you, it really works (Your definition of “works” and mine are very different).
• The Gartner Group has seen this and they agree, there’s nothing quite like it (It’s one of the most unfortunate facts about the anti-spam ecosystem — no two solutions are created equal. That’s part of the problem).
• So and so Fortune 500 company is using it (oy vey, the blind leading the blind).
• No honestly Dave, I swear to you. Try this system and you’ll agree that it’s better than anything else out there.

I’m so tired of this e-mail that I usually ignore it. Occasionally, I respond and the first question I ask is, “What does your solution do to solve the deliverability problem?” Answer nothing. Case in point? I’m still arguing with one anti-spam solution provider and, irony of all ironies, most of the e-mails that he’s sending to me, telling me about how his system is so much better than everyone else’s, are showing up in my junk mail folder.

He does however admit that there’s one way to solve the problem; everyone needs to run the same system. In his case, he just thinks it should be his system. In my case, the answer is to make sure the fundamental technologies are baked, as standards, into all e-mail systems. It’s simply unrealistic to think that every e-mail administrator in the world is going to go out and buy the same system. But if the so-called system involves standards that are baked into every solution that’s out there, then, we stand a chance of rectifying the problem.

It isn’t just one standard either. Fixing the problem requires layers of standards just the same way that retrieving e-mail today involves layers. For example, when e-mail servers transmit or receive e-mail from across the Internet, those servers must comply with the Simple Mail Transfer Protocol (SMTP). But for you to get your e-mail into your PC from one of those servers usually requires your e-mail client (Outlook, Thunderbird, etc.) to connect with an SMTP-compliant server over a different protocol. It might be a proprietary protocol like the one Outlook uses to speak with Microsoft’s Exchange Servers (for both mail and calendering) or it might be the POP3 or IMAP standards for e-mail retrieval. The point is that layers are involved and that bit of complexity, which will be required here, shouldn’t deter us from going after the right solution.

For example, going back to my bit of manual labor over the weekend where I wrote back to a bunch of people telling them that their e-mail had been falsely classified as spam, there’s no reason the system could not have done that. In other words, over the SMTP protocol, there could be a variety of error codes that the suspicious system sends back to the suspect to let them know that (a) the e-mail didn’t get to it’s intended recipient and (b) why. Imagine for example if all the people who received my manual generated “non-delivery e-mail” received the same sort of non-delivery message for every e-mail that was falsely categorized as spam from all the other recipients? At least they’d know they have a problem and with whom. They might even be able to zero in on the problem and eliminate it, thereby increasing the chances of deliverability this time.

Arm-chair anti-spam quarterbacks will tell you that this sort of automated response is a terrible idea because it notifies the sender that they’ve found a active inbox. They talk about this like it’s the equivalent of letting the spammer have one foot in the door. This is pure BS. Does it really matter? The system is so broken today that we’d be conceding very little in exchange for something that long term stands a chance. That’s because this would simply be a layer in the system. Other layers (for example, authentication) would take care of spammers’ other means of flying below our radars and weaseling their way into our inboxes.

Finally, as I have said many times before, we can’t make this sort of progress on anti-spam standards (or layers of anti-spam standards) until the world’s largest e-mail solution providers Microsoft, AOL, Google, and Yahoo (MAGY: pronounced “Maggie”) decide to work together to (1) agree on what the anti-spam protocols should be, (2) get their systems interoperating over those standards, and (3) announce a date in the future at which point non-conforming e-mail will be refused entry into their systems. Why they can’t come together to a least take a stab at this on behalf of everyone who is plagued by both spam and non-deliverablity (heck, nothing else is working) remains a mystery to me.

October 15th, 2007

Does payback on email alone make Google Apps' $50/yr. worth it? (Docs, etc? That's icing)

Posted by David Berlind @ 1:30 pm

Categories: General, Google Apps To-Do List, Office 2.0, Software Infrastructure, Web technology

Tags: Software, Cost, Google Inc., Google Apps, Storage, Server, Microsoft Corp., User, Small And Medium Business, Software Assurance

Whenever I talk about doing something crazy like using Google Apps instead of other office suites, a conversation that’s usually driven by my beliefs about computing in the cloud, there are some number of ZDNet readers that chalk it off to insanity or a momentary lapse of reason. Or, maybe I forgot to take my meds that morning. But, on the heels of some unrelated events and discussions that took place over this past week, not only am I more convinced of going after a cloud computing approach like the one offered by Google Apps, I’ve got a different way of explaining the ROI that will probably resonate with many IT managers, small business people, and CFOs better than any other previously used rationale.

First, this is and isn’t a story about Google Apps.

It is a story about Google Apps because of the way Google Apps is currently the best example of how a scale service provider can deliver certain IT functions at such a reduced cost ($50 per user per year) that it is almost impossible not to consider.

For small and medium businesses (SMBs) that can’t afford basic IT fragility, costs, and headaches, Google has figured out what, since 1999, has been the Holy Grail for every company (not just IT) looking for an in with SMBs — how to hook them online. Think about it. To the extent that FaceBook, MySpace, AIM (AOL Instant Messenger) have been outrageously successful at attracting a specific audience and making them stick, who has really had that kind of success with the SMB market? NetSuite, with its blend of salesforce.com-like CRM and Intuit like bookkeeping functionality probably rises to the top. Perhaps eBay as the electronic storefront of choice for many. But no single provider is the FaceBook, MySpace or AIM of SMBs. Meanwhile the SMB market in aggregate is widely recognized as being the most lucrative to those who can crack it. So far, despite thousands of attempts (a good many of which I was involved with back in the 1999-2000 timeframe), no one has.

This isn’t a story about Google Apps because to the extent that Google finds a way to crack the SMB market the way no one else has before, Google Apps won’t be the only offering of its kind from a provider that’s in Google’s league. The SMB market is simply too important to too many of Google’s competitors for Google to be allowed to run away with the show.

So, bearing in mind that this is as much as a story about the future competitors to Google Apps as it is a story about Google Apps itself, consider the following.

As seems to happen every couple of weeks (or sooner if some person e-mails me a message with a 5 MB attachment), I get an automated message from our Microsoft Exchange server that tells me that my inbox is over its storage limit of 150MB. Given how close my inbox always is to that threshold, I just got one of those “purge your inbox or die!” messages last week. At first, the message is like a nudge. But if I ignore it long enough, the server simply goes into action and rejects all outgoing mail. It tells me it’s doing this, but it’s nice enough to let the inbound mail, including spam, flow in.

After not touching on the topic in at least a year, last week, I had a conversation that had to do with migrating from IBM Lotus Notes to Microsoft Exchange (strangely, in the last five years, I’ve never heard of anybody going the other way). That conversation morphed rather quickly into a pros/cons discussion of outsourcing e-mail.

Back in February of last year, my fellow blogger Phil Wainewright asked “What’s the true cost of running e-mail in-house?” The truth is, I’m not sure anybody knows the answer to that question because so much of that cost is fuzzy. For example, whereas storage architecture is the life-blood of outfits like Google (not just for e-mail, but for search, YouTube, etc.), Amazon (with its S3 service), Yahoo and Microsoft and their scale affords them certain opportunities to cost effectively increase overall capacity, storage is a checklist item for most non-IT companies (I said “most.” Not all.).

The typical thought pattern goes something like, “how much storage do we need to bring that application online?” A decision gets made, product is purchased, the application is set up and until its users get nearly mutinous about its limitations or something catastrophic happens, the IT staff attends to other tasks. Even with storage coming down so dramatically in cost per gigabyte the way it is, the idea of doubling that server’s storage capacity is still painful enough to someone’s budget that it’s simply not an option until things really start to break.

Meanwhile, in comparing notes with other people who rely on some sort of corporate e-mail system, pretty much every person I talk to has a limitation on their inbox size. For some, it’s less than the 150MB limit. For others, it’s more. But one thing is for certain: now that e-mails are just as likely to have a multi-megabyte movie or PowerPoint attached to them as they are 10 words of text, everybody groans when it comes to the limitations on their inboxes. Yet somehow, for absolutely no cost, Google can provide you with the same inbox and e-mail address (yourname@yourcompanydomain.com) with a limit of 2GB. Pay $50 per user per year, and then, the ceiling for everyone in your company goes up to 25GB. For me who has been struggling with the 150MB limit for years now, that would be more than 177 times the storage I’m allowed now.

Going back to the fuzzy costs of e-mail, on the basis of storage alone, I’d posit that Google’s charge of $50 per user per year is probably enough to cause any SMB or CFO in larger organizations to re-examine their current e-mail choice.

For example, when I hit the limit, which is about once per month, I spend around 30 minutes digging around my e-mail looking for stuff to delete. Junk mail is an obvious one but a block-delete there is a bad idea given how many legitimate mails are getting routed there. My sent mail folder is another no brainer, especially if it has a few outbound emails in it that have big attachments connected to them. Then, I dig through my inbox (sorting on the basis of attachment size) and where there are e-mails with really big attachments that I need to keep, I save those attachments to my local hard drive (a re-allocation that I wish my e-mail could easily keep track of) and delete the mail. Finally, I purge my Deleted Mail folder.

Let’s say I spend 6 hours of my time on this exercise every year. I can guarantee not just my employer, but most employers, that the 6 hours of time their employees may be spending annually on this futile exercise is worth more than the $50 you’d pay for each one of them so this wouldn’t be a problem. Or, let’s try the math another way. There are some number of people in your company where there’s no cost to keeping their inboxes clear. Either their hourly wages crash the break even analysis or their inboxes never come remotely close to reaching their limits. But, on the other hand, there is some number of highly paid people in your company who are worth $300 per hour. Over the course of the year, the 6 hours they spend purging their e-mail costs $1800. That’s 36 users of Google Apps Premium.

Of course, we’re still talking about one extremely fuzzy cost. Never mind all the others that would take us a while to list before we finally came around to the hard dollar costs. Last year, after some local weather-related event, the e-mail server on which my account resided became inaccessible. Several single points of failure between my PC and the server had failed. The local area network was down. Power was out. The virtual private network was down. Naturally, having once been a Lotus Notes user and having been able to recover from an IT disaster like that by simply dialing into another location and attaching to a different Notes server to which my e-mail was routinely replicated, I thought I’d be able to do the same thing between my Outlook client and some other Exchange server at another geographical location that was still accessible. But this wasn’t the case.

So, I inquired with our IT people as to why things were the way they were. The answer was cost. In fact, it doesn’t matter whether its Notes or Exchange (even though it seems as though Notes’ replication architecture makes it better suited to this sort of fault tolerance). The expense (servers, software, networking, etc.) of having such redundancy was so outrageously prohibitive that basically, someone made the decision that the staff would have to grin and bear it in the event that the one server that hosted each person’s mailbox went down. One issue, according to the IT people I spoke with, was scalability. There comes a threshold (in terms of number of users) where you simply have no choice but to add another e-mail server to your server room or data center.

But with Google Apps, adding users (starting with the first one) and giving them 25GB of personal storage never requires an additional server and only costs $50 per user per year. Alternatively (and completely forgetting any of the hardware costs for a minute), once you’ve navigated Microsoft’s complicated labyrinth of server software, client software, client access licenses (CAL) , and software assurance, $50 per user per year for an e-mail and group calendaring system that requires minimal oversight from someone in the IT department (again, completely forgetting about the hardware), seems like a pretty good deal (not to mention how differently it hits the books because its a service).

For example, assuming you’re an SMB using a Microsoft Volume License (which you would for 5 or more users) and you’re getting one of those standard 30 percent discounts from some reseller of Exchange, you could expect to spend around $660 on a copy of Exchange Server with the kind of upgrade protection (what Microsoft calls Software Assurance) that ensures you’ll be able to upgrade when a new version comes out (at no additional cost). The cost of Software Assurance (approximately 35 percent of the acquisition cost of your software) recurs once every two years. With that same 30 percent discount, for each CAL required to access that Exchange server (CALs are required regardless of client software used), you pay a one time perpetual licensing fee of $47 ($67 list price x .70) plus about $8 every year for Software Assurance (SA). In other words, $63 initially and then $8 every year after that (fyi: Microsoft only sells SA in two year chunks so it’d be $16 for 2 years of SA). According to the licensing specialist I spoke to at 800-426-9400, the reason a CAL needs SA is because CALs are not transferrable when you upgrade your server. Upgrades to servers require upgrades to CALs as well. SA assures you that you won’t have to pay the full boat for new CALs.

Or, for the server side of e-mail and group calendaring (Microsoft has completely separate charges for client software like Outlook), you can pay Google a straight fee of $50 per user per year, never have to worry about hardware, backing up, etc. and, oh, by the way, when Google upgrades its e-mail service which seems to happen pretty often (in other words, you don’t have to wait for major releases to get some cool functionality upgrade like what was added as a result of the Postini acquisition), the IT people barely have to lift a finger (oops, there are those fuzzy costs again!). All the end-users have to do in their browsers is press the refresh button. By the way, for organizations paying the $50 per user per year charge, Google promises 99.9 percent uptime.

Guess what? None of this analysis is meant to paint Exchange Server in a negative light. For some organizations, Exchange Server along with some of the other products that Microsoft is just now coming to market with in the area of unified communications are great solutions that hang together really well and for some organizations will provide terrific ROI. What I’m trying to point out is that when you factor in all the hard and soft costs of running an e-mail system — the servers, the storage, the networking, the fault-tolerance, the accessibility, the software, the upgrades, the people, the spam, etc. — $50 per user per year ain’t such a bad deal to get the sort of e-mail system that Google Apps gets you.

Enter: All the people who poop on Google Apps because, relative to the cost of Microsoft Office, paying $50 per user per year isn’t such a great deal (they have their break-even analyses and, to give them the benefit of the doubt, let’s assume they’re fair). OK, fair enough. If the only reason to look at Google Apps is for its ability to do the sort of stuff you’d do with Microsoft Office, then maybe Google Apps is no clear winner. But then again, although I’m sure they exist, I can’t imagine many companies becoming clients of Google Apps without taking advantage of the e-mail functionality which, as I just proved, is probably worth more than $50 per user per year when you consider what it costs to run your own solution. In other words, all the Office-like functionality is simply icing on the cake. Not to mention the collaborative abilities built into it, the Start Page that all users get (the organizational equivalent of iGoogle), and the free Web hosting.

Finally, as a Google Apps user, I’ll be the first one to admit that you must accept some compromises when you move into the so-called “cloud.” Yes, your applications may not be accessible while you’re disconnected from the Internet (that problem is temporary thanks to Google Gears). And yes, you’re trusting Google with what could very well be incredibly sensitive information (the Googlefolk occasionally remind me that if they EVER screw that part up, it’s game over for them… in other words, they take that trust very seriously). And, the apps aren’t nearly as robust as their desktop competitors. I was reminded of this yesterday when a document I created in Google Docs neither translated the way I expected it to when I saved it as a PDF nor did it look very good when I cut and pasted its HTML into a regular Web page (it took a bit of hand editing, but I finally got it fixed). Google Apps is most definitely a work in progress and not nearly as mature as MS Office.

But all this said, there are a lot of organizations that might be willing to accept these sacrifices once they consider what they might be getting for their $50 per user per year and whether they really need anything more.

Finally, a reminder that this really isn’t about Google Apps. It’s about the model of Google Apps that will invariably be repeated by others — a model where just one part of the offering (in Google Apps case, it’s e-mail) makes for such a compelling ROI story that it makes it a lot easier to overlook the shortcomings of the rest of the package (provided there are any such shortcomings in the context of your organization’s needs).

October 11th, 2007

Desperately seeking: The ultimate x-container 'ubertagger' & Google's answer to del.icio.us

Posted by David Berlind @ 1:46 pm

Categories: General, Google Apps To-Do List, Green, Office 2.0, Personal Technology, Software Infrastructure, Web technology

Tags: Google Inc., Google Gmail, Del.icio.us, Google Reader, Item, Yahoo! Inc., GreenComputing, E-mail, RSS, Online Communications

There’s no question that one of the great deliverables of social technologies and networks is the way in which they efficiently aid us in the filtering and organizing content. This is not a story about RSS, but I want to use it as an example of a technology that’s relevant to the larger challenge of sharing and/or archiving content that’s hosted in multiple but dissimilar “containers.” I see it as an uber-tagging problem.

RSS is unquestionably a social technology and for the sliver of Internet users that have discovered and leveraged it so far (and, percentage-wise, it’s still a sliver), there’s a good chance that they’re wading through far less muck than others are in order to snack on the content that most interests them.

For example, I rarely if ever visit the main entry points (home pages, category pages, etc.) of the tech media (InfoWorld, eWeek, ComputerWorld, Slashdot, The Register, ZDNet, etc.) any more. With their different layouts, it’s far too time consuming for me re-orient myself as I jump from one of those sites to the next, only to have to dig around their pages looking for the content that most matters to me. RSS readers like Google Reader (the one I use), Newsgator, and Attensa give me one interface (no re-orientation necessary) through which to experience the latest content from all my favorite sources (an act that by itself efficiently weeds out the sources I could care less about).

It takes some discipline, but part of my daily ritual involves periodic visits to a Firefox tab that’s always open to the “New Items” view of my Google Reader account and:

• Hitting the refresh button
• Using the “N” key (for “next”) to advance through the headlines that arrived since I last visited the tab
• Pressing the “M” key (for “mark”) to mark the headlines I don’t care about as “read”
• Hitting the refresh button again so the marked items disappear and all the remains are unread items — the items I intend to do something with.

In fact, I’ll bet that for most people, virtually every act of content consumption ends this way. Whether it’s our RSS readers, our e-mail inboxes, our voice mail, some set of search results, or just random visits to Web sites, we’re doing one of three things with each item we encounter; we dismiss it, we act on it immediately (eg: I reply to your e-mail) or we archive it with the intention of acting on it later. Archiving an item could be a simple as leaving it where it is. After all, as long as you’re not dismissing it or acting on it now, you’re saving it for later (another word for archiving). When we do that, whatever container it’s in (eg: our e-mail client) ends up becoming an unnatural extension of our to-do list.

Thankfully, to make it easier for us to take action on that archived content later (which means having to find it), we have plenty of organizational tools at our disposal for categorizing and clustering related items. Some are socially oriented. Others not. Herein lies the problem: if I have 10 related items that, for archival purposes, need to be clustered together with the idea of using them all in some single future project, and 3 of those items are in e-mail, 3 are in my RSS reader, 2 are simply Web pages I visited, 1 is a document on my hard drive, and another is a message that someone texted to me on my cell phone, how do I easily find and retrieve them from that one archive (virtual as it may be)?

Via e-mail for example, I get pitched by vendors on all sorts of stories. Some get dismissed (deleted). Some get acted on right away (I’ll reply, write about them, tweet about them on Twitter, or forward them to fellow bloggers that might want to write about it themselves). Others, I archive thinking that I’ll come back to them and write them up in my blog, or I’ll come back to them as part of a larger project that I’m working on.

Let’s say that project is one on green computing. But let’s also say items are also arriving in my RSS reader that have to do with green computing as well. In Outlook, I could file the e-mail in a folder called “Green Computing.” In Google Reader, I can tag the item with the tag “Green Computing.” If I happen across some content on the Web that didn’t show up on one of my “antennas” (email, RSS), I can bookmark it in a Firefox bookmark folder called “Green Computing.” Ideally, I don’t want to have to go to multiple places to get at all the archived information that’s relevant to my Green Computing project when the time for that project comes up.

As more business people begin to discover the efficiency of social tools when it comes to discovering and archiving content that’s relative to them and those social tools end up as part of their organizations’ IT fabric (whether the IT department knows it or not), the larger challenge of efficiently organizing and collaborating over that information is going create some technology challenges, perhaps forcing IT managers to rethink their infrastructures and set some standards.

Today for example, there are ways to “ubertag.” But unless certain solutions are escaping me (please let me know if you know of one or more), not only does ubertagging force you into making some long term commitments that you might later wish you hadn’t made, there’s also a bit of friction that makes it feel rather unnatural.

For example, one way to solve the the problem above is to annoint your e-mail client as the ubertagger. Using the above example, if I’m using Outlook (a decision) and the Newsgator plug-in for Outlook (another decision), I could create a folder called Green Computing (I can even make it a shared folder for collaborative purposes) and archive Green Computing-related RSS items as well as Green Computing related e-mail into that folder. I can even drag the URL’s of randomly visited Web pages from my browser into that folder.

In my case however, once I do that, Outlook’s security prevents me from opening it for fear that it’s an unsafe item. I can probably reconfigure Outlook to let me open it, but then, am I creating some other vulnerability that’s not worth creating? To work around the problem, instead of dragging the page into my Outlook folder, I can send it to myself via e-mail and then drag the resulting e-mail into the Green Computing folder. Not only do a lot of Web pages I visit have an “e-mail this story” button, both Firefox and Internet Explorer can send the current URL via e-mail to the recipient of your choice.

Another approach, one that I was playing around with this morning, relies on Yahoo’s del.icio.us social bookmarking service. Suppose for example you don’t want to use Outlook or an RSS reader that can be plugged into it like Newsgator. If a Green Computing item shows up in Google Reader’s river of headlines, I can click through to the actual Web page and post it as a bookmark to my del.icio.us account and tag that bookmark “GreenComputing.” Even better, I could use the del.icio.us plug-in for Firefox and instead of having to click through Google Reader in order to retrieve the page that I want to post to del.icio.us, I can right click on the URL in Google Reader and post that URL directly into del.icio.us (with the GreenComputing tag) through the resulting pop-up dialog.

Likewise, if I’m using Web based e-mail (eg: the non-AJAX version of GMail), I can also bookmark and tag individual e-mail items in my del.icio.us account. The same goes for documents if I pick a Web-based productivity suite like Google Apps which is capable of assigning the equivalent of a bookmarkable permalink to each document (with the one caveat being that not everybody who can see your del.icio.us bookmarks will be able to see those documents because they won’t have the credentials to get into your Google Apps account).

What got me into thinking about ubertagging (or uberfoldering as it may be)? In the course of sifting through headlines in Google Reader, I started to take advantage of Google Reader’s tagging capability. For example, right in Google Reader, I can tag some item for “GreenComputing.” Much the same way GMail allows for tagging of e-mails in such a way that you can dive into a tag and see all e-mails to which that tag was assigned, tagging an RSS item in Google Reader creates the equivalent of a folder in Reader’s left-hand nav that can be used to view nothing but RSS items for one tag like GreenComputing.

But the more I used it, the more I realized it was becoming a relatively isolated island of personal technology. If for example, I randomly encountered a page through Google Search that I’d also want to tag for GreenComputing, I could do it through del.icio.us. But to get that URL into Google Reader, I’d have to take the extra step of subscribing my Google Reader to the RSS feed associated with my del.icio.us account and then waiting for the page that I bookmarked in del.icio.us to show up in Google Reader and then using Google Reader to tag it. I could also pipe everything over to GMail (eg: send Web pages to my GMail account) and use GMail’s tagging capabilty to arrive at what’s essentially the same conclusion. Only in that case GMail is my ubertagger instead of Google Reader. OK, it’s not pretty and I can’t imagine one of the clerks down in the general counsel’s office figuring out a work around like that, but hey it works.

At some point (this is hopefully on Google’s to do list), I’ll be able to access Google Reader with the same Google account that I use to access Google Apps (I can’t seem to do that right now) and, by doing so, Google will centralize my tag taxonomy in such a way that, whether I’m tagging Google Apps documents, Google Reader RSS items, or GMail-based e-mails, I not only have access to all three through the one tag, it’s also in a collaborative context so that those I’m working with can join in on the fun. When you think about this, it’s hard to imagine search results not coming into play here which is why, if you ask me, between the need to tag and the need to collaborate, Google can’t avoid having a del.icio.us competitor at some point. Even if it has to “back” into it.

Finally, in the bigger picture, given the collaborative possibilities with just about any approach, there are some important implications for IT managers to consider as more so-called information workers start to discover the efficiency of social technologies and, in the course of working around the friction in ways that I’ve described, end up making choices that may not necessarily jive with the choices that others within an organization are making. It can’t hurt to start thinking strategically about this problem now so that somewhere down the line when it makes more sense to standardize on certain social technologies, a handful of your earliest adopters aren’t faced with some sort of massive and painful export/import project.

October 5th, 2007

Technology Shakedown #9: Why AOL, Google, Microsoft, and Yahoo are to blame for spam

Posted by David Berlind @ 9:33 am

Categories: General, Google Apps To-Do List, IT Management, Office 2.0, Personal Technology, Software Infrastructure, Technology Shakedown, Video, Web technology

Tags: Google Inc., Google Apps, America Online Inc., Yahoo! Inc., Problem, Video, Microsoft Corp., E-mail, Cyberthreats, Spam

Yesterday was the last straw for me when it comes to the way spam is impacting my work. First, before purging the junk mail folder in my Outlook, I did a quick scan only to notice that almost every other e-mail that was classified as spam was actually a legitimate e-mail that should have flowed into my inbox. Why was it in my junk mail folder? I have no idea. That’s part of the problem. In many cases (not all), you can’t look at the e-mail, see what the offending issue was, and notify the sender of why their e-mails are getting classified as spam.

But that wasn’t all that happened yesterday. For the events company (Mass Events Labs) that Doug Gold and I co-own to produce Mashup Camp, Startup Camp, and other events, we use a masseventslabs.com-specific context of Google Apps for e-mail, documents, spreadsheets, etc. In other words, when Doug and I send e-mail to each other through the masseventslabs.com domain, both he and I are sending and receiving from and to a Google Apps-based version of Google’s GMail. Yet somehow (as you can see in the attached video), yesterday, when he replied from his Google Apps account to an important e-mail that I sent to him via my Google Apps account, GMail redirected his reply to my spam folder. How can this be? That’s the equivalent of users of the same, behind-the-firewall copy of Microsoft’s Exchange Server not being able to send e-mail to each other because it’s getting classified as spam. Surely, an e-mail server has some idea of when the source of e-mail is itself.

So, what’s the problem and whose to blame for “friendly fire” and other SNAFUs in the battle against spam? The problem is that the major e-mail technology providers won’t work together to come up with some standard approaches to stopping spam. And when I say major, I mean AOL, Google, Microsoft, and Yahoo. If those four companies simply got together and said it’s time to fix the problem and here’s how we’re going to fix it, the rest of the world would have no choice but to follow. Don’t agree with me? Watch the video. From my interview the other day with Matt Glotzbach, director of product management for Google Enterprise, I extracted the part where he unequivocally agreed that that’s all it would take.

Yet, here we are, more than five years after the major e-mail tech providers said that they’d find a way to curb the problem, and the situation is markedly worse. Markedly. Compounding the problem is that there is some cooperation going on between pockets of vendors and Web sites here and there. But the end game there will be separate Internets. If Yahoo! and eBay get together as they’ve just done to address phishers going after users of eBay and PayPal and Google does something different with GMail to address phishers going after users of Google Checkout, pretty soon, you end up in a situation where you have to enter completely different multi-site contexts (walled Internet silos) to get anything done. That was not the idea behind the Internet.

So, are you outraged enough to join me in taking action? How can we (you and I) solve the problem. We have to put the pressure on AOL, Google, Microsoft, and Yahoo. I’ve recorded a video Technology Shakedown (see above) and I’ve licensed it under a Creative Commons license that allows you to re-use it anywhere you want. It’s not easy to grab our videos from ZDNet (I’ll work on that). So, if you want a copy of the video to paste into your blog or Web site, feel free to grab the YouTube version. Maybe together, we can all send a clear message to these four technology providers that its time to stop dilly-dallying and to lead the Internet to a standard “stack” of anti-spam solutions that will have most spammers and phishers looking for a new line of work.

October 2nd, 2007

Interview: Google completes integration of Postini into Google Apps Premier Edition

Posted by David Berlind @ 9:07 pm

Categories: General, Google Apps To-Do List, IT Management, IT Matters Podcast, Office 2.0, Podcasts, Software Infrastructure, Web technology

Tags: Google Inc., Google Apps, Postini Corp., Integration, E-mail, Podcasts, Online Communications, Internet, David Berlind

It was not even four months ago that Google announced it would be acquiring the anti-spam, anti-virus, and e-mail compliance outfit Postini. Today, the company is calling on the press and bloggers to inform them that, not only is the acquisition complete, but so too is the integration of Postini’s offerings into the Premier Edition of Google Apps.

Google Apps is an organization-targeted package of several of Google’s applications such as Documents, Spreadsheets, Presentations, and e-mail (GMail) that Google markets as a different offering from the stand alone versions of the Web-based applications. Whereas the base version of Google Apps is free, the Premier Edition (largely targeted at enteprises) costs $50 per user per year. In addition to the free phone support that the $50 gets you, the company announced today that it is (a) offering the Postini functionality at no additional cost and (2) upping the e-mail storage limit for Premier Edition customers from 10GB to 25GB.

To get more of the details on the integration news, I interviewed the director of product management for Google Enterprise Matt Glotzbach. To listen to the interview, press the play button on the Flash-based podcast player above, or, if you want, there’s a download option to grab the MP3. If you’re subscribed to ZDNet’s IT Matters series of podasts (see how), it should show up on your system, MP3 player, or both automatically. In the interview, Glotzbach and I riff on some of the standards that would be good to have in order to eliminate spam. He talks a bit about the granular level of spam-control that Postini brings to the Google Apps portfolio. For example, e-mail senders can be whitelisted for an entire organization, by group, or just for a particular recipient (and, based on central policy, recipients may have the ability to make their own configurations).

Although he wasn’t prepared to make any official announcements about API consolidation and portfolio changes, Glotzbach indicated that, like many of the Google Apps services, Postini has several APIs that it makes available to third party developers and that somewhere down the line, they’ll be looking at ways to reconcile the Postini API infrastructure with Google’s API infrastructure.