After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 621064 - Can't send email to a trusted AD domain
Can't send email to a trusted AD domain
Status: RESOLVED NOTGNOME
Product: evolution-mapi
Classification: Applications
Component: Mail
0.30.x
Other Linux
: Normal normal
: ---
Assigned To: evolution-mapi-maint
evolution-mapi-maint
Depends on:
Blocks:
 
 
Reported: 2010-06-09 06:35 UTC by Milan Crha
Modified: 2010-10-20 06:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed ema patch (2.39 KB, patch)
2010-08-25 07:47 UTC, Milan Crha
rejected Details | Review
ema test patch (731 bytes, text/plain)
2010-09-01 08:56 UTC, Milan Crha
  Details
Fix for libmapi in openchange trunk code (2.29 KB, patch)
2010-10-16 21:33 UTC, rbezuide
none Details | Review

Description Milan Crha 2010-06-09 06:35:14 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=588486

When sending a message to a trusted AD domain, message sits in outbox.

Version-Release number of selected component (if applicable):

evolution-2.30.1-2.fc13.x86_64
evolution-mapi-0.30.1-1.fc13.x86_64

How reproducible:
always

Steps to Reproduce:
1. send message to user on trusted AD domain
2.
3.

Actual results:
message sits in outbox

Expected results:
message is sent

----------------------------------------------------------------------------

When you say "sending a message to a trusted AD domain", what does it mean
exactly? Is it like filling only username of a user which is on the server to
the recipient list (To/CC)? It seem to work fine for me.

----------------------------------------------------------------------------

We have domain1 and domain2, there is a two-way trust between domain1 and
domain2.  I'm in domain1, and was trying to send a message to user in domain2.

----------------------------------------------------------------------------

In parsing through that output while I was scrubbing it, I noticed that it kept
saying:

  error_code               : ecUnknownUser (0x3EB)

which is probably what is causing it to choke.  Evolution is talking to the
trusted domain fine though, as I can see all of domain2 users in GAL.  So it
would seem that the GAL code is handling the trusted domain fine, but the mail
code isn't?

----------------------------------------------------------------------------

I see that line too, but it's rather a "first try", then it tries to find the
user, and it seems to succeed. but later on:
> SubmitMessage            : ecInvalidRecips (0x467)
so even it found him the server rejected him.

Are you using autocompletion when entering Joe's email, or you put in just his
name and let it resolve the right name before sending? I would guess using his
full email address should work, and using his username only as well, as it
works fine for me here, though my server communicates with only one domain.

When you try to send an email to yourself, not using your email address, will
it work or not?

----------------------------------------------------------------------------

> Are you using autocompletion when entering Joe's email, or you put in just his
> name and let it resolve the right name before sending? I would guess using his
> full email address should work, and using his username only as well

I've tried letting autocomplete work (via GAL), I've tried manually entering
his username@domain, and manually entering username (letting it resolve when I
push send).  not one of those emails will send.

> works fine for me here, though my server communicates with only one domain.

right, the single domain issue, which affected me here in F11 and F12, was
fixed with bug# 496702.  could this be related to that bug?

> When you try to send an email to yourself, not using your email address, will
> it work or not?    

autocomplete, manually entering my email address, and manually entering just my
username all work to send myself a message.

----------------------------------------------------------------------------

Thanks for the update. I've unfortunately not much idea where to continue,
maybe we can try with openchangeclient, whether it'll work or not. I suppose
the same works just fine with Outlook.

Please create an openchangeclient profile, with a command like this:
   $ mapiprofile -S -P $PROFILENAME -c -I $SERVERADDRESS -u $USERNAME
      -p $PASSWORD -D $DOMAIN
which will create a default profile named as $PROFILENAME. It can be almost
anything, so feel free to use a $USERNAME there as well. The other values are
exactly the same as you entered while creating the MAPI account in Evolution.

Then you can run the openchangeclient:
   $ openchangeclient -S --to=$TO "--subject=test email" "--body=body of
       a test email"
where $TO is a name, or email address of the user in the second domain.
Probably same as you see in Global Address List.

----------------------------------------------------------------------------

Created mapi profile, sent messages to myself, and I received them.  I was able
to do this successfully whether I only specified 'user' or if I used
'user@domain'.

Furthermore these sent messages were also correctly copied to my "Sent Items"
folder on exchange.

