Email

Mark Crispin, father of the Internet Message Access Protocol (IMAP) died on December 28, 2012. Due to the contribution Crispin made to email interoperability and access, his passing deserves the acknowledgement of the global email community. Although it’s now regarded to be an outdated protocol because it does not support the advanced features of modern email systems, IMAP still has a dedicated band of followers and is used by tens of millions of people daily to fetch email from Gmail, Exchange, Zimbra, and just about every other email server on the face of the planet. The major value of IMAP is its sheer ubiquity, with the golden rule being that if a client can’t access a server using another method, it probably can using IMAP. The world of email was very different when the first versions of IMAP were written at Stanford University in the mid-1980s. The vast majority of mailboxes were served by proprietary systems such as Digital’s ALL-IN-1 or IBM PROFS and the Internet was a loose collection of servers connected with dial-up telephone links. The Post Office Protocol (POP) existed then as it still lingers on today, but only allowed users to download messages from a server. This sufficed in many situations then – servers and clients alike were resource poor and it was deemed to be a good thing to remove items from server mailboxes to bring them down to clients for processing. Crispin conceived IMAP as a mail access protocol that advanced the state of the art by allowing access to more than an Inbox folder on the server, supported concurrent access to mailboxes, and offered much more functionality to manipulate messages than the POP protocol allowed. Originally developed in Lisp, a language much favoured by people working on Artificial Intelligence at the time, on a Digital TOPS-20 computer, the value of IMAP was realized in its fast evolution and adoption to the point where IMAP4 appeared in 1994. IMAP4 has been extended many times with additions by vendors (...More

Email services have long been one of the first places companies have looked for outsourcing to the cloud. It makes a lot of sense: Few companies are in the business of providing email (with the exception of service providers), although email is essential to almost every business. Therefore, why not let someone else manage this function and free up your IT resources to focus on projects more central to your company's mission?However, with as easy a decision as moving email to a hosted service might seem, you could run into significant problems if you don't plan carefully before any migration. If you're using Microsoft Exchange Server, or another groupware provider, do you know all the third-party products or add-ins that tie in with that system? For instance, you might have a group in the company that uses a program to email automated reports weekly or monthly to key members of staff; if email domains change, someone's important information might not appear in their Inbox as expected. And what about machines such as printers that can email scanned documents to your users -- how will they work after you transition?...More

Because we’re all skilled computer professionals who have carefully considered a suitable computer naming convention before deploying any server into production, I can’t think of good reasons why anyone would ever want to rename an Exchange server. On the other hand, I can think of some pretty bad reasons for wanting to rename a server such as wishing to update all names following a corporate merger or as part of a rebranding exercise launched by the marketing department. Of course, this kind of exercise cheerfully ignores the basic logic that few users care what their server is called and fewer probably know how to find out. Administrators do care because of the naming convention that is in use to identify servers and the role that they play within an organization. Some questions have recently been asked on the topic so I thought it worth discussing here. If backed into a corner by the unreasonable demand to rename a server, the first ploy that should be adopted is the standard response “it’s unsupported by Microsoft”. In this case it’s actually true and Microsoft support is most unlikely to be happy with you if you call in to report that things went horribly wrong when you attempted to rename a server. However, aside for the directive that you must not change the server name after installing an Edge server that’s buried in a TechNet article, there is little authoritative commentary on the topic, so here’s why you shouldn’t even consider a renaming exercise. The first thing to realize is that Active Directory is liberally populated with references to an Exchange server name. Both the distinguished name (DN) and the visible server name can be found. The basic location to start looking is in the Servers container in the famous Exchange Administrative Group (FYDIBOHF23SPDLT) container (much beloved of those interested in playing Exchange trivial pursuit). You’ll need to navigate to Services, then Microsoft Exchange, and then the name of your organization within the...More

A certain amount of joy erupted across the Exchange community after last Friday’s announcement on the EHLO blog that Microsoft had decided to remove multi-mailbox searches from the set of Exchange 2010 features that are licensed through an Enterprise Client Access License (ECAL). The announcement says: “Multi-Mailbox Search required an Enterprise Client Access License (CAL) for each mailbox searched. We’ve heard your feedback on how you use this feature and the licensing requirements. Today we’re making a change to Exchange 2010 licensing so you’ll no longer require an Enterprise CAL for Multi-Mailbox Search.” I always thought that it was a bit silly to require an ECAL for mailboxes that were liable to be searched. After all, the whole purpose of having multi-mailbox searches is to be able to find information that’s needed to satisfy a legal discovery action or to satisfy some other appropriate reason for administrators to delve deep into the innards of user mailboxes. It does make sense to require an ECAL for those who perform multi-mailbox searches as these folk are by definition using the feature. Penalizing “normal” mailboxes simply because their contents are being searched doesn’t seem quite so sensible. Put another way, it’s pretty insane. The problem with any multi-mailbox search is that you don’t necessarily know what mailboxes need to be searched before you start, nor do you know what mailboxes will actually contain anything of interest to the search,...More