GNOME Bugzilla – Bug 568763
MAPI - can't send mails to addresses on same server
Last modified: 2009-12-24 08:56:03 UTC
Please describe the problem: When I send emails using openchange's mapi support on evolution, I can email others with a different mail server than mine (if mine is x@a.com, they would be y@b.com) I cannot email others on my own email server (y@a.com). This issue is also logged on the openchange bug list, but may be with the plugin and not the openchange libraries. http://trac.openchange.org/ticket/125 Steps to reproduce: 1. Send email to someone with same email server *@myserver.com 2. Receive email from mailserver stating " The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address." Actual results: Expected results: Does this happen every time? Yes. Other information: Evolution 2.25.5 Evolution-data-server 2.25.5 Samba4 cvs 12/20/2009 OpenChange cvs 12/20/2009
Please start evolution on the console and look for any interesting messages printed. That would help with debugging the issue.
This is the output while sending a letter to someone on my server: exchange-mapi-connection.c(1952): Entering exchange_mapi_create_item libexchangemapi-Message: exchange-mapi-connection.c(1954): exchange_mapi_create_item: lock(connect_lock) exchange-mapi-connection.c(808): Entering exchange_mapi_util_modify_recipients exchange-mapi-connection.c(879): Leaving exchange_mapi_util_modify_recipients libexchangemapi-Message: exchange-mapi-connection.c(2064): exchange_mapi_create_item: unlock(connect_lock) exchange-mapi-connection.c(2066): Leaving exchange_mapi_create_item
Upgraded to evolution (and eds) 2.25.90 and evolution-mapi 2.25.90, and the issue is still present. Still using Samba4-alpha6 and openchange 0.8
I have now tested sending emails using openchangeclient, I created a profile using mapiprofile, then sent an email using openchangeclient, and the "System Administrator" returned: The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address. Even though I emailed myself, and the email correctly bounced back to my account. ###My setup below for openchange #Create local profile for connecting to server mkdir ~/.openchange mapiprofile --database=$HOME/.openchange/profiles.ldb --profile=my_profile --username=my_username --password=secret --language=0x040C --address=mailhost_ip --workstation=LOCALHOST --domain=the_domain --create #use openchange to send mapi email openchangeclient -S --to=me@server.com --subject="test openchange sendmail" --body="test body" --profile=my_profile I get MAPI SUCCESS on the send, but it still bounces on the exchange 2003 server. All of the read access using evolution-mapi works, calendars, inbox, sending emails to those outside of the company...
bug 572000 is a duplicate of this one I just tested again, I was trying to BCC all mail to myself, as my "sent items" weren't being updated from evolution MAPI client, so even outbound external mail was failing. After removing the BCC, only internal mail now fails. I am using: Evolution 2.24.1.1 on openSUSE 11.1 (i586), with evolution-mapi-lang-0.25.90-1.1 and evolution-mapi-debuginfo-0.25.90-1.1 installed from repository: http://download.opensuse.org/repositories/GNOME:/Evolution:/mapi/ also from same place: openchange-0.8-3.1 (also installed are the following samba-related packages: samba-winbind-3.2.6-0.3.1; samba-client-3.2.6-0.3.1; yast2-samba-server-2.17.6-1.2; yast2-samba-client-2.17.11-1.30; samba-4.0.0-2.1 Here is the terminal output from my attempts to send mail to addresses on the same server(domain) as myself. ------------------------------------------- exchange-mapi-connection.c(1952): Entering exchange_mapi_create_item libexchangemapi-Message: exchange-mapi-connection.c(1954): exchange_mapi_create_item: lock(connect_lock) exchange-mapi-connection.c(808): Entering exchange_mapi_util_modify_recipients ModifyRecpients : MAPI_E_CALL_FAILED (0x80004005) exchange-mapi-connection.c(879): Leaving exchange_mapi_util_modify_recipients SubmitMessage : ecInvalidRecips (0x467) libexchangemapi-Message: exchange-mapi-connection.c(2064): exchange_mapi_create_item: unlock(connect_lock) exchange-mapi-connection.c(2066): Leaving exchange_mapi_create_item ------------------------------------------- Steps to reproduce: 1. Create new mail to same (own) domain 2. Reply to email in same (own) domain 3. Forward email to same (own) domain Actual results: Evolution pops up an error window, which states "Error while performing operation. Could not send message." Expected results: Does this happen every time? Almost every time
*** Bug 572000 has been marked as a duplicate of this bug. ***
Mathew & Andrew : When exchange server is not able to deliver a message, in the bounce mail there would be section "Diagnostic information for administrators" . Would be good to have that information here.
In the bounced email I receive, it states::: The following recipient(s) could not be reached: <User Name> on 1/1/2009 1:00 AM The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address. <mail.servername.com #5.1.1> Also, we do have a server front-end that bounces sent emails, but I have tested against both the front-end address as well as the back-end address. Will keep trying.
I have the same problem, but I noticed that even in message preview, there is wrong format of email address. I came to conclusion, that this wrong email address is taken/completed from one of my AddressBook of Exchange. In my addressbok there are three contact lists and each contact is without email address. There are only basic information such Name,Surname. The GAL doesn't work.
I have the same problem on Ubuntu. It only grabs part of it and I believe you're right that it's probably because GAL is not working.
(In reply to comment #9) > I have the same problem, but I noticed that even in message preview, there is > wrong format of email address. Can you please paste the wrong format it evolution is using? Thanks.
Created attachment 135328 [details] The output message from exchange The result from exchange when attempting to send email to myself.
I'm using the trunk version of evolution-mapi.
*** Bug 583334 has been marked as a duplicate of this bug. ***
I've been able to reproduce this on the following setup : E2K3 Setup with few E2K7 servers: - Mails from E2K7 -> E2K7 : Works. - Mails from E2K7 -> E2K3 : Fails with a NDR . 5.1.1
*** Bug 578905 has been marked as a duplicate of this bug. ***
I'd need further information to find the bug origin. You'll find below a set of questions that should help me figuring out the issue: 1. Is the x.y@server.com email you are using exists? I mean, can you use it in Outlook when composing new emails and does openchangeclient --fetchmail display the same To or Cc recipients? 2. is x.y your logon name (pre-Windows 2000)? 3. Does x.y differs from the SMTP email Exchange uses for you? 3. Does it work if you use x.y instead of x.y@server.com? 4. Is x.y an alias?
1. openchange --fetchmail : works great, I can read all emails. The To and Cc Recipients are always the GAL names (Bob Tyler, not b.tyler@a.com). 2. I use my login as my --username=. I get MAPI_E_LOGON_FAILED if I use my email alias as my --username. 3. No combination of email address names work, tried my full name, the fullish name that the Gal failure shows (Matt instead of Matthew), my email address, my email name (no server), and a full server name address ( @a.b.c.com instead of @a.com ). 4. Yes
Regarding statement 3, could you lookup the SMTP address stored in your profile database and tells me whether it differs or not from your previous tests? If you have not been trying it, can you tell me using it makes things better? I'm btw assuming here you can't send mail to yourself within Exchange organization. For example here: $ ldbedit -H ~/.evolution/mapi-profiles.ldb Search ProxyAddress ProxyAddress: X400:c=US;a= ;p=First Organizati;o=Exchange;s=Kerihuel;g=Julien; ProxyAddress: SMTP:jkerihuel@openchange2003.local If I specify either jkerihuel or the SMTP email 'jkerihuel@openchange2003.local' it works. Finally, could you provide me the log associated to similar command: $ openchangeclient --database=$HOME/.evolution/mapi-profiles.ldb --sendmail --to='jkerihuel' --subject=test --body='sample test' --dump-data -d10 Replace to with your name attempts. I only need the in/out data from NspiResolveNames and ModifyRecipients calls. Cheers, Julien.
Created attachment 135535 [details] --dump-data -d10 logs
Tried sending mails from Outlook 2007. From account@ex2007.com to account@ex2003.com. Mail got delivered properly.
Re assigning to Julien (as he asked :) )
Regarding attachment http://bugzilla.gnome.org/attachment.cgi?id=135535 NspiResolveNames works properly and gives expected output. The problem potentially comes from a bug or uncovered case in the ModifyRecipients recipient/bitmask algorithm. I'll review the code and try to figure out whether we have an incorrect mapping or not (wrong/missing property associated to a particular bit etc.) In the meantime if someone could provide me (additionally to the --dump-data -d10 log) either a wireshark capture of Outlook doing + sending Exchange or even better a mapiproxy network dump, that would really be helpful.
Created attachment 135749 [details] Debug & Analysis Debug & Analysis: * When sender and recipient are in the same administrative group: * openchangeclient CLI sending succeeds however evolution-mapi client fails with NDR. * When sender and recipient are in different administrative groups: * openchangeclient CLI and evolution-mapi client both fail with NDR. See Debug & Analysis attachment for CLI debug logs and additional information.
At last I sat to debuging. I suspect that problem with address can be in handling with email-address from mapi profile file. I was testing with openchangeclient. ldbedit shows following email address:: EmailAddress: /o=XnY Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDL T)/cn=Recipients/cn=zimen I see a relation between this "zimen" from profile and "zimen" error email message from exchange where "zimen" is also user as "unknown user". However recipient entry must be in form of michal.zimen@ and not only zimen@. During the testing, I changed this EmailAddress to ...cn=michal.zimen. Then the openchangeclient's output was: EcDoConnect : ecUnknownUser (0x3EB) MapiLogonEx : MAPI_E_LOGON_FAILED (0x80040111) Where the email address of recipient is constructed? --output from exchange 2007-- Diagnostic information for administrators: Generating server: skhub02.xny-is.com IMCEAEX-_O=XNY+20EXCHANGE_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIEzimen@xny-is.com #550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ## Original message headers: Received: from skmail.xny-is.com ([10.203.32.37]) by skhub02 ([10.203.32.46]) with mapi; Fri, 12 Jun 2009 09:23:25 +0200 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary From: Zimen Michal <Michal.Zimen@xny.sk> To: zimen <IMCEAEX-_O=XNY+20EXCHANGE_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIEzimen@xny-is.com> Date: Fri, 12 Jun 2009 09:23:24 +0200 Subject: zimen Thread-Topic: zimen Thread-Index: AcnrLqxVX3+pNfKwT/+/l04YxfNPLQ== Message-ID: <59170B679ABAB348A5E0387F4D84C5B101F8E3222A@SKMAIL.xny-is.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <59170B679ABAB348A5E0387F4D84C5B101F8E3222A@SKMAIL.snt-is.com> MIME-Version: 1.0
That makes sens to me, as my email address is name.surname@host.domain .. as are all the other email addresses on the exchange server that I use. Thanks.
Hi Julien, Any updates on this? Thanks.
*** Bug 591314 has been marked as a duplicate of this bug. ***
*** Bug 592059 has been marked as a duplicate of this bug. ***
I have verified that the current evolution-mapi-0.28.1 source compiled for use on Ubuntu 9.10 has the same issue. The name lookup appears to use non-prefixed user names (stripping the domain prefix) instead of just keeping the same name as typed. It would be interesting to see if there is a way to not do name lookups on the same domain and send the name as is to the exchange server. Names such as: first.last@domain.com Get translated to: username@domain.com For instance my email on the company domain is: mark.morris@domain.com And when I send email to myself, the MAPI client translates this email address to: mmorris@domain.com (even though my domain account is north\mmorris) There is some type of lookup happening. I have checked the message source from other messages that I receive from the same domain, and the usernames are not translated. If there is a lookup, maybe there needs to be a configuration to turn off name lookups on the same domain.
Bharath : Ping.
While I can send to some ppl in my org...I cannot to some others. I get an NDR back saying email address does not exist. Is this fixed in the new mapi version?
Created attachment 148155 [details] [review] Evolution MAPI patch Setting a LegacyExchangeDN for the mailboxes not residing on the same server but part of the same cluster setup helps fix the issue, but the server administrators would need to run the script for all mailboxes. When sending a mail, as per the docs it is up to the client to act as a message transfer agent and deliver the message using an alternate transport. So I guess it should also be fixed if we have a X400 type address handling. But this small change fixes the issue for me by handling all the recipients as unresolved and using SMTP instead of EX. There may be some side-effects because of this change, but nothing that I can see. Let me know if it has any serious implications.
Hi, Thank you for your reply. Does the Evolution MAPI patch need to be run on my fedora box or the MS exchange server? If it needs to be run on the server, I have already been said NO! Any server side changes is unlikely. Anything that can be done on the client side? (on my fedora box). Also, is this bug fixed on the latest F12 release (uses Gnome 2.28 i believe). Thanks
I can confirm this patch fixes the issue on Evolution 2.28.0 on Fedora 12
Ok thanks. How do you apply this patch? Is there somewhere you can point me too. THis would be extremely helpful for me!
I can also confirm that applying the patch to the evolution-mapi-0,28.1 source directly and then building the source (i.e. "./configure", "make", "sudo make install") fixes the issue on Ubuntu 9.10. Mail can now be sent directly to users on the same domain.
Hello This patch work to send email in the domain. As it was not include in the 0.28.1 release i did patch and it is working fine now Thx.
And news when will this patch be available in Fedora 12 updates-testing repo?
Comment on attachment 148155 [details] [review] Evolution MAPI patch Committed to master http://bit.ly/6RKcGe Committed to gnome-2-28 branch http://bit.ly/90nFQL Well this is the best we have right now. Lets have this workaround until we have a better solution in the openchange side. Keeping the bug open.
Does it make any sense to have this bug opened when the right fix will be done in openchange, which has its own bug tracker? (In reply to comment #39) > And news when will this patch be available in Fedora 12 updates-testing repo? It will be part of 0.28.2 which is supposed to be released next week.
Since it is fixed in evolution-mapi and works well, lets close it then. Once the openchange ticket has a patch, I'll look at the evolution-mapi side of it. Kindly reopen if anyone sees any regressions.
I can just confirm that with evolution-mapi-2.28.1 this bug is still present, at least in Fedora 12 :(
(In reply to comment #43) > I can just confirm that with evolution-mapi-2.28.1 this bug is still present, > at least in Fedora 12 :( That's expected. The fix wasn't committed until after that release.
This is now working in Evolution 2.28.2 Thanks! ps. I still can't use Evolution because I found out that it messes international UTF-8 characters when sending email and doesn't send attachements :(