Paul E. Jones' Blog

As many of you probably know, Avaya acquired Nortel's enterprise assets a few months ago. Now, they're out making noise about how Avaya is more powerful and stronger than ever before. They are Avaya to the power of N!

Here's an ad Avaya is running:

I laughed when I saw that. So, Nortel has been and still is a sinking ship, meaning its value is approaching 0. So what do we get from this equation? At least it isn't zero, I suppose.

While the fact that Internet Explorer's market share is shrinking is not news, what I found interesting is that November 2009 was the first time that Internet Explorer was used by fewer than 50% of the visitors to Packetizer.

Really, I'm amazed. Well, perhaps I'm not. I commented earlier that I had gotten fed up with Internet Explorer and I switched to Firefox. Still, it is amazing to watch the percentages shift like they have over the past two years. If I had time, I'd provide a graph.

So where are users going? Interestingly, users seem to be moving in two directions: Firefox and Apple's Safari. While Firefox is not a huge surprise, what was a surprise to me was that 8.3% of the visitors in November 2009 used Safari versus just 0.6% in November 2007.

Is it time I bought a Mac?

It has been a couple of years since we started implementing new spam prevention measures on Packetizer. Spam had reached such levels that it was almost impossible to read legitimate email, because individuals (including me) were receiving in excess of 600 spam messages every day. To say the least, it was insane.

We now have spam volumes reduced to a level that is manageable, perhaps allowing 10 to 20 spam messages through per day per user on the system. Of that, virtually all of it is effectively detected and filtered out as spam.

While the situation today is significantly better than where we were a couple of years ago, what concerns me is the fact that so much spam originates from "trusted networks". We operate a blacklist on Packetizer so that "repeat offenders" get blocked, but some networks are known repeat-offenders, but we simply cannot block them. Examples include Yahoo! and Hotmail. For Packetizer, those are the top two spam transmitters, with Google often right behind them (though not lately, interestingly). More troubling, though, is that they are not just a little more problematic, but significantly more problematic. But what can they do? They are web sites where anybody without an email address can quickly and easily create one: they provide a great service. Even so, there is no way to imagine how many "disposable" spam accounts get created daily on those networks.

As noted in the Packetizer News section, organizations that are supposed to be helping to fight spam are actually becoming a problem themselves. Organizations like Spamhaus, MAPS, SORBS, and UCE PROTECT have proven to be a disservice to the public to some degree this year. The reason is simply that they just block mail based on IP addresses. Packetizer does that too, but it's because there are no alternatives.

What the industry needs to do is to start implementing DKIM. Do it immediately. DKIM is not intended to be a spam prevention tool, but it can be a valuable tool nonetheless in fighting spam. If every domain owner signed messages with DKIM and required all mail transmitted from their domain to be signed, then it would be relatively easy to establish a certain level of trust in those domains. Rather than blacklisting IP addresses, we can blacklist domains. I believe this would be a better solution, because domain owners can usually be tracked down. If registrars follow the rules as required by ICANN and insist on having accurate domain registration information, it would most definitely be easier.

I am tired of receiving spam and I think it's time that we — all of us on the Internet — encourage changes that help address the problem.

In the wake of Google's acquisition of Gizmo5, Tsahi Levent-Levi raises some good questions and made some excellent points in his blog posting on protocol interworking and the pain it introduces. Like many others, I have an opinion on this.

Google needs a way to interwork with the SIP-enabled gateways and SBCs, but SIP really isn't in line with its web strategy. XMPP, on the other hand, is since it utilizes XML and has interfaces like BOSH that allow one to get presence information and even do IM via the web browser.

Most people who know me are well-aware of my opinion of SIP: it is a nice client-server protocol for voice and video, but it falls significantly short trying to do anything more than that. SIP was initially intended to be a light-weight protocol that breaks away from the traditional telephony model, but has in fact fallen into the trap of replicating the PSTN over IP, implementing much of what was in the PSTN world and behaving like a traditional telephony protocol. It is not the web-centric, simple, light-weight protocol it was supposed to be: it is quite the opposite.

XMPP is web-centric in many ways and is very flexible. Heck, they are building things like Google Wave on top of that infrastructure! So, it makes a lot of sense trying to use XMPP in the core and pushing SIP to the edges for interworking with the rest of the world.

That said, perhaps Google has come to the realization that few have implemented Jingle and their plans are to marry SIP + XMPP into a single client. I can imagine IM and presence functions being handled by the XMPP side and SIP used for voice/video.

That makes sense for GoogleTalk, but what about the Google's Chrome OS? What kind of voice/video support will be available there? The only way to do that is via some plug-in to get voice/video capabilities from JavaScript, but perhaps that's exactly what they'll do.

Long-term, I agree they would be best-served by having a single protocol, but SIP cannot be it: it lacks the web-centric capabilities that Google needs to enable richer forms of communication available via XMPP.

I've been a long-time fan of Internet Explorer. Really, I have. While people have been praising Firefox, Opera, and other browsers for years, touting how they are more standards-compliant than IE, I continued to use Internet Explorer. I actually liked the browser. While it has its deficiencies, most of those deficiencies are not visible to the end-user: they are just painful issues that developers have to deal with.

