Messaging

This category contains messaging-related posts.

Current Tech Projects

Sunday, November 6, 2005 in Collaboration, Messaging, UNIX by slowe

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.

Tags: , , , , ,

Badmail and Exchange 2003

Saturday, July 16, 2005 in Messaging by slowe

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.

Tags: , ,

STARTTLS and IMAP in Mail.app

Saturday, July 2, 2005 in Messaging by slowe

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.

Tags: , , , , ,

Split E-Mail Routing

Thursday, May 19, 2005 in Messaging by slowe

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.

Tags: ,

Perdition Working Now

Sunday, May 15, 2005 in Messaging by slowe

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.

Tags: , , , , , , ,

Nonstandard Implementations

Saturday, May 14, 2005 in Interoperability, Messaging by slowe

In my experiments with Perdition, I learned a couple of very interesting facts. First, the IMAP4 implementation on Exchange Server 2003 does not support the STARTTLS command, as described in RFC 2595 and re-affirmed in RFC 3501. Instead, Exchange expects an SSL session to be established immediately, and then IMAP is spoken. This is similar to the “smtpd_tls_wrappermode” directive that Postfix supports.

Second, it appears that the Mac OS X Mail application (commonly referred to as Mail.app) also uses this IMAP-over-SSL approach, since I’ve been using Mail.app to connect to Exchange using IMAP with SSL for quite some time. I’m trying to confirm that now, but having precious little luck finding any definitive information one way or the other. If anyone knows for certain, please let me know. I’m going to keep searching.

This is one of those things that just makes me crazy.

Tags: , , , , , , ,

Newer entries »