Non-local mailboxes

["M. Thielker" <balsa t-data com>]

Hello,

 I had asked oGALAXYo from #balsa to forward this issue to the mailing list. Now I've subscribed myself. Maybe there have been replies that I've missed, so here I go again.

I tries to set up Balsa to store incoming pop3 mail in a non-local (IMAP) folder. That didn't work as expected, even when the local maildrop is removed from the configuration, pop3 mail still gets stored there.

Apparently the fetch_pop_mail_direct() function takes a spool file name, which, of yource, can only be local. I haven't got the time to dig into the source to find where that name is passed, but I suppose that for lack of a usable (local) mailbox to pass the file name of, the default maildrop file is used.

The need for this functionality arises because a number of people need to work with emails from a single pop3 mailbox concurrently, some on portables that aren't always online.

My idea was to configure each of the machines to access the pop3 maildrop, so no one machine needs to be turned on for the system to work, any machine can poll the pop3 maildrop and then stores the retrieved emails into an IMAP folder for others to use.

For this to work, several conditions must be met:
* delivery of incoming pop3 mail to non-local mail folders must be possible
* local copies of IMAP folders must be kept and updated automatically on the portable clients
* when another user changes the contents of an IMAP folder, Balsa must update the displayed folders without the need for a manual interverntion.
* when a portable client reconnects, all subscribed IMAP folders must be automatically synchronized to the local copies by deleting emails on the server that have been deleted locally while offline and adding emails that have appeared on the IMAP server while the client was disconnected. Also, locally cached emails should be deleted if they're not on the server anymore and all emails added locally should be transferred to the server.
* Balso must be configurable to access the pop3 maildrop while not accessing the IMAP server unless the user wants to. This is to avoid excessive data transfers while connected by a modem line. Suggestion: a check box on the IMAP account to attempt connection only when a local ethernet interface is the route to the server.

Of all these points, all but the first are optional, though highly desirable. Being able to store incoming mail in IMAP mailboxes is, however, required for our use of Balsa. Meanwhile, we are forced to use vmware to run M$-Out***k because MAPI is currently the only way to achieve the desired results.

Here's another suggestion as well: I have done some tests and found that mapi.dll *will* work under WINE. It should therefore be possible to write a small, command line based Windows daemon to run mapi.dll and allow data transfer to and from a unix domain or TCP socket. That way an extra gateway machine running Windows can be avoided, as well as installing additional software on the Windows Exchange server. The former is not desirable in corporate environments, while the latter often fails because sysadmins often fail to see a need for Linux desktops.
Many people on the net are looking for an email solution able to access Exchange server folders from the linux desktop. For many the unavailability of such an email client is the main reason for staying with Windows.
Microsofts reverse-engineering policy makes everyone afraid of analyzing and reimplementing Exchange server's protocols, for fear of retaliation from Micro$oft.
This solution would avoid those pitfalls, because Micro$ofts very own .dll would do all the work and allow a Linux based email client to access Exchange server 5.0 or 5.5 with IMAP disabled like Out***k does.

Well, that's my $0.02.

All the best,

M.