Messaging

This category contains messaging-related posts.

VMware, Zimbra, and Why I’m Not an Analyst

Tuesday, January 5, 2010 in Collaboration, Messaging, Virtualization by slowe | 9 comments

The rumors are swirling that VMware is going to buy Zimbra, an open source e-mail platform currently owned by Yahoo. You’ve probably all read the various news articles about the rumors and the events leading up to the rumored acquisition, so I won’t bother you with them again.

Yesterday on Twitter, I mentioned that the Zimbra acquisition didn’t quite make sense to me. I wasn’t the only one; several others mentioned it, too. That sparked a great discussion with Chris Wolf of the Burton Group (really sharp guy, by the way). His comments caused me to look at the purported acquisition in a different light where it starts to make a bit more sense. The discussion reminded me why I’m not an analyst: sometimes I don’t take a broad enough view. (It’s something I’ll work on improving.)

Most people look at the Zimbra acquisition (assuming that the rumor is accurate and it really does happen) and immediately recognize the intent to compete against Microsoft Exchange. However, if you look at the Zimbra acquisition strictly from the perspective of competing against Microsoft Exchange in the market as it currently exists, you’ll quickly come to the same conclusion that I did: it doesn’t make sense. Get real: lots of companies have tried before and failed. I believe that If VMware were to use Zimbra to compete against Exchange in the traditional corporate messaging market, where Exchange mopped up very worthy competitors like Lotus Notes, VMware would end up a failure like so many others before them. As Chris Wolf pointed out on Twitter, the integration between Exchange and the Microsoft applications is just too great to take them head-on.

However, what if you consider that the market is shifting? There is a greater move toward private clouds running scalable, web-based applications. There is an inclination toward workloads that can run outside of an organization’s data center. There is a shift toward virtual desktops. There is desire and interest in embracing the idea of cloud computing—however you choose to define that—across organizations of many different shapes and sizes. In the light of these market factors, now the Zimbra acquisition starts to make more sense. Yes, VMware will compete against Microsoft with Zimbra, but not using today’s architectures and today’s paradigms. As Chris put it in a Twitter post yesterday (emphasis mine):

@TonyWilburn @scott_lowe – IMO vmware has to redefine the traditional app stack for long term survival; email has to be part of it

In the light of this line of thinking, the acquisition begins to make a bit more sense (again, assuming that it’s actually going to happen). Although VMware has different leadership, and it’s a different market, I do feel that VMware would not be successful taking on Microsoft Exchange without redefining how e-mail platforms—as a key part of the overall application stack—can be provisioned, deployed, and managed in conjunction with VMware’s broader private cloud/public cloud strategy.

So what do you think?

Tags: , , , , ,

Growl Notifications with Snow Leopard Mail and Exchange

Thursday, December 10, 2009 in Macintosh, Messaging by slowe | 2 comments

Like many Mac users, I use Growl to provide customizable, centralized notifications for events occurring on my system. Rather than use the Growl team’s GrowlMail plug-in, I use a custom AppleScript that I wrote that provide new message notifications via Growl. It’s not a terribly advanced script; it just provides per-message notifications for each message received, unless I receive more than 5 messages at a time in which case the script just provides a summary notification. It’s worked very well for me for quite some time.

Now, following my upgrade to a new MacBook Pro running Snow Leopard, I’m finding that the script has an interesting flaw: when new messages are received via my Exchange account at work, the script notifies me using information from the previous message received on that account rather than the information from the newly-received message. I know that it’s not the script because notifications for all other accounts work just fine. Only the Exchange account—which uses Snow Leopard’s new Exchange support for connectivity—is affected.

Has anyone else seen this? If so, does anyone have a fix?

UPDATE: I wasn’t able to make Growl notifications invoked from an AppleScript work properly with my Exchange account, so I tried switching to GrowlMail. Unfortunately, GrowlMail has problems with Snow Leopard 10.6.2 that can only be fixed using the Terminal commands in this article. After getting GrowlMail recognized by Mail.app, notifications started appearing correctly for all accounts including my Exchange account.

Tags: , ,

I Tried to Like Postbox, I Really Did

Wednesday, April 1, 2009 in Macintosh, Messaging by slowe | 7 comments

If you haven’t yet heard about Postbox, it’s a new Mac OS X e-mail application built on Mozilla technology that intends to offer a new and different way of working with e-mail. From the Postbox web site, you can look at some of the features the application offers as well as see some screenshots.

