Brad Hards | 1 May 04:48 2010
Picon

Re: [openchange]Obtaining server configuration data?

On Thursday 04 March 2010 04:44:56 pm Brad Hards wrote:
> I've started on a simple server ROP (GetAddressTypes from MS-OXOMSG), and
> my initial version works (in that the relevant part of mapitest passes
> when I run against it). However to get to that point, I've hard coded the
> responses (to be three strings "SMTP", "EX" and "X400". The code is
> attached.
> 
> I recognise that the appropriate address types should come from the server
> configuration, but I'm not sure how to do that.
With much help from Julien and a lot of staring at ldb.h, I finally got this to 
work without hard coding the response. Its now driven by the language code 
provided by the client, and by the provisioned configuration. Committed as 
revision 1767.

Any feedback would be appreciated.

Brad
Milan Crha | 3 May 14:31 2010
Picon

Re: [openchange]Crash test on concurrent access to the session

On Fri, 2010-04-30 at 18:34 +0200, Julien Kerihuel wrote:
> Attached is the modified concurrent_test.c with mutex support.
> 
> I basically lock the mutex (one per session) prior any MAPI call and
> unlock it after the call returns. 
> 
> This patch is really 'quick and dirty' but shows the problem can be
> fixed.

	Hi,
yup, I noticed a lock&lock in monitorB, where it should be lock&unlock,
but anyway, as the MonitorNotification function is blocking, then the
lock is "never" released, thus the get_inbox function never continues
its duty. It's technically the same as the old notification sample. :)

> The way to proceed now is to add a mutex to the session context,
> initialize it and do the lock/unlock where necessary within libmapi
> stack.
> 
> Initially I thought a lock/unlock enclosing dcerpc_EcDoRpc would be
> enough, but I guess we'll need macro instead to also enclose memory copy
> from the mapi_response pointer.

The idea is right, there should be done some locking in libmapi to
prevent concurrent access on objects which cannot handle it, like
connections and such. You mentioned on IRC: add one lock for any
provider within a session (emsmdb, nspi and rfr potentially).

> Now regarding the change, we can either add libpthread a dependency to
> libmapi or offer a --with-pthread compilation option at build time and
(Continue reading)

Julien Kerihuel | 4 May 15:14 2010

[openchange]Fixing website attacks

Hi All,

During the past few days, we've noticed a significant increase of attacks against the openchange website. Since we are focused on development at this time and we don't have someone that can handle this issue right now, we've decided to shutdown user registration for now.

(That is only meant for openchange public website and not other services ... except for trac we still have to handle).

Cheers,
Julien.

---
Julien Kerihuel

OpenChange SARL CTO

Email: jkerihuel <at> openchange.fr

Telephone:  +33 (1) 43.38.23.00
Mobile:        +33 (1) 81.42.73.73
Fax:             +33 (1) 43.38.15.85


OpenChange SARL                                                                                    
70, rue Amelot
75011 Paris, France

Registered in France.
VAT Registration Number: FR 11 489379388

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of right on the line unless specifically stated. If you have received it in error, please delete it from your system. Do not use copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that OpenChange SARL monitors e-mails sent or received. Further communication will signify your consent to this.


Julien Kerihuel
j.kerihuel <at> openchange.org
OpenChange Project Manager

GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79


_______________________________________________
devel mailing list
devel <at> lists.openchange.org
http://mailman.openchange.org/listinfo/devel
Milan Crha | 7 May 22:08 2010
Picon

Re: [openchange]Revision 1762 slightly unusable

On Thu, 2010-04-29 at 19:49 +0200, Milan Crha wrote:
> > The problem is that you're hitting cases that I don't see. So the
> TDD process 
> > is a bit harder here...
> 
> Sure, no problem, as long as we get this fixed before release.

	Hi there,
I'm still in process of testing the PT_DOUBLE bug, with not much
success, but that might be Evolution's issue, I'll investigate more.

But meanwhile, I'm offering you this patch. It slightly simplifies
cast_mapi_SPropValue function, and adds not as that many handled types,
but few it does. With this patch applied I can read my items from the
server with no crash, where after revision 1762 I couldn't. This patch
is applicable to revision 1775.
	Bye,
	Milan
Attachment (oc.patch): text/x-patch, 3673 bytes
_______________________________________________
devel mailing list
devel <at> lists.openchange.org
http://mailman.openchange.org/listinfo/devel
Vinay Nagrik | 7 May 22:52 2010
Picon

[openchange]Beginners question for configuring MAPI client

Hello Group,
 
I am new to MAPI proxy and in the process of learning.  I need to straighten out so many kinks.

Could anyone please tell me if Mozilla Thunderbird can work as a MAPI proxy client?
 
Also all SMTP servers work on port number 25.
 
Which port does the MAPI proxy work, so that I can specify it in the configuration of MAPI proxy client? 
 
Besides “Outlook”, are there other MAPI proxy client, with which I can work?
 
Could anyone also please tell me the “binding string” specification for the second MAPI proxy, which is trying to connect to “FINAL Exchange Server”.  What transport it will use, so that it safely reaches Exchange server, and the Exchange server can decipher it.
 
Generally the MAPI proxy binding string reads like transport:ip address.  Something like ncacn_ip_tcp:<ip address>
 
Please tell me these three things.  I will be very grateful.
 
It is very important for me and my project on which I am working.
 

Thanks and best regards.


--
Thanks

Nagrik

_______________________________________________
devel mailing list
devel <at> lists.openchange.org
http://mailman.openchange.org/listinfo/devel
Brad Hards | 8 May 01:16 2010
Picon

Re: [openchange]Beginners question for configuring MAPI client

On Saturday 08 May 2010 06:52:32 am Vinay Nagrik wrote:
> *Could anyone please tell me if Mozilla Thunderbird can work as a MAPI
> proxy client?*
mapiproxy uses the "exchange RPC" protocol, just like outlook and exchange do. 
I don't think Thunderbird can do that yet.

> *Which port does the MAPI proxy work, so that I can specify it in the
> configuration of MAPI proxy client?  *
Its dynamic (negotiated) via some underlying RPC calls. You shouldn't need to 
specify it.

> *Besides “Outlook”, are there other MAPI proxy client, with which I can
> work?*
Recent versions of Evolution should be OK.
You can also use the command line tools provided with openchange (like 
openchangeclient).

> **
> *Could anyone also please tell me the “binding string” specification for
> the second MAPI proxy, which is trying to connect to “FINAL Exchange
> Server”. What transport it will use, so that it safely reaches Exchange
> server, and the Exchange server can decipher it.*
> 
> Generally the MAPI proxy binding string reads like transport:ip address.
> Something like ncacn_ip_tcp:<ip address>
I don't understand what you can't figure out. It looks like
dcerpc_mapiproxy:binding = ncacn_ip_tcp:192.168.1.1[print]
(where you use the IP address of your sever, of course).
More details are at 
http://apidocs.openchange.org/mapiproxy/index.html#minute

> It is very important for me and my project on which I am working.
What project is this?

Brad
_______________________________________________
devel mailing list
devel <at> lists.openchange.org
http://mailman.openchange.org/listinfo/devel
Brad Hards | 8 May 06:35 2010
Picon

Re: [openchange]Revision 1762 slightly unusable

On Saturday 08 May 2010 06:08:28 am Milan Crha wrote:
> 	Hi there,
> I'm still in process of testing the PT_DOUBLE bug, with not much
> success, but that might be Evolution's issue, I'll investigate more.
Tell me more about what you're seeing. Is there a bugzilla entry somewhere?  
Can you get a network capture?

> But meanwhile, I'm offering you this patch. It slightly simplifies
> cast_mapi_SPropValue function, and adds not as that many handled types,
> but few it does. With this patch applied I can read my items from the
> server with no crash, where after revision 1762 I couldn't. This patch
> is applicable to revision 1775.
I didn't like the macro (just a stylistic preference), and didn't apply that 
bit. I copied your support for PT_MV_UNICODE and PT_MV_LONG directly, and 
implemented PT_I8 based on your patch (just without the macro).

Committed as r1779.

I'm undecided on this bit:
+	case PT_NULL:
+	case PT_OBJECT:
+	case PT_MV_SHORT:
+		/* types, which cannot be stored in mapi_SPropValue */
+		printf ("cast_mapi_SPropValue: Cannot cast prop value 0x%x to mapi 
type\n", sprop->ulPropTag & 0xFFFF);
+		break;

Can you explain what you're trying to do here?

[In a previous email you basically asked "why not just do them all"? I don't 
mind doing it, I just don't like code I don't have any tests for. I just don't 
trust untested code, and don't want to commit it. That is why I'm relying on 
your testing for this.]

Brad
Dan Shearer | 8 May 16:35 2010

Re: [openchange]Beginners question for configuring MAPI client

On Sat, May 08, 2010 at 09:16:54AM +1000, Brad Hards wrote:
> On Saturday 08 May 2010 06:52:32 am Vinay Nagrik wrote:
> > *Could anyone please tell me if Mozilla Thunderbird can work as a MAPI
> > proxy client?*
> mapiproxy uses the "exchange RPC" protocol, just like outlook and exchange do. 
> I don't think Thunderbird can do that yet.

Confirm, Thunderbird definitely cannot act as a MAPI client.

You will find references to Thunderbird using MAPI but that is in the
context of making Thunderbird the default email client on a Windows
machine, see http://kb.mozillazine.org/MAPI_Support . I suspect this
page is a bit dated (ie Thunderbird has had some bugs fixed since it was
written.)

Just for general interest - other people can relatively easily write
their own MAPI clients on Windows, by calling Microsoft's MAPI32.DLL.
These programs communicate with the Exchange server using exactly the
same library code as Outlook. When Evolution (not on Windows)
communicates with an Exchange server it uses entirely different,
non-Microsoft code, the equivalent to MAPI32.DLL being the libmapi
library.

--
Dan Shearer
dan <at> shearer.org
Milan Crha | 10 May 09:55 2010
Picon

Re: [openchange]Revision 1762 slightly unusable

On Sat, 2010-05-08 at 14:35 +1000, Brad Hards wrote:
> On Saturday 08 May 2010 06:08:28 am Milan Crha wrote:
> > 	Hi there,
> > I'm still in process of testing the PT_DOUBLE bug, with not much
> > success, but that might be Evolution's issue, I'll investigate more.
> Tell me more about what you're seeing. Is there a bugzilla entry somewhere?  
> Can you get a network capture?

	Hi,
I'll tell you when I will know more, I'm facing some issues with recent
evolution changes preventing me from testing this properly.

> I'm undecided on this bit:
> +	case PT_NULL:
> +	case PT_OBJECT:
> +	case PT_MV_SHORT:
> +		/* types, which cannot be stored in mapi_SPropValue */
> +		printf ("cast_mapi_SPropValue: Cannot cast prop value 0x%x to mapi 
> type\n", sprop->ulPropTag & 0xFFFF);
> +		break;
> 
> Can you explain what you're trying to do here?

>From the code reading I understood that struct mapi_SPropValue and
struct SPropValue are not 1:1, some values which can be stored in struct
SPropValue are not possible to store in struct mapi_SPropValue, and/or
vice versa. I found these three as the beginning. It's preventing crash
for developer compiles.

> [In a previous email you basically asked "why not just do them all"? I don't 
> mind doing it, I just don't like code I don't have any tests for. I just don't 
> trust untested code, and don't want to commit it. That is why I'm relying on 
> your testing for this.]

Yup, I understand that, I also do not like untested code.

One more thing I forgot to mention in my previous email: I noticed that
cast_mapi_SPropValue allocates memory on the global memory context, but
only partially, the array itself, but not array items, which might mean,
if I read and understand the core properly, that values in mapi_sprop
are valid only until the sprop value isn't freed. It is good and bad in
the same time. It's good as you do not allocate some memory twice (only
the array, with actually no gain), but it's bad as it's undocumented and
if I would like to use new mapi_sprop after free of source sprop, then
I've a bad luck. I think that:
a) the cast function should have one more argument, the mem_ctx which
should be used for values and arrays which require memory allocation
b) items with string and byte values should be also allocated in the
given context
c) I'm afraid of memory usage. Are these arrays allocated on the global
memory context freed with the mapi_sprop struct or on the program
exit/global memory context free? The later is something I would like to
avoid. But I do not know how exactly this works.
	Bye,
	Milan
Vinay Nagrik | 10 May 18:30 2010
Picon

[openchange]End to end binding string values

Hello Group,
 
Thank you for your previous reply.  That was very helpful.  I have one last question.  Please look at the following scenario.
 
<Mapi proxy client>   -->   <First Mapi Proxy>   -->   <Second Mapi Proxy>  -->  <Final Exchange server>
 
Now at my end I am providing the following setting for "binding string"
 
The very first address is <Mapi proxy client>. and at this point I am not providing the full
 
 ncacn_ip_tcp:<ip address>
 
At this point I am just providing a simple <ip_address of First Mapi Proxy>.
 
Then
 
At <First Mapi Proxy> I am providing
 
 ncacn_ip_tcp:<ip address of second Mapi Proxy>
 
and at the <second Mapi Proxy>, I gather from your reply that I should provide
ncacn_ip_tcp:<ip address of Final Exchange Server> and not the following
 
<ip address of Final Exchange Server> with no prefix of {ncacn_ip_tcp}
 
Please advise if this will be correct configuration for the first three places.  I will greatly appreciate your response.
 
Thanks in advance.
 
nagrik

_______________________________________________
devel mailing list
devel <at> lists.openchange.org
http://mailman.openchange.org/listinfo/devel

Gmane