However, when I sent messages to the domain2 user, they seemed to vanish into
thin air.  openchangeclient gave no indication that they didn't successfully
send.  openchangeclient even returned 0.  The domain2 user didn't receive them,
they didn't bounce back to me like they would if I specified a nonexistent user
on domain1.  

Also, a copy of the email sent to the domain2 user wasn't left in my "Sent
Items" folder like they were with the successful sends.

I tried to debug what was going on, but even setting --debug-level=10 didn't
seem to change anything.  openchangeclient ran quietly.
Comment 1 Milan Crha 2010-06-09 06:40:41 UTC
I just noticed, the --debug-level=10 should be --debuglevel=10, then the openchange will print debug output.

I'm still not sure how you write the address to the user on the second
domain in the message composer, is it like user2@example2.com , whereas
you are user1@example1.com or is it just user2 instead of the email
address?
Comment 2 Milan Crha 2010-06-29 15:36:23 UTC
I received an openchangeclient log from you, and I compared it with a log I did on the actual openchange svn trunk version, and I see one difference: both are sending four properties when calling ModifyRecipients, but mine version uses
> PR_OBJECT_TYPE (0xFFE0003)
> PR_DISPLAY_TYPE (0x39000003)
> PR_7BIT_DISPLAY_NAME_UNICODE (0x39FF001F)
> PR_SMTP_ADDRESS_UNICODE (0x39FE001F)
and that yours
> PR_OBJECT_TYPE (0xFFE0003)
> PR_DISPLAY_TYPE (0x39000003)
> PR_SEND_RICH_INFO (0x3A40000B)
> PR_7BIT_DISPLAY_NAME_UNICODE (0x39FF001F)
where that mine succeeded, but that yours resulted in ecRpcFormat error code, which is a generic error about the sent request, as I understand it. It seems to me that the PR_SMTP_ADDRESS_UNICODE makes the difference, and that the server wasn't able to recognize proper recipient with given PR_7BIT_DISPLAY_NAME_UNICODE only (it's basically only a user name part from the email).

I'm wondering how to test it (whether it'll be fixed for you in the latest openchange), because compiling openchange from svn trunk is something not so easy, due to its dependency on samba4 and also due to its API changes, so you wouldn't be able to use evolution-mapi if not compiled against that openchange version.
Comment 3 Chad Feller 2010-07-07 19:47:59 UTC
I'm thoroughly confused here.  I was just able to send an email to domain2 with evolution-mapi.  Only a minor update in versions since I originally reported this:

evolution-mapi-0.30.2.1-1.fc13.x86_64
evolution-2.30.2-1.fc13.x86_64

I still cannot send an email directly to domain2.  However, as I just accidentally stumbled upon, I can if domain1 is in the "To:" field and domain2 is in the "Cc:" field.

After doing some testing I can confirm the follows.  If I compose and email as follows:

To: user-foo@domain1.com
Cc: user-bar@domain2.com

the message will get sent and user-foo and user-bar will get the message.  If I reverse them:

To: user-bar@domain2.com
Cc: user-foo@domain1.com

the message will sit in the outbox...  To help make things clear, I'll restate that I'm in domain1.

I'm not sure if that info helped or just made things more confusing.
Comment 4 Milan Crha 2010-07-08 20:46:37 UTC
Thanks for the update. This is very interesting. It makes things clearer, actually. There are three options which can happen when users are resolving on the server. It's either found, not found, or there are found more with the similar name. As the last cannot happen, and the first is pretty simple, then I suppose the user in domain2 couldn't be resolved.

By reading the code, emails are simply processed in the order from top to bottom in your example, so in the first case (I suppose) it is:
 - resolved
 - unresolved
and with the resolved one it adds it to the list at the first position, and then adds the unresolved one at the end (the second position) as an email address and changes recipients on the message to these two.

The reverse order should behave pretty similar, but on the first look it seems that the unresolved email is added to the last position first, which means to the position 0, and the resolved one is not added at the end, but it rewrites the first position, so it seems we claim we are sending to two recipients, but the structure for the second recipient isn't filled.

