244222 - add MAPI ResolveName

Status: RESOLVED FIXED

(MailNews Core :: Simple MAPI, defect)

Description

[David :Bienvenu]

We need to add the MAPI ResolveName interface.

Comment 1

[Rob Janssen]

Is there any Mozilla document that lists the MAPI interface functions and says
which ones are implemented by Mozilla and should work, and which ones are not
implemented?
(maybe both on a programmer and on a user level)

Comment 2

[Boris Zbarsky [:bzbarsky]]

*** Bug 259549 has been marked as a duplicate of this bug. ***

Comment 3

[WADA:World Anti-bad-Duping Agency]

*** Bug 53186 has been marked as a duplicate of this bug. ***

Comment 4

[John McCormick]

Microsoft's info on this function is at:
http://windowssdk.msdn.microsoft.com/en-us/library/ms529143.aspx

Seems like an acceptable implementation of this function, if no one has time to get into showing address books and stuff like that, would be to simply "resolve" a standard e-mail address to itself without otherwise checking it.

Comment 5

[John McCormick]

Working from bug 259585 comment 4, it seems like something like this should work:

ULONG FAR PASCAL MAPIResolveName(...)
{
    //return MAPI_E_FAILURE;
    char* lpszRecipName = new char[strlen(lpszName + 1)];
    char* lpszRecipAddress = new char[strlen(lpszName + 6)];
    strcpy(lpszRecipName, lpszName);
    strcpy(lpszRecipAddress, "SMTP:");
    strcpy(lpszRecipAddress + 5, lpszName);

    (*lppRecip) = (lpMapiRecipDesc FAR)malloc(sizeof(MapiRecipDesc));
    (*lppRecip)->ulRecipClass = 1;
    (*lppRecip)->lpszName = lpszRecipName;
    (*lppRecip)->lpszAddress = lpszRecipAddress;
    (*lppRecip)->ulEIDSize = 0;
    (*lppRecip)->lpEntryID = 0;

    return SUCCESS_SUCCESS;
}

Of course, I don't really do c-style windows programming or mozilla programming, and am not sure who should really own the strings. In theory that'd be one way to do it, though, I think.

On another note, when sending MAPI requests to Thunderbird in the past, I've found that it seems to like having the lpszName part of a MapiRecipDesc be the e-mail address to send to and the lpszAddress part set to NULL, so if that's the preferred format, maybe that should be done instead of filling them both. All this SMTP: and FAX: stuff is specific to outlook anyway, right? But, I think Thunderbird ignores it, so it shouldn't hurt to fill it in so long as the name part is an actual e-mail address.

Comment 6

[Frans-Jan v. Steenbeek]

Attachment: Implements very basic functionality for MAPIResolveName

Building upon the suggestion by John McCormick (2006-09-12 16:11:04 PDT) I've build Thunderbird with

ULONG FAR PASCAL MAPIResolveName(...)
{
    char* lpszRecipName = new char[(strlen((const char*)lpszName) + 1)];
    char* lpszRecipAddress = new char[(strlen((const char*)lpszName) + 6)];
    strcpy(lpszRecipName, (const char*)lpszName);
    strcpy(lpszRecipAddress, (const char*)lpszName);
    (*lppRecip) = (lpMapiRecipDesc FAR)malloc(sizeof(MapiRecipDesc));
    (*lppRecip)->ulRecipClass = 1;
    (*lppRecip)->lpszName = lpszRecipName;
    (*lppRecip)->lpszAddress = lpszRecipAddress;
    (*lppRecip)->ulEIDSize = 0;
    (*lppRecip)->lpEntryID = 0;
    return SUCCESS_SUCCESS;
}

Besides, MAPIAddress and MAPIDetails were set to always return MAPI_E_NOT_SUPPORTED (not sure if this is the way to go, but it worked and it seems more 'just' than always returning MAPI_E_FAILURE).

