Can I split my mail spool from my IMAP server?

September 21, 2005 1:16 PM

I want my small office's half dozen desktop computers to retrieve incoming e-mail from an external mail server, but store all IMAP folders on an internal mail server. Is this possible?

Currently, our mail server is hosted in-house, which is fine, unless our internet connection goes down, in which case mail bounces. We'd like to pay a host to queue our incoming e-mail. We'd pay them for IMAP storage, too, but our e-mail largely consists of multi-MB PDFs, we'd need many GBs of storage, which is just too expensive to justify.

Do any of the major Windows e-mail clients support splitting the mail spool from the IMAP storage? Or would it be better to use fetchmail to suck e-mail down to the local mail server from the hosted mail server? Or is there a solution that's so simple that I'm overlooking it?

posted by waldo to computers & internet (10 comments total)

If it were me, I'd do fetchmail without even Googling for other methods ;-) I'm sure there are other simple ways you can synch two mail spools. What I would NOT do is create a system where each client needed two configs. That's duplication of work, silly.
posted by autojack at 1:26 PM on September 21, 2005

What I would NOT do is create a system where each client needed two configs.

Nah, I wouldn't want that. In an ideal world, Thunderbird would have options that I could set like such:

inbox_server = mail.example.com
inbox_username = joeblow
inbox_password = secret
imap_server = 192.168.0.100
inbox_username = joeblow
inbox_password = secret

The contents of the inbox would be retrieved from mail.example.com, and the rest of the IMAP hierarchy would be stored on 192.168.0.100.
posted by waldo at 1:36 PM on September 21, 2005

Mail should not be bouncing just because your Internet connection has gone down. MTAs trying to send you mail will just time out and re-queue the message, usually for three days or so. (Except for spammers, which don't do this because, hey, why waste time retrying servers which weren't up when you could be spamming someone else whose server is up instead? Losing their e-mail is a feature, not a bug.)

If you regularly have Internet outages lasting longer than three days, get another ISP. Failing that, what you want is a backup mail exchanger, not someone who will actually provide a mail store for you.
posted by kindall at 1:46 PM on September 21, 2005

Fetchmail is probably the best option if the company is going to store all your mail in mailboxes. A perhaps better, seamless way to solve this problem would be to just have the other company act as a secondary MX server. Your mail server will (usually) recieve all mail if you're connected, but if it's not reachable mail will go to the secondary MX. It will then queue your mail and automatically deliver it to your mail server when you get back up and running.

And for the Thunderbird thing, there's no reason why you can't set up an IMAP server and just use it for folders. You can drag messages in between different servers with no problem. I can drag a message from one IMAP server's INBOX into a folder on a second IMAP server. Or, I can drag mail from local storage to an IMAP server. Yes, your "storage only" IMAP server will have an Inbox (IMAP won't let you unsubscribe from INBOX), but it doesn't mean you have to use it.
posted by zsazsa at 1:47 PM on September 21, 2005

Mail should not be bouncing just because your Internet connection has gone down. MTAs trying to send you mail will just time out and re-queue the message, usually for three days or so.

Actually, five days is the standard. Unfortunately, many of our customers have poorly-configured mail servers, and they don't attempt to resent for very long -- some not at all. Worse still, their employees often don't understand e-mail, so they'll ignore a bounce message. We're in the insurance business, so a missed e-mail could be an order for an insurance policy that, if not received, could be a minor disaster.

zsazsa, your suggestion is intriguing. Very simple. I'll play with that.
posted by waldo at 1:51 PM on September 21, 2005

You could also set up another mx entry in your DNS to point to a "backup" mailserver. The backup mailserver would only get incoming mail if the primary mail server was down. It would then forward the mail on to the primary mail server (and because you set it up correctly, you would get the 5 day reties before bouncing).

This is a pretty standard way to set up mail servers, with no fetchmail or other extraneous programs needed.
posted by gus at 2:15 PM on September 21, 2005

Oh yeah, WTF is wrong with me. MX records. Forget I said anything and do what gus says.
posted by autojack at 2:18 PM on September 21, 2005

If you setup a secondary mail server, choose an offsite location, using a different ISP, in a different disaster zone (preferably on the other side of the country). As a small company, I recommend you find another small company with whom you have an existing relationship (and who have a clued-in network staff) and swap secondary services with them (they provide secondary DNS and mail services for you, you provide secondary DNS and mail services for them). You need both secondary DNS and mail, since if DNS services go down mail will be bounced immediately, even if the secondary mail server is still operational.

One of the "gotchas" with a secondary mail server is that it complicates server-side spam filtering. A not-uncommon spammer tactic is to ignore the primary mail server and deliver spam directly to the secondary, knowing that it will forward the spam to the primary and that the primary will see the origin of the spam as the secondary server (and obviously you can't reject mail from the secondary server). Solve this problem by making sure that any server-side anti-spam policy is enforced by both the primary and secondary mail servers.
posted by RichardP at 2:52 PM on September 21, 2005

RichardP, for the very reason that you cite -- spam -- I eliminated all of my backup MXs a couple of years ago. The backups were just overwhelmed with spooled mail, since user accounts aren't present on the MX, in which SpamAssassin could be run.

The other problem with a backup MX is that the spool can't be accessed. If our office catches fire, we have the daily off-site backups for our IMAP records, but we can't use, say, webmail to access our inbox spool. It remains spooled until the primary MX (or a new server) comes up, to which it can pass on the mail.
posted by waldo at 3:59 PM on September 21, 2005

You can use a service like MessageLabs or Postini to receive and filter the mail and then forward it on to your local server. They charge like $3/mo per user but they will scan all incoming mail for virus and SPAM. As mentioned above, there is great beneifit to filtering for these things during the initial connection/transfer of the message.

I have multiple e-mail accounts that I consolidate onto one IMAP server that I run locally (dovecot). Fetchmail pulls in all of my messages from the various accounts, and Procmail filters them into boxes for me. It works great and I also have IMAP access open from the outside, so I can access my email via my Treo/Palm.

We're in the insurance business, so a missed e-mail could be an order for an insurance policy that, if not received, could be a minor disaster.

You do know that there is no guaranteed delivery with e-mail and there is no guaranteed speed? Right? Please tell me that you are not using email as a reliable method for starting new policies?
posted by dhammala at 11:26 PM on September 21, 2005