I'll try to test the hypotheses on my machine and give here an update.
Comment 5 Milan Crha 2010-07-08 21:19:19 UTC
(In reply to comment #4)
> I'll try to test the hypotheses on my machine and give here an update.

Hrm, no, I'm wrong, the array if filled properly, at least with indexes. I overlooked that resolved email addresses are in the array already, so those unresolved should be added always at the end, thus the index in the above hypotheses is not 0, but 1 for the last item in the array.
Comment 6 Milan Crha 2010-07-09 10:17:04 UTC
It seems evolution-mapi used a very similar algorithm as is used in the openchangeclient, the part of recipient name resolution. In case this will work correctly in openchangeclient when you change order to the correct one, could you send me logs for both cases (--debuglevel=10) so I can compare them, please?
Comment 7 Chad Feller 2010-08-09 21:41:06 UTC
Milan,

Sent you the openchange client log a few days back.  If you did not get it, let me know and I'll resend.

-Chad
Comment 8 Milan Crha 2010-08-24 14:16:36 UTC
Thanks, I received it (and was away, so it also took me longer to get back to this). I see from the non-working log that the openchangeclinet is using these properties:
 : PR_OBJECT_TYPE (0xFFE0003)
 : PR_DISPLAY_TYPE (0x39000003)
 : PR_SEND_RICH_INFO (0x3A40000B)
 : PR_7BIT_DISPLAY_NAME_UNICODE (0x39FF001F)

whereas the working log is using these properties:
 : PR_OBJECT_TYPE (0xFFE0003)
 : PR_DISPLAY_TYPE (0x39000003)
 : PR_7BIT_DISPLAY_NAME_UNICODE (0x39FF001F)
 : PR_SMTP_ADDRESS_UNICODE (0x39FE001F)

so the difference is whether to use PR_SEND_RICH_INFO or PR_SMTP_ADDRESS_UNICODE, but I believe the PR_SEND_RICH_INFO is unrelated to us. Looking more into the log the other recipient, from the second domain, is found in both cases, just once also the email address is provided in the data blob, and the second time only the PR_7BIT_DISPLAY_NAME_UNICODE, so, I suppose, the server was unable to find the user on the PR_7BIT_DISPLAY_NAME_UNICODE base. It might mean that we should always include a PR_SMTP_ADDRESS_UNICODE when modifying recipients.

I'm sorry, but I forgot it already, are you able to test code changes on your machine, please? It means if you can compile evolution-mapi from source (it's pretty straightforward, only devel packages for evolution-data-server, evolution, openchange and possibly some other packages are required, but compilation is done only with evolution-mapi, which is a small package).
Comment 9 Chad Feller 2010-08-24 14:40:35 UTC
I can test code changes.  Just let me know if there is a patch you want me to apply to the F13 version, or if you want me to pull the code from somewhere.
Comment 10 Milan Crha 2010-08-25 07:47:46 UTC
Created attachment 168711 [details] [review]
proposed ema patch

for evolution-mapi;

This makes every outgoing mail to be SMTP addressed, not EX addressed, if possible. It seems to work on my machine, but please give it a try. I suppose it being applicable to F13 ema too, maybe except the last chunk, fix of a typo in a string, which you can safely ignore.

Please give it a try and let me know, as we can commit to source only until Monday to have it included in 2.32.0. The best if you can try to send a message only to jk, and then to you and jk in both orders (you first and he first), just to make sure it does the right thing for these cases. Thanks in advance.
Comment 11 Chad Feller 2010-08-29 21:02:59 UTC
uninstalled evolution-mapi rpm

used source tarball extracted from:

  evolution-mapi-0.30.2.1-1.fc13.src.rpm

and applied above patch.  As you suspected, two of the three hunks applied:

# patch -p1 < /var/tmp/ema.patch 
patching file src/libexchangemapi/exchange-mapi-connection.c
Hunk #1 succeeded at 939 with fuzz 1 (offset -276 lines).
Hunk #2 succeeded at 963 with fuzz 1 (offset -276 lines).
Hunk #3 FAILED at 1353.
1 out of 3 hunks FAILED -- saving rejects to file src/libexchangemapi/exchange-mapi-connection.c.rej

did a ./configure && make && make install.

This was a pristine F13 install, with no evolution profile, so I created a new profile.  

Everything with regard to evolution-mapi behaved as it did on my main workstation, including the error sending to domain 2.  That is, the patch didn't change anything.
Comment 12 Milan Crha 2010-08-30 13:55:23 UTC
Thanks for the update. I see the patch changed a bit, but the result is still the same, cannot send a message. From the log you sent me I see the recipient is identified by the email address, rather than the exchange address book "ID". Which means the patch applied. Then is message saved successfully, but when it is about to submit, the function call fails:
> SubmitMessage : ecInvalidRecips (0x467)
This fails later in the code (if I recall correctly), than without the patch, but it still fails.
Comment 13 Bharath Acharya 2010-08-31 09:51:00 UTC
Is this related to https://bugzilla.gnome.org/show_bug.cgi?id=568763 ?