I’ve been testing Postbox off and on since I was first invited into the beta, and at first I was really excited about Postbox. You see, I have my complaints about Mail.app, but there really aren’t any good alternatives. Given that Postbox is based on Mozilla Thunderbird and I’d heard good things about Thunderbird, I was excited that someone was releasing a more “Mac-native” version. I didn’t want just a Mac port of an existing application, but rather a Mac-integrated build. That’s why, for example, I use Camino instead of the Mac version of Firefox.

Although Postbox is a really nice application with features that some users will love, for me it just wasn’t (and isn’t) the right fit. Here are my reasons why. Keep in mind as you read this that YMMV (your mileage may vary).

  • I switch back and forth a lot between my home network, which has an HTTP proxy, and other networks that do not have an HTTP proxy. Currently I use Quicksilver to switch between two network locations that are identical except for the proxy settings. Postbox doesn’t honor the systemwide proxy settings, so switching back and forth between networks now requires another step. (This is one of those things that makes Postbox feel like a Mac port, not a Mac-native build.)
  • Postbox doesn’t integrate with the Mac OS X Keychain.
  • It appears that Postbox’s search functionality isn’t tied to Spotlight. Why not leverage Spotlight?
  • Postbox offers integration with the Mac OS X Address Book but also maintains its own address book. Why?
  • I don’t need Facebook, FriendFeed, or even Twitter integration in my e-mail client. I have other applications for those services.
  • I don’t like tabbed interfaces. Postbox does offer the ability to open messages in a new window instead of a new tab (thankfully!), but you can’t turn the tabs off. I suppose this would be difficult given the UI layout and how it’s used for the search features.
  • Speaking of search features, I don’t really need web search integration in my e-mail message windows. I also don’t need image searching features. I’m sure that home users that are sharing pictures with family members and friends would find that feature helpful, but not me.
  • I’d like to be able to turn off features that I don’t want to see, like the preview pane (a long time complaint of mine with Mail.app as well!), the Compose Sidebar, and the web search pane. But you can’t, at least not as far as I can tell.
  • I’d love to see AppleScript support. That would include the ability to launch an AppleScript from a message filter.

All of this is not to say that Postbox is a bad application; quite the opposite, in fact. It’s just not the right application for me. Other users with other needs will likely find it to be a great fit for them. For me, I need an e-mail application that is focused on doing just one thing and doing it really, really well: managing e-mail. So far, I’m still searching.

Anyone else out there using Postbox? I’d love to hear someone who’s using it and loving it (and who’s not a Postbox employee!). Feel free to speak up in the comments.

Tags: ,

Configuring Mail.app and iPhone with Google IMAP

Tuesday, January 20, 2009 in Macintosh, Messaging by slowe | 13 comments

So I recently moved almost all of my personal e-mail domains over to Google Apps. A couple of people have asked, “Why?” My answer is simple: it’s easier. The e-mail functionality of my current hosting provider is lacking in a couple of key areas:

  • Rather than using the emerging standard of having e-mail clients connect to TCP port 587 (Submission) to send e-mail, they used a very non-standard practice of using TCP port 26. (Now if we could just get older versions of Outlook to not have a severely broken SMTP client implementation, we’d be in good shape. But that’s another story…)
  • Despite paying for a dedicated IP address, I can’t use my own SSL certificates for e-mail (only web traffic). The SSL certificates the hosting provider supplies for e-mail are self-signed certificates and cause fits to clients such as Outlook and Mac’s Mail.app.

By using Gmail and/or Google Apps, on the other hand, these issues go away. However, Google’s particular implementation of IMAP—and its use of labels vs. folders—presents a few challenges of its own. During the process of migrating over to Google Apps and using IMAP for all my e-mail accounts, I have finally settled into a configuration that works well for managing e-mail from my MacBook Pro as well as my iPhone.