As a developer, I have a certain appreciation for the cool, geeky features in Firefox. As an end-user, I like what Internet Explorer has to offer: a simple browser that works on most all web sites, because it's the dominant browser and everybody has to make their sites work with IE. When Internet Explorer 8 came out, I really felt like it was a great step forward. It was more standards-compliant than before and there were a number of good features added. I particularly appreciated the strong support for RSS and Atom feeds: it is significantly better than what Firefox has to offer.

Alas, though, I've decided to dump Internet Explorer. I do not know what Microsoft did with IE8, but the browser seems to freeze a lot. I do not mean that it crashes. Rather, it freezes for a while thinking deep thoughts, I suppose, and then resumes after a while. Sometimes, I would just open a different IE instance and visit a different web site while I waited on IE to wake up. The pages that caused the biggest problems were those that were extremely long or had a significant number of hyperlinks.

So, I dumped Internet Explorer. It is still on my machine, but I have now converted to Firefox. Firefox 3.5 has thus far proven to be extremely stable and has absolutely no problem with the web pages that present Internet Explorer with so many challenges. I do wish Firefox had better integrated RSS/Atom support, but I'll gladly trade that for the stability and robustness I do not get with Internet Explorer.

Sometimes, a good tip is worth sharing. As I was making some edits to some HTML pages using Vim, I wanted to find a quick way to convert uppercase tag and attribute names to lowercase. I found this tip somewhere on the Internet and it worked so well, I thought it might be worth repeating.

To convert HTML tags from uppercase to lowercase, use this command in Vim:

%s/<\/\?\zs\(\w\+\)\ze[ >]/\L\1/g

To convert HTML attributes from uppercase to lowercase, use this command in Vim:

%s/\(<[^>]*\)\@<=\<\(\a*\)\ze=['"]/\L\2/g

Perhaps I am a bit late to the party, but I just learned that Microsoft's XML Paper Specification was standardized by ECMA as a new standard (ECMA-388) on June 16, 2009.

XPS seems to be an important printing technology for Microsoft and has been adopted by quite a number of hardware and software makers. Native XPS support has already been introduced by some printer manufacturers, for example. This makes it great for taking documents directly from the PC to the printer, perhaps something that needed improvement? I don't know. I thought my documents printed perfectly well before.

What makes this so interesting to me is that XPS is a direct competitor to Adobe's PDF format. The next big question is which of these two competing formats will be the winner, or will we have many years ahead where both formats will be common? I write a lot of documents that I need to share with others. PDF has been the standard for a very long time now, but XPS looks very promising. With XPS support built directly into Windows Vista and Windows 7, will it be easier to send around XPS documents rather than PDF documents?

The tools are also important to the success of XPS. Microsoft Office 2007 has excellent support for both PDF and XPS, but other products lack PDF support. With the XPS "printer driver" on Windows, I can easily create XPS documents from any application, and I do. Sometimes, XPS wins only for that reason. But, that is the best thing I can say for XPS, to be frank. I've used the XPS viewer in Internet Explorer and also the stand-alone XPS viewer from Microsoft. Adobe Acrobat Reader really looks and works much nicer than Microsoft's XPS viewers. I hope they consider making some serious improvements. It would be nice to open a document that fits the width of the viewer window. I'd also like to have the XPS viewer remember its position on the screen after I close it. It reminds me a lot of my first "Hello, World!" program on Windows in the way that it opens.

While the browser wars seemed to have picked up again and a lot of technically-oriented people have moved over to Firefox, I've noted that Packetizer still gets a large number of visitors using Microsoft Internet Explorer. And, I'll confess that I also use IE. I really like it, and I appreciate some of the cool new additions in Internet Explorer 8.

That said, there is one feature I absolutely despise: the Compatibility Views feature. If you use Internet Explorer 8, you will note that for many sites you visit, there is an icon at the top of the browser that allows you to select which mode in which to view the site. I found that feature to be terribly confusing and the button was right beside the refresh button, so I often pressed the wrong one.

Not having found a way to get packetizer.com added to Microsoft's compatibility list, I finally decided to figure out how to get rid of that button on IE. I think there is a menu option somewhere to disable it, but I wanted a solution that worked for all visitors to Packetizer. After all, the site should work with Firefox and IE8 and if it does not, people will tell us!

So, I did some searching and found that Microsoft allows control of this feature through an HTTP header. This did the trick for Apache:

BrowserMatch "MSIE 8" IE8_support
Header set X-UA-Compatible "IE=8" env=IE8_support

I hope other site administrators will also turn off this very annoying feature in Internet Explorer 8, once they have verified that their sites work. I hate accidentally pressing that button!

Last week, Google introduced a technology called Google Wave. It is a communication platform that will allow users to communicate, much like they can with email. But, it is significantly different than email in the way discussions take place. A "wave" can be significantly more dynamic than email messages. Plus, the technology allows one to integrate a messaging platform with blogs, Twitter, or just about any other information source on the Internet.

All that sounds interesting, but what really caught my attention was the fact that Google is not just building a platform that it runs in-house and users around the Internet use. Rather, what got me really excited is that Google is building a system that fully federates with domains around the world. Anybody can run a wave server, much like they run an email server today.

The way inter-domain federation is enabled is by building on open standards like XMPP. By using XMPP, they are able to have members of a wave who exist in any number of domains. Those users are then able to communicate in real-time through the wave. And when I say real-time, that is what I mean: as you edit a wave, the other users who are a part of the wave can see your edits as they are made.

This is definitely the first messaging platform that I have seen that truly embraces the capabilities enabled by the web. It might take a few years for this technology to take off, but I do believe it has a real potential to displace email as the primary mode of communication in the future. It's really awesome.

Be sure to check out the video Google made where they unveiled Google Wave for the first time. It was given at the developer's conference, but you do not need to be a software engineer to see the power and flexibility of this new messaging paradigm.

Amazon's Elastic Compute Cloud (EC2) is an amazing cloud service that offers a lot of flexibility. One might use the service to perform complex or time-consuming calculations, employing any number of servers in parallel. It can be used by web-based companies to store tons of information, with virtually unlimited storage capacity. Or it might simply be used to provide web hosting or email services to businesses and individuals.

Packetizer.com has been around since 2000 and we have had a few hosting companies. Initially, we hosted our web site and email on a simple web hosting account. As time progressed, the site grew and we found ourselves in need of a dedicated or virtual server. We tried the use of a virtual server and found the performance less than satisfactory and so we ultimately leased two dedicated servers: one to serve up web pages and one to provide email services.

One of frustration points with a dedicated server is that one's web site and email services are at the mercy of the hardware upon which your services are running. And, that became painfully clear when one of our servers started crashing unexpectedly. In need of a quick solution, we moved packetizer.com to the Amazon EC2 service. For those who are not familiar with the service, it is very comparable to virtual dedicated servers offered by other hosting companies. However, unlike other hosting companies, Amazon also offers virtually unlimited storage space on the "pay for what you use" model.

Another thing that is really cool about the cloud computing model is that if you setup your server and do not like the way you have it configured, you can just terminate the "instance" (a virtual server) and start a new one. Changing operating systems or configuration is very quick and easy. With a dedicated server, one has to re-install the operating system and that takes time. What might be an all-day upgrade effort with a dedicated server becomes a 10-minute task with Amazon EC2. In fact, one can prepare a new instance and get everything just the way it needs to be before terminating the old instance.

Having been successful with moving packetizer.com to the Amazon EC2 infrastructure, we then decided to move our mail server over. In the past, people had been reluctant to use EC2 to provide critical email services for two reasons: 1) there was apparently no way to assign a static IP address to a mail server, and 2) when an instance was terminated, any data stored on the instance was lost. However, neither of those two issues exist with enhancements Amazon has made to EC2.