If yes, try the patch at https://bugzilla.gnome.org/show_bug.cgi?id=568763#c33 and see if it fixes your issue. The patch may not apply cleanly for your sources, but it is a very minor change.

Let us know if it helps. This was fixed long back by the openchange devs,
http://websvn.openchange.org/revision.php?repname=OpenChange&path=/trunk/libmapi/IMessage.c&rev=1649&peg=1649

After the openchange fix, I haven't heard anyone complaining about this issue.
Comment 14 Milan Crha 2010-08-31 10:01:39 UTC
Thanks for the insight, Bharath, I didn't know about this.

Chad, I suppose you are using the standard Fedora openchange package, right?

I cat try to build a test package of openchange for you, with the fix included, and you'll just revert your evolution-mapi with my above proposed patch (knowing Bharath has a fix for it already...) and test it.
Comment 15 Chad Feller 2010-08-31 18:16:03 UTC
Yes, I'm using the current F13 openchange client.

I'm happy  to test anything out.
Comment 16 Milan Crha 2010-09-01 08:56:08 UTC
Created attachment 169220 [details]
ema test patch

for evolution-mapi;

I realized that Fedora 13's openchange package contains a fix Bharath mentioned above, even the ChangeLog in the 0.9 release doesn't indicate it. Nonetheless, it's there.

This patch returns back a workaround from Bharath's Gnome bug. Please revert the previous patch I gave you and try with this one, we'll see whether it'll help or not. Thanks in advance.
Comment 17 Chad Feller 2010-09-15 16:09:35 UTC
I uninstalled the previous evolution-mapi instance (make uninstall), then moved the previous build directory out of the way and started over.  I unpacked the same sources as used in commment #11, and applied the above patch from comment #16:

  # patch -p1 < /var/tmp/ema.patch
  patching file src/libexchangemapi/exchange-mapi-connection.c

and did a ./configure && make && make install

This patch still didn't fix the problem, and in fact it caused in a regression in so much as not only could I not send an email to user2 on the trusted AD domain, but I couldn't even send an email to myself.  Could send emails to users off the domain just fine.
Comment 18 Milan Crha 2010-09-15 16:52:51 UTC
Thanks for the update. So this is something else :-(
Comment 19 Milan Crha 2010-09-20 16:07:07 UTC
I finally read your logs you sent me, and both are failing with
> SubmitMessage : ecInvalidRecips (0x467)
everything before works as expected, no error, no issue, only that final submit fails.

I got out of idea here, I'm sorry.
Comment 20 rbezuide 2010-10-12 14:30:12 UTC
Hi,

I'm seeing the same issue here sending to users in a different domain than mine inside the same company.  Anything else you might think to try I'll be willing to help.  I can compile from source and have 2.32 evolution checked out as well ass openchange via svn of their trunk code.
Comment 21 rbezuide 2010-10-12 17:10:12 UTC
One more comment ... the error I'm getting is a "ModifyRecpients: MAPI error ecRpcFormat (0x4b6) occurred"
Comment 22 rbezuide 2010-10-16 21:33:44 UTC
Created attachment 172513 [details] [review]
Fix for libmapi in openchange trunk code

Apply the patch in the libmapi directory of openchange trunk
Comment 23 rbezuide 2010-10-16 21:35:16 UTC
This is a patch on openchange libmapi to fix a delivery problem and the "missing" PR_SMTP_ADDRESS_UNICODE mentioned above.  This allows me to send email to myself and people in other trustred domains.
Comment 24 Milan Crha 2010-10-18 07:00:31 UTC
Thanks for a patch. I cannot test this myself, but I entered an upstream request to test and include the patch in any next release of openchange. See [1] for more details.

[1] http://tracker.openchange.org/issues/326
Comment 25 rbezuide 2010-10-19 21:27:09 UTC
This is now fixed in the trunk of libmapi (0.11) not sure if they will take it back to 0.10 ...

:)
Comment 26 Milan Crha 2010-10-20 06:08:00 UTC
Julien told me that they will do regular updates, more often than the one between 0.9 and 0.10, so it'll come out sooner. I do not have exact dates, though. The revisions are r2203 and r2204 in OpenChange.

Either way, I'm closing this bug.