The secret lies in a Google Labs feature called “Advanced IMAP Controls.” By enabling Advanced IMAP Controls, Google Apps and Gmail users can control which labels will appear in Mail.app (and other IMAP clients, like the iPhone). Here’s the configuration I’ve been using that seems to work really well:

  1. In the Mail section of Google Apps or Gmail, go to Settings, then Labs, and enable “Advanced IMAP Controls”. Google Apps users may need their administrator (if they don’t have administrative permissions) to allow Labs features to appear. I’m not sure about Gmail users; I think Labs features are available by default for Gmail users.
  2. Once Advanced IMAP Controls are enabled, go to the “Labels” section of Settings and uncheck all labels except Drafts, Spam, and Trash.
  3. When setting up Mail.app, configure the IMAP account as normal, but set the Inbox Path Prefix to “[Gmail]“. When you take the account online, a heading for that account should appear in the Mail.app sidebar with three folders under it: Drafts, Trash, and Spam.
  4. Select the Drafts folder/label under the account’s heading, then go to Mailbox > Use This Mailbox For > Drafts. This should cause the Drafts folder under the account’s heading to disappear. Instead, it will be listed under the unified Drafts folder under the Mailboxes heading.
  5. Repeat the process for the Trash folder/label (use for Trash) and Spam folder/label (use for Junk). After performing this process on all three folders/labels, the account heading should disappear from Mail.app’s sidebar.
  6. In the Mailbox Behaviors section of the account settings (Under Mail > Preferences) check the box for “Store draft messages on the server.”
  7. In the same area, also check “Store junk messages on the server” and specify a time period for how long to keep junk messages.
  8. Finally, check the box for “Move deleted messages to the Trash mailbox” and “Store deleted messages on the server” and specify how long to keep deleted messages.

To keep mail synchronized between the IMAP server, Mail.app on my laptop, and Mail on my iPhone, I replicated these settings on my iPhone, selecting the Drafts folder/label as the “Drafts Mailbox” and the Trash folder/label as the “Deleted Mailbox” in the Advanced area of Mail settings.

With this configuration, reading a message on my laptop will mark it as read on my iPhone, and deleting a message on my iPhone will make it appear in the Trash mailbox on my laptop. In addition, I can continue to leverage Gmail/Google App’s web interface when necessary as well, and see draft messages and deleted messages in the appropriate areas there, too. All in all, it works very well for me.

If you have other tips for enhancing the use of Gmail/Google Apps with Mail.app and your iPhone, I’d love to hear them in the comments below. Thanks!

Tags: , ,

Google Apps Doesn’t Play Nice with MailTags

Friday, December 12, 2008 in Macintosh, Messaging by slowe | 3 comments

One of my most used and most useful applications (add-ons?) is MailTags, by Scott Morrison. It’s an add-on to Mail.app that allows for tagging e-mail messages with keywords, projects, notes, etc., and then saving that information in IMAP headers—if you are so inclined—so that it persists from one IMAP client to another. It’s a fantastic add-on. I highly recommend it.

Unfortunately, I just discovered a strange interaction between MailTags and Google Apps. I recently moved one of my older e-mail domains over to Google Apps and discovered that every time I try to save MailTags data to IMAP, the message(s) disappear from my Inbox. The only way to recover the messages is to login via the web and recover them. The only workaround is to not save MailTags data back to the IMAP server. This is not an issue with MailTags, by the way; this is a strange interaction that results from the odd way in which Google provides IMAP access to mail data.

Had I bothered to do a bit of research before migrating this domain over to Google Apps, I would have found that this was a known issue and is well-documented on the MailTags forums (see here and here, for example). There does not appear to be a timeframe for a workaround, so for the time being I’ll just have to refrain from trying to save MailTags data to IMAP for this particular e-mail account.

Since this is an older domain that isn’t mission-critical, this isn’t a huge worry. Further, since I only use a single IMAP client and typically don’t save a lot of data on the IMAP server, the impact is lessened even more. However, I had been considering moving e-mail for scottlowe.org over to Google Apps as well, and along with that migration I had considered moving more of my e-mail into Google Apps and just use IMAP to keep my client in sync with the server. This would, for example, provide me with greater access to my archived e-mail via my iPhone. With the discovery of this odd behavior, now, I’ll have to reconsider that plan. Anyone have any suggestions?

Tags: , ,

Plain Text Messages with Mail.app

Saturday, August 16, 2008 in Macintosh, Messaging, Microsoft by slowe | 7 comments

I’m not really sure where or when it started, but over the last couple of years I started taking a strong preference to plain text communications. Perhaps it’s an increased amount of time spent on Usenet newsgroups (I’m still waiting for Panic to release a substantive update to Unison!), or perhaps its due to the annoyance of HTML e-mail that include more pictures than text; I don’t know. In any case, I set my e-mail client (Mac OS X’s Mail.app) to use plain text by default when composing messages, and I used the “hidden” preference to show the plain text alternative for messages when it’s available:

defaults write com.apple.mail PreferPlainText -bool TRUE

