Messaging

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?

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!

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!

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.

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.

Every now and then, I like to post out here a list of my current “tech projects.”  These are the things that I’m working on for my own network, things that I may or may not start recommending to or supporting for customers.

Here’s my current list:

• InterNetNews (INN):  I had an installation of INN up and running a short while back, but had to resort to an ugly hack with stunnel in order to make SSL work from a newsreader.  To get a clean build, I’ve decided I’ll just start from scratch with a clean installation.  I’ll be using CentOS 4.1 again as I work on transitioning all my Linux-based servers to a newer Linux distribution, and I’ll be compiling INN from source instead of using a package.
• OpenBSD-based antispam gateway:  I’ve got an antispam gateway running right now (uses Red Hat Linux, Postfix 2.1, SpamAssassin, Postgrey, Razor, DCC, and ClamAV), but I want to try building one using OpenBSD 3.8 (just recently released) and newer builds of Postfix, SpamAssassin, and Amavisd-New.  In particular, I’m interested in the advanced integration of newer versions of Postfix and Amavisd-New.
• XC Connect:  I’ve also mentioned XC Connect before as well, but a previous installation proved to be unstable, and the Apache integration was less than stellar.  In fact, the integration was nonexistent.  I’m going to try a clean build of CentOS 4.1 and XC Connect to see if that will correct the stability and integration problems.

I also need to wrap up the documentation for a few completed items, such as the Cisco VPN integration with Active Directory.  Mac OS X integration with Active Directory is also on the “to do” list, but it will have to wait a little while—I’ll need to find another Mac to “experiment” with instead of using my own PowerBook.

If you are planning an in-place upgrade of your server running Exchange 2000 to Exchange Server 2003, beware of the Badmail folder.  Apparently, during the Exchange Server 2003 setup process, the setup application tries to go back and stamp ACLs (access control lists) on all the objects in the installation directory.  This, by default, includes the Badmail directory.  If your Badmail directory contains lots of items (which, in an Exchange 2000 installation, it probably does), then this can cause the Setup process to appear to be hung.  Microsoft has published this KB article discussing the issue and the resolution.

Fortunately, in Exchange Server 2003 SP1, Microsoft has changed the behavior of Exchange to use the Badmail folder only if explicitly configured to do so (see this KB article).  No more monitoring the Badmail folder!

In addition, for those networks that have not yet deployed Exchange Server 2003 SP1, Microsoft has released the BadMailAdmin tool.  I’ve tested this, and it works as advertised.

I blogged earlier about my frustration with the Mac OS X Mail.app mail client and its apparent lack of STARTTLS support with IMAP4.  Well, on a whim today I decided to take this issue back up again.

Since Microsoft Exchange does not support STARTTLS, I had to use Perdition as an IMAP proxy in front of Exchange.  Earlier attempts to get Mail.app to do STARTTLS had failed (not sure why), but today I decided to try changing the IMAP port from 993 (the default when you check the “Use SSL” box) to 143 (the standard IMAP4 port).  Oddly enough, it seemed to work!

Curious to find out for sure, I trotted out tcpdump on the mail gateway running Perdition to capture traffic to/from Mail.app and to/from the back end mail server.  The traffic to/from the back end mail server was transmitted in the clear (I used plain text messages so that I could see the content), but the traffic to/from Mail.app was not readable.  I also saw Mail.app issue a CAPABILITY command, then issue a STARTTLS command.  Bingo!

So, it appears that Mail.app does indeed support STARTTLS for IMAP, but only if you set the port number back to 143 after checking the “Use SSL” checkbox.

Now that I have Perdition up and running (although not in the way I really wanted; see my post titled “Perdition Working Now”), I’m moving on to setting up an internal news server.

Before I can get the internal news server up and running, though, I must first address the issue of e-mail submissions to these newsgroups.  See, right now I can send an e-mail to newsgroupname@domain.com (this is obviously an invalid address) and that message will be posted to the newsgroup.  This works well because the mailboxes and the newsgroups live on the same server and the mail gateway can route all messages to this server.

If I setup a separate news server, however, I’ll need some e-mail addresses to be directed to the mail server, but other e-mail addresses (the e-mail addresses for the newsgroups) to a different server altogether.  I think that Postfix can do this, but I don’t know that for certain yet.  I suspect that the answer lies somewhere in the mystery of virtual_alias_maps, but I just can’t wrap my head around it right now.  Of course, it is getting late here so that may explain it.

I finally managed to get Perdition working.  Still unable to confirm if Mac OS X’s Mail.app supports STARTTLS (my experience thus far says No), I had to resort to using Stunnel to wrap IMAP inside an SSL tunnel, then forward the IMAP traffic to Perdition on the same host.  The Perdition proxy then passes the traffic to the back-end mail server.  It’s not the solution that I really wanted, but it will do for now.  At least the Exchange Server 2003 IMAP server isn’t exposed directly to external networks.

On a slightly related note, the Slipstick Systems web site has a link to an IMAP proxy server that implements STARTTLS as a workaround for Exchange’s lack of native support for STARTTLS.  The IMAP proxy can be found at http://www.slipstick.com/files/imapproxysvc.zip.  So, if you have an IMAP4 client that supports STARTTLS and want to connect it to Exchange, you can use this IMAP proxy.  At least, until Microsoft puts STARTTLS support into Exchange directly.