This was done to get two programs we use to work. The first (Avaya IP Office VoiceMail Lite) uses MAPIResolveAddress to send mail to a regular email address. This program now works. The second (AccountView) seems to use MAPIAddress to include a list of recipients. Obviously, that program does not work yet, but that is outside the scope of this bug (a new one should be opened for MAPIAddress, but I need to look into it a bit more).

Some caveats:
* lpszName is frequently typecasted to const char*. I do not think this is the way to go, but I have no experience with C++ to do it otherwise. Removing the typecasting causes the build to fail.
* The SMTP: bit was removed, since it seems that both Thunderbird and Outlook Express ignore these. Outlook Express does not add it, so it might be specific to Extended MAPI or even to Outlook alone. It looked ugly, it didn't hurt to remove it, so there it is. Again, not sure if this is the way to go.
* lpszName and lpszAddress are both filled, and identical (now I look at it, lpszAddress and lpszRecipAddress are both 5 chars larger since I forgot to correct that while removing SMTP:).
* The function only works when a regular email address is given. There are no checks or anything on that, so behavior might be strange when another string is passed. There should be something hooked into the addressbook, but there isn't.

Apart from all that, the function now works and enables a few 3rd party apps to work with Thunderbird.

DISCLAIMER!
I am not a C++ guru. I'm not even a C++ coder. In fact, this is the first serious bit of programming I've done that does not involve PHP or JavaScript. All I did was adding John McCormick's suggestion and rewriting it.

Comment 7

[Frans-Jan v. Steenbeek]

Attachment: Fixed typo in patch, now directing to the correct file (I hope)

Comment 8

[Ronald Killmer]

Nominating Wanted for Tb 3.0

Comment 9

[Magnus Melin [:mkmelin]]

Comment on attachment 309120 [details] [diff] [review]
Fixed typo in patch, now directing to the correct file (I hope)

Patch still applies.

Frans, you need to ask review to get the patch to go anywhere - see http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree. 

