On Wed, 2009-02-25 at 17:36 +0100, Miklos Balazs wrote: > I am exploring the possibility of using mapiproxy to act as a gateway > between Outlook and a third-party groupware suite, translating MAPI > RPC messages to the third party groupware's API, thus allowing Outlook > to communicate with the groupware suite natively. > > As I understand from the documentation, I would have to use mapiproxy > in proxy mode, and write a module which has the norelay option set on > its hooks, and it constructs the corresponding RPC message to the > third-party groupware server, then it receives the response and > translates it to the appropriate MAPI messages. I haven't looked at > the sources yet, but based on what I have read, this seems to be a > straight-forward task.
Hi Miklos,
I think you are mixing different mapiproxy concepts here:
1. mapiproxy in proxy mode with norelay option implies (whatever happen)
to have a running Exchange server behind:
1. Outlook authenticates on mapiproxy
2. mapiproxy initiates a connection to remote server
3. mapiproxy intercepts Outlook request and reply on its own
2. I may have misunderstood your query, but I think you are rather
looking for a proxy-gateway translating MAPI to whatever with no
Exchange server at all running in the organization:
1. Outlook authenticates on mapiproxy
2. mapiproxy acts as a server and work as a translator
Implementing a proxy gateway with case 1 is possible but really not
trivial. We are talking about mixing an existing mailbox managed by
Exchange with another system. It implies mapiproxy has, among other
things, to handle MAPI handles management and Message identifier on its
own:
- The technology for MAPI handles is available into OpenChange,
so this shouldn't be much a problem.
- Handling message identifiers may be more problematic. The
development effort can probably be kept minimal if your 3rd
party groupware messages lies in different folders than
system/special ones (Inbox, Calendar, Task etc.). This would
mean the folder object does exist on the real Exchange server
but messages are stored within another backend.
- Managing messages between Outlook-3rd party groupware means
mapiproxy will be responsible for creating message identifiers
for these message objects. This can lead to message ID
collisions, e.g.: "Exchange creates a new message with same ID
than one created for your application". If Outlook doesn't check
for message ID collisions too closely and tolerate this, it can
be done easily. However it would IMHO be very wrong design.
Otherwise you could delegate message ID generation to Exchange
and create empty messages within these custom folders so
Exchange "reserves" the message identifiers.
Case 2 is much more complicated. We are not talking anymore about
injecting traffic into an existing communication, but handle the whole
communication*s* on our own. It requires mapiproxy to have the entire
underlying technology and semantics needed to maintain this connection:
MAPI store support but also Address Book (GAL) support.
Here you are looking for OpenChange server and you have two choices:
1. Implement a custom backend for mapistore [1]. It is the
abstraction storage layer we are working on.
* Advantage:
- You delegate most of the MAPI semantics thing
to us and focus on translating data only
(fetch/get). This widely reduces the amount of
work needed.
* Drawback:
- You entirely depends on how much coverage we
have for MAPI Rops.
2. OpenChange can integrate custom providers. You can develop
your own EMSMDB provider:
* Advantage:
- You do not depend on us and can implement your
provider the way you want.
- You can however use some of the shared
technology to reduce the scope of your work
(MAPI handles management, mapistore etc.)
* Drawback:
- You do not depend on us and have to implement
your provider on your own ;-)
> However, I have some questions that I can't find the answer for, and
> I've thought that I'd better ask the developers before spending days
> on finding them. First, regarding the maturity of mapiproxy: does the
> current version in the repository has all features developed that this
> gateway module would need?
For case 1, yes.
For case 2, not yet - it is under heavy development.
> When is the first stable release of mapiproxy to be expected?
mapiproxy (proxy mode) is assumed to be stable already.
> And most importantly, I think that the most difficult problem with
> implementing this module would be the authentication process, and
> whether or not Samba is the domain controller is a cardinal question
> regarding this issue. If Samba is the domain controller, then the
> correct way would be to connect Samba's authentication database with
> the groupware suite's, so users could log in to the domain with their
> groupware credentials. I suppose this would'nt be too hard to
> accomplish, because Samba4 has a modular database backend, am I right?
The easier would probably be to take the problem the other side: "users
log in to the groupware using their domain's credentials."
> But what if I don't want to use Samba as a domain controller? How is
> authentication handled in mapiproxy? Does it use Samba's
> authentication backend?
Then you can't use mapiproxy.
> I have noticed that I couldn't log on to an Exchange server through
> mapiproxy unless I had the same username for my Windows profile and
> for the Exchange server.
I am not sure I understand what you mean here.
> And in the example configuration at mapiproxy.openchange.org, the
> username and password is "hard coded" in the config file. Is it
> because mapiproxy's authentication component is not written yet?
mapiproxy doesn't formally need to implement any authentication
mechanism at all, it entirely relies on Samba4.
We anyway have 2 authentication methods:
1. specified credentials (the one you mentioned)
2. delegated credentials (krb5) which should theoretically be
working but which isn't yet.
Cheers,
Julien.
[1] http://wiki.openchange.org/index.php/MAPISTORE_SAL_Architecture
--
Julien Kerihuel
[email protected]
OpenChange Project Manager
GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
