GNOME Bugzilla – Bug 621064
Can't send email to a trusted AD domain
Last modified: 2010-10-20 06:08:00 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.
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?
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.
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.
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.
(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.
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?
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
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).
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.
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.
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.
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.
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.
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.
Yes, I'm using the current F13 openchange client. I'm happy to test anything out.
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.
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.
Thanks for the update. So this is something else :-(
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.
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.
One more comment ... the error I'm getting is a "ModifyRecpients: MAPI error ecRpcFormat (0x4b6) occurred"
Created attachment 172513 [details] [review] Fix for libmapi in openchange trunk code Apply the patch in the libmapi directory of openchange trunk
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.
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
This is now fixed in the trunk of libmapi (0.11) not sure if they will take it back to 0.10 ... :)
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.