Hide Forgot
Description of problem: If the recipient is in the GAL, the mail always stays in the outbox and will not be sent. If the recipient is not in the GAL (out of the organization), the mail can be sent successfully. Version-Release number of selected component (if applicable): evolution.i686 2.32.2-1.fc14 @updates evolution-data-server.i686 2.32.2-1.fc14 @updates evolution-help.noarch 2.32.2-1.fc14 @updates evolution-mapi.i686 0.32.2-1.fc14 @updates openchange.i686 0.9-11.fc14 @updates How reproducible: Always Steps to Reproduce: 1.compose a new mail 2.select a recipient in GAL, or just write the email address (a@b) 3.send the new mail Actual results: The new mail stays in the outbox of the computer. A messagebox says "ModifyRecipients：发生了 MAPI 错误 MAPI_E_CALL_FAILED (0x80004005)" The following message is on the terminal console: ** (evolution:7807): DEBUG: Loading Exchange MAPI Plugin ** (evolution:7807): DEBUG: MAPI listener is constructed with 1 listed MAPI accounts (evolution:7807): libexchangemapi-CRITICAL **: make_mapi_error: assertion `*perror == NULL' failed (evolution:7807): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: 无法发送消息。 Expected results: The new mail should be sent. Additional info:
Good, thanks (we moved here from bug #674034). Could you get a log what is evolution-mapi trying to do, please? You can get such log by running evolution like this: $ MAPI_DEBUG=10 evolution &>log.txt Reproduce the issue, close evolution, and the log.txt will contain pretty chatty, aka detailed, information what was moving between client and the MAPI server. Please make sure you'll not expose any private information, like passwords, server names/addresses and user emails. I suggest to skip most of the beginning of the log and paste here only values after ModifyRecipients call (search for that name). It can be there multiple times, but only the last should be the one used when sending the message. Please keep the log in case more information from it will be needed. Thanks in advance.
I've a wild idea, is it possible this was caused by the openchange update? In other words, if you downgrade openchange to the previous version, will you be able to send messages?
Created attachment 486044 [details] The error log of the bug
The log is attached. Also I had downgraded openchange to the previous version, but the mail can not be sent. Thanks in advance.
Thanks for the update. The good thing is that you see the same behaviour with older version too, which means nothing from the update broke this. (I suppose it fails with similar error.) I see in the log these warnings: > ndr_push_error(2): Bad switch value 0 at gen_ndr/ndr_exchange.c:37218 > Unable to ndr_push structure in dcerpc_ndr_request_send - > NT_STATUS_INVALID_PARAMETER which I suppose have something to do with us. The server resolved recipient's address with unicode letters, which may or may not be related.
Did you have any progress?
Ah, I'm sorry, I do not as of now. I expect this being part of openchange, and I didn't find time to search its sources for possible fix(es).
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping