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!

This is a really, really, really simple task, but to save me the time of looking it up on those rare occasions when I need to do it I’m capturing the information here.  This is how to create, delete, or modify users for a Postfix-based mail relay using SASL.

All of these examples assume that SASL is configured to use “sasldb” as the authentication mechanism.

To create a new user, use the following syntax:

saslpasswd2 -c -u <domain> <username>

For simplicity’s sake, it’s easiest to make both the domain and the username in the command above the same as the domain and the username in the user’s e-mail address.  This will make their full username the same as their e-mail address.

To change an existing user’s password:

saslpasswd2 -u <domain> <username>

This will prompt for password and password verification.  To delete an existing user:

saslpasswd2 -d -u <domain> <username>

Finally, to list the available users on the system, simply use:

sasldblistusers2

This will list all the SASL users defined in the SASL database.  Please note that the users’ passwords will show up only as “userPassword”, so it’s not possible to see their existing passwords (at least, not without some effort).

There—now, the next time I need to do this, I’ll be able to easily remember the instructions.

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.

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.

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.