So that’s all well and good, but what I’ve noticed is that Mail.app seems to “ignore” some of the line endings in my message. It primarily only happens in signatures; I haven’t noticed it happening in the body of the message. At the same time that I adopted plain text messages, I also adopted the “standard” signature delimiter of two dashes and a space, so my signature will typically look something like this:

-- (hidden space at the end here)
Scott

What happens is that Mail.app turns it into this:

-- Scott

What in the world? Why is Mail.app playing with my signature? I’ve also noticed that in my longer signature—where I include my official title, phone numbers, company name, etc.—that Mail.app plays with the line endings there as well.

It also seems that this may be somehow related to Exchange Server 2007, as it only seems to happen to messages sent through my corporate Exchange infrastructure (I use IMAP and SMTP for connectivity to Exchange). I can’t find a single instance of an e-mail message where this has happened with any of my other non-Exchange e-mail accounts. But this doesn’t really make much sense, because the message I’m seeing is the local copy after it is submitted via SMTP. Perhaps the way in which Mail.app interacts with the SMTP server affects how the message in the Sent mailbox looks? I don’t know.

This is really irritating. If I type something, Mail.app (or Exchange Server) should NOT be going back and changing what I type. Anyone have any clue what could be going on here, or how I might fix it?

Tags: , , ,

E-Mail Subscriptions Now Available

Wednesday, March 5, 2008 in General, Messaging by slowe | 3 comments

RSS is handy, but not everyone likes RSS. Some people prefer to receive updates about this site via e-mail, and to help accommodate that I’ve enabled e-mail subscriptions to the site. To subscribe to receive updates about this weblog via e-mail, just follow these simple instructions:

  1. From your web browser, open the feed URL for the site. I’ve hyperlinked it for your convenience.
  2. An HTML interpretation of the RSS feed will be displayed. In the upper right hand corner, there will be a box titled “Subscribe Now!” In that box, there’s a hyperlink labeled “Get blog.scottlowe.org delivered by email”. Click that link.
  3. The next screen will prompt you to enter your e-mail address and enter a verification code that is displayed on the screen. Provide that information and then click the button labeled “Complete Subscription Request.”
  4. Soon thereafter, you’ll receive an e-mail in your Inbox. In that e-mail will be a link—which you should NOT click on, but should instead copy and paste into your browser—to complete and verify the subscription.

That’s it, you’re all set! Please note that the “Reply-To” address on the e-mails you receive from the site is not valid, so don’t be surprised if you reply to a message and get a non-delivery report back. If you need to contact me via e-mail, my information is available here on the site.

Thanks to everyone for reading, and I hope that this new service will be helpful to some of you!

Tags: ,

Suggestions for Processing Mail

Monday, February 13, 2006 in Messaging by slowe

I need some help with a solution for processing mail messages.  Specifically, I’m looking for an open source solution that will allow me to create filters (or rules, or policies, or whatever term you’d like to insert here) that will perform actions on inbound mail messages.  Does anyone out there have any suggestions?

In case you’re wondering why, I need something that can alert me (via e-mail, of course) when an e-mail message with specific words in the subject or body are delivered to a generic mailbox created on the mail server.  See, I have multiple customers whose systems and applications send non-urgent reports and notifications to a generic mailbox.  When one of those messages contains text that might indicate a failure or a problem, I want to be notified via e-mail on my primary e-mail account.  This way, I don’t have to check this generic mailbox every day, but instead I can be notified when a failure/error notification arrives.

This solution should integrate with both Postfix and Dovecot, as I use currently use both of these.  I’ve looked at procmail and maildrop, and these both seem good, but which is better?  Which is faster, more efficient, more flexible?  This is where I could use some feedback from those of you out there that have used these programs before, and can provide real-world input.  By the way, I’m using Maildirs instead of standard mailbox files, so I’ll need something that can work with Maildirs.

So, anyone have any suggestions for me?  Or, at the very least, some links to clear, concise instructions for either procmail or maildrop?  Feel free to bookmark them via del.icio.us and tag them as “for:slowe”, if you are so inclined.  Thanks!

Tags: , ,

Open Source Blackberry Workaround?

Monday, February 13, 2006 in Messaging by slowe | 2 comments

Funambol, formerly Sync4j, is claiming that its latest product, Funambol 3, could function as an open-source Blackberry workaround, allowing push e-mail to be delivered to a variety of mobile devices, including Blackberries.  This is particularly important in light of the threat of a Blackberry shutdown due to the RIM-NTP patent dispute.