One can now allocate an IP address for such services as email servers. Once allocated, that IP address is, in effect, statically assigned. As long as one wishes to continue using Amazon's EC2 service, the IP address is reserved and does not change. One merely maps the IP address to the instance that provides email or web services. If one starts a new instance (such as when moving from one operating system to another), one can re-assign the given IP address to the new instance. So, to the outside world, the IP address remains static.

Another significant introduction is Elastic Block Storage (EBS). EBS is a means of allocating storage space, with storage volume sizes presently ranging from 1GB to 1TB. To a Linux machine, this storage space presents itself just like any other block I/O device. When mapped onto a Linux machine, it appears as a device with a name like /dev/sdh. One can then format the storage space with a preferred file system (e.g., ext3) and mount the file system as if it was a local hard drive.

By utilizing EBS and statically assigned IP addresses, we had everything we needed to move Packetizer's mail server to Amazon EC2. We run Linux and use sendmail for message delivery. So, to prevent loss of data in the event that the mail server instance gets terminated (e.g., such as when there is a hardware failure), we allocated block storage for /var/spool/mail and /var/spool/mqueue. We could easily terminate the currently running instance, start a new one, put configuration files in place (which is entirely scripted), and then re-mount the EBS-based file systems. It is really cool and definitely a big step forward in terms of management.

But, not everything is perfect. What we discovered was that there were some organizations that considered Amazon's EC2 service as a source of spam and our IP address was blacklisted. Most of the organizations were reasonable and unblocked our assigned mail server address. Unfortunately, we were unsuccessful at convincing some organizations to unblock our address. They would argue that Amazon's cloud service uses dynamically assigned IP addresses and I could only counter the argument with the fact that we have a statically assigned address. Unfortunately, they would not listen to reason.

Fortunately, we have not really encountered significant problems with messages being blocked by those organizations. It has happened a few times, but I can report that the Amazon EC2 service has been a great platform for operating Packetizer's mail services, including our public mailing lists.
If you have not experienced Amazon EC2, I would invite you to check it out. It truly changes the way Internet applications and services will be deployed in the future.