(I've done it for you this time.)

Comment 10

[Magnus Melin [:mkmelin]]

Marking wanted‑thunderbird3+ since we have a small patch.

Comment 11

[Frans-Jan v. Steenbeek]

@ #9

Even if I knew I wouldn't have done it. I don't know C++, but I do know the code I added is not really up to standards, to say the least. What I wanted to show is that, building on John McCormick's suggestion, a workable MAPIResolveName can be implemented quickly.

I would highly advise to have a proper C++ coder look at MapiDLL.cpp, build on the patch I added and make it into something more sane, more stable and equally workable. It'd be great if said coder can also implement MAPIAddress and hook both functions into the address book.

Comment 12

[David :Bienvenu]

Comment on attachment 309120 [details] [diff] [review]
Fixed typo in patch, now directing to the correct file (I hope)

MAPIREsolveName should actually resolve the name, in particular give the user a chance to resolve dupes, and hook up to the address book(s) - see http://msdn.microsoft.com/en-us/library/ms529143(EXCHG.10).aspx. This code should also check for allocation failure. We could build on this patch, but I don't have time to do this myself. We could check if MAPI_DIALOG is not set, and do simple AB resolution in that case, since doing the resolution dialog is the more difficult part.

Comment 13

[Frans-Jan v. Steenbeek]

That is correct, but please keep in mind that a lot of applications just fire a request at it and expect it to be send (used as an alternative for a built-in SMTP server). Whatever it does, it should at the very least accept plain email addresses and send the mail without further notice (if so configured).

Just unlocking that feature will enable a lot of applications to work with Thunderbird where they can't as it is now. I do not believe this should be an either/or implementation.

Comment 14

[David :Bienvenu]

I'm ok with an incremental approach...didn't mean to imply otherwise.

Comment 15

[Virgo Pärna]

Resolving this would probably also resolve bug 215978

Comment 16

[Ludovic Hirlimann [:Usul]]

(In reply to comment #15)
> Resolving this would probably also resolve bug 215978

A patch would be very welcome.

Comment 17

[gonzzza]

The fix was offered TWO years ago, and still Thunderbird 3 does not support MAPI ResolveName. Is it realy hard to implement such a simple fix? The bug has a NEW status, which means it wasn't even reviewed yet. Well great. How do we raise the priority of this one?

Comment 18

[David :Bienvenu]

(In reply to comment #17)
> The fix was offered TWO years ago, and still Thunderbird 3 does not support
> MAPI ResolveName. Is it realy hard to implement such a simple fix? The bug has
> a NEW status, which means it wasn't even reviewed yet.

the patch was reviewed and minused, but a new patch was not submitted. Status NEW just means someone didn't change the status to assigned. It says nothing about whether a patch was reviewed or not.

Comment 19

[bugzilla.org]

Hey All

This issue is causing me major pain as we use Thunderbird in our office and because of this bug i am not very popular with the rest of our staff as they each have to use an old copy of outlook to send emails with attachments straight from an accounting program written in Foxpro.

As such i am willing to pay someone to get this fixed and in the next stable release. If anyone knows who i should contact about this please contact me or reply to this post.

If not i guess i will have to start learning C++

Comment 20

[Theo]

The same for me!

We're using Thunderbird 3 in an office with >100 stations and the ERP system sends email trough SimpleMAPI. Recipient's address is added to the mail text instead of the correct To: field in TB.

It would be great if anyone could comment on the priority of full MAPI support for Thunderbird as it's one of the big aspects for companies using TB.

Comment 21

[mb]

Me too.  This is an issue in an office, as so many third party applications use mapi calls.

Comment 22

[Magnus Melin [:mkmelin]]

phil, interested in finishing this patch?

Comment 23

[Patrick Kurz]

Hi, I tryed to implement code above - in TB 3+ but did not work - can anybody help? Multiple errors (SDK Windows 7). We need this funktion for ERP Software, etc.

or can someone send me a compiled mozMapi32.dll with MapiResolveName? For testing our ERP? 

Thanks Patrick

Comment 24

[Worcester12345]

We need MAPI support for some telephony applications, such as sharing address book. Any chance of this happening soon?

Comment 25

[Patrick Kurz]

(In reply to comment #24)
> We need MAPI support for some telephony applications, such as sharing address
> book. Any chance of this happening soon?

Hi, 
I´ve fixed the mozmapi32.dll by myself - it works for xp, 2003 and 7 (only 32bit) there is a bug with 64bit 7 we can´t handle. I can send you a copy of my dll if you like?

Patrick

Comment 26

[Worcester12345]

(In reply to comment #25)
> (In reply to comment #24)
> > We need MAPI support for some telephony applications, such as sharing address
> > book. Any chance of this happening soon?
> 
> Hi, 
> I´ve fixed the mozmapi32.dll by myself - it works for xp, 2003 and 7 (only
> 32bit) there is a bug with 64bit 7 we can´t handle. I can send you a copy of my
> dll if you like?
> 
> Patrick

I'd rather see the focus on getting it into the core product for full support. This is not an individual install, but a company-wide thing. Thanks.

Comment 27

[Worcester12345]

How can this be + on "wanted‑thunderbird3" when "thunderbird3" is already out and the successor is in place? Is there a ? or + for "wanted‑thunderbird3.2"?

Comment 28

[Werner F. Bruhin]

Would really like to see this too.

Patrick did you/can you provide what you did to Mozilla?

If you woulnd't mind would appreciate if you could send it the dll to me, would like to test it.

Werner

Comment 29

[Werner F. Bruhin]

Would really like to see this too.

Patrick did you/can you provide what you did to Mozilla?

If you woulnd't mind would appreciate if you could send it the dll to me, would like to test it.

Werner

Comment 30

[David :Bienvenu]

I'm ok with accepting a patch based on the existing patch that checks for out of memory, which should be very easy.

Comment 31

[Tony Sosa]

Would like to see this resolved for Win7 64-bit.

Comment 32

[:aceman]

I can look at fixing it up per comment 30.
But can this be compiled on linux? Or is it skipped in the build there?

Comment 33

[:aceman]

Attachment: patch, add check out of memory and other cleanup

Comment 34

[:aceman]

I did not compile it, I suppose it is only for Windows. Somebody please test the patch.

Comment 35

[Jim Porter (:squib)]

Comment on attachment 587088 [details] [diff] [review]
patch, add check out of memory and other cleanup

Review of attachment 587088 [details] [diff] [review]:
-----------------------------------------------------------------

Just a quick pass from me since I noticed a potential leak. See below.

::: mailnews/mapi/mapiDll/MapiDll.cpp
@@ +402,5 @@
>  {
> +  char* lpszRecipName = new char[(strlen((const char*)lpszName) + 1)];
> +  char* lpszRecipAddress = new char[(strlen((const char*)lpszName) + 6)];
> +  if (lpszRecipName == NULL || lpszRecipAddress == NULL)
> +    return MAPI_E_INSUFFICIENT_MEMORY;

You probably want to delete lpszRecipName and lpszRecipAddress here just in case one of them fails but not the other. Don't forget to use delete[], not delete. (Also, barf, Hungarian names.)

Comment 36

[:aceman]

Good catch, will fix the leak.

What did you mean with the variable names? They seem to use the style of the surrounding code.

Comment 37

[:aceman]

Do I also need to check *lppRecip ?

Comment 38

[:aceman]

Attachment: patch, fix proper release of memory in case of failure

Comment 39

[David :Bienvenu]

Comment on attachment 587107 [details] [diff] [review]
patch, fix proper release of memory in case of failure

thx very much for the patch

this doesn't compile for me because it can't find msgMapiMain.h - not sure why.

+#include "msgMapiMain.h"

+  if (lpszRecipAddress == NULL) {

should be !lpszRecipAddress

similarly for the other null checks...mozilla style guide says to use !ptr, not ptr == null

-  	return(S_OK);
+    return(S_OK);

should be return S_OK;  no parens

Comment 40

[David :Bienvenu]

I don't think that include is needed in MapiDLL.cpp - I'll attach the patch that builds for me.

Comment 41

[David :Bienvenu]

Attachment: patch that builds for me

Comment 42

[:aceman]

Thanks, I'll fix the other nits.

Comment 43

[:aceman]

Attachment: patch v3

Comment 44

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/0f7e5afbe650

Comment 45

[Ludovic Hirlimann [:Usul]]

Requesting ESR support for that feature as it let's Thunderbird interact with a bunch of other Enterprised software (such as crystal report).

Comment 46

[:aceman]

For those deciding it it is worth it:
There is a confirmation this helps with Crystal reports in bug 215978.
We wait for confirmation with MS Word in bug 259585.

Comment 47

[Emilio Lumia]

Hello,
this works for me with a third part software (see Bug 251228 - Fail to send a message from a third party software with MAPI) on a windows 2003.

Please just a question : how to don't send the message on the fly, so user can edit it.

Thx very much.

Comment 48

[:aceman]

Has your software started working after we solved this bug?

Comment 49

[David :Bienvenu]

I think this would be a good thing to land on the ESR branch.

Comment 50

[Mark Banner (:standard8)]

(In reply to David :Bienvenu from comment #49)
> I think this would be a good thing to land on the ESR branch.

Agreed, though I'd like to bake this for a while in case there are any side effects. At the moment, not going to take it until 13, when this fix is scheduled to be released, although we could potentially move it forward to 12, but we'll think about that early next cycle.

Comment 51

[Mark Banner (:standard8)]

Comment on attachment 597912 [details] [diff] [review]
patch v3

[Triage Comment]
a=Standard8 for ESR.

Comment 52

[Mark Banner (:standard8)]

Landed on esr: https://hg.mozilla.org/releases/comm-esr10/rev/36ce100dacb4