Currently in beta, the v3 server software runs on Linux or Windows, and clients are available for Outlook, Windows Mobile, Blackberry, Palm, and (believe it or not) iPod.

More information can be found in this article.

Some people are also suggesting the use of open standards to ease the impact of a potential Blackberry shutdown as well.  While not as functionally rich as a typical Blackberry implementation, the use of POP3/IMAP4 and SMTP to handle mobile messaging needs is certainly very viable.  This is easily implemented via most commercial messaging systems and through a number of open source packages as well.  For example, I use Dovecot and Postfix to provide IMAP4/SMTP support for my Treo, all secured by SSL/TLS encryption.  Like the Funambol approach, this also offers a great deal of client-side variety as well, instead of locking users into a single client device.

Tags: , , , ,

Protecting OWA with Apache

Saturday, December 3, 2005 in Interoperability, Messaging by slowe | 6 comments

Outlook Web Access (OWA) is the web-based interface for accessing e-mail and other resources handled by Microsoft Exchange.  Unfortunately, OWA’s popularity also makes it the target of numerous worms and security exploits.  As a result, many organizations seek to deploy OWA behind a reverse proxy that can help shield OWA from web-based attacks and exploits.  In this posting, I’m going to share information to help build a reverse proxy using Apache 2.0.

Here’s a skeleton of an httpd.conf file to support Apache as a reverse proxy in front of OWA:

NameVirtualHost 1.2.3.4:80
NameVirtualHost 1.2.3.4:443
ProxyRequests Off

<VirtualHost 1.2.3.4:443>
ServerAdmin webmaster@domain.com
ServerName webmail.domain.com
DocumentRoot /var/www/webmail
RequestHeader set Front-End-Https “On”
ProxyRequests Off
ProxyPreserveHost On

SSLEngine On
SSLCertificateFile conf/webmail-ssl-cert.pem

<Location /exchange>
ProxyPass http://mail.domain.com/exchange
ProxyPassReverse http://mail.domain.com/exchange
SSLRequireSSL
</Location>

<Location /exchweb>
ProxyPass http://mail.domain.com/exchweb
ProxyPassReverse http://mail.domain.com/exchweb
SSLRequireSSL
</Location>

<Location /public>
ProxyPass http://mail.domain.com/public
ProxyPassReverse http://mail.domain.com/public
SSLRequireSSL
</Location>

</VirtualHost>

The key portions of this configuration are described below, along with some supporting information.

  • NameVirtualHost:  The NameVirtualHost directive enables Apache to use name-based virtual hosts on the specified IP addresses and ports.  The parameter to the NameVirtualHost directive must match one of the VirtualHost definitions, as shown in the sample configuration, or else the content will be served from the default virtual host (the first virtual host listed in the configuration).  Note that if the Apache reverse proxy will not be using name-based virtual hosts (instead using IP address-based virtual hosts or running only a single server instance), then this directive is not required.
  • RequestHeader:  This directive instructs Apache to add a header “Front-End-Https: On” to requests sent to the internal OWA server.  This header is proprietary to OWA and forces OWA to build URLs using “https://” references instead of ordinary “http://” references.  This directive is required in order to terminate the SSL tunnel at the reverse proxy and use clear-text HTTP between the reverse proxy and the internal OWA server.  This directive requires the mod_headers module.
  • ProxyPreserveHost:  This directive configures Apache to pass the original host header, supplied by the client, to the server to which the request is being proxied.  (This is instead of the host name supplied in the ProxyPass directive.)  Again, this facilitates the construction of URLs with the correct hostname when accessing resources inside OWA.
  • SSLCertificateFile:  Apache expects the web server’s SSL certificate to be in PEM format.  If the certificate’s key is encrypted, Apache will prompt upon startup for the passphrase to the key (this prevents any form of automated startup).  It is considered a security best practice to keep the key in a separate file (using the SSLCertificateKeyFile directive) in encrypted form and supply the password upon the startup of Apache.

With this configuration in place, the following benefits are realized:

  1. Name-based virtual hosts are supported. This allows other URLs to also be proxied through this same reverse proxy server.
  2. SSL encryption is offloaded from the Exchange server to the reverse proxy server. Traffic from the reverse proxy server itself to the Exchange server is standard, unencrypted HTTP.
  3. When used in conjunction with mod_security (another Apache module), OWA is protected against a very significant majority of all web-based attacks.

Using Apache to serve as a reverse proxy for OWA is a cost-effective way to add another layer of security to an Exchange-based messaging infrastructure.

Tags: , , ,

« Older entries