|Summary:||Use SetProps if write property as stream failed|
|Product:||[Fedora] Fedora||Reporter:||Canyon Bliss <canyon>|
|Component:||evolution-mapi||Assignee:||Matthew Barnes <mbarnes>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-07-10 16:29:29 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Canyon Bliss 2012-06-25 18:34:12 UTC
Description of problem: When I attempt to send mail to certain people, I receive this error "Could not send message: OpenStream: Permission denied". Version-Release number of selected component (if applicable): evolution-mapi-3.4.3-1.fc17 How reproducible: Every time. Steps to Reproduce: 1. Write or reply to an email. 2. Send email. 3. Actual results: "Could not send message: OpenStream: Permission denied". Expected results: Email is sent. Additional info: Before I updated to evolution-mapi-3.4.3-1, I was receiving a different error described in bug827371 (https://bugzilla.redhat.com/show_bug.cgi?id=827371) . Consequently, it's the same situation (email recipients) but I do not see the error NT_STATUS_BUFFER_TOO_SMALL in the log with evolution-mapi-3.4.3-1.
Comment 1 Milan Crha 2012-06-26 07:31:43 UTC
Thanks for a bug report. I suppose you use 3.4.3-2 now, with patch from bug #827371, am I right? Could you provide part of the LIBMAPI_DEBUG=15 evolution &>log.txt log, around this OpenStream request, please? There are basically two reasons for the OpenStream call, either some property is too large, thus it can be uploaded only as a stream, or there is an attachment in the message. I would like to know what case is this (sending with 3.4.3-2 works fine for me, I tested it with smaller messages).
Comment 2 Canyon Bliss 2012-06-26 14:16:41 UTC
Created attachment 594494 [details] LIBMAPI_DEBUG=15 evolution log around OpenStream Debug log as requested in comment#1. The email addresses are changed but still have the same number of characters.
Comment 3 Milan Crha 2012-06-27 14:08:39 UTC
Aha, interesting. It's trying to write PidTagInternetReferences as stream, which seems to be worthless, because this particular property is rather short. Would you mind to send me the message you are trying to send to myself, as an attachment, please? I'll try to reproduce with it here and hopefully figure out which of the reasons (from comment #1) is the issue here. On the first look, the code should have precedence to save PidTagBody as stream, rather than any other string property.
Comment 4 Canyon Bliss 2012-06-27 15:13:45 UTC
(In reply to comment #3) > Aha, interesting. It's trying to write PidTagInternetReferences as stream, > which seems to be worthless, because this particular property is rather > short. > > Would you mind to send me the message you are trying to send to myself, as > an attachment, please? I'll try to reproduce with it here and hopefully > figure out which of the reasons (from comment #1) is the issue here. > > On the first look, the code should have precedence to save PidTagBody as > stream, rather than any other string property. I sent you the email as an attachment. The attached email (from comment #1) is not very long and has no attachments. It does however, have very long HTML lines.
Comment 5 Milan Crha 2012-06-28 07:25:48 UTC
Thanks for the email. I appreciate it and I fully annonimized it before I start playing with it. On the first look, the problem is with the PidTagInternetReferences property, which corresponds to References header in the email. If you view source of the message you can see that the References header is longer than message text itself :) I can reproduce the error with your message on my machine and with my server too.
Comment 6 Milan Crha 2012-06-28 09:27:24 UTC
OK, I've a fix for this, which is currently building. I thought that the exchange server can write any property as stream, but it seems it cannot, thus the patch fallbacks to SetProps if OpenStream fails for the given property. The fix is committed for 3.5.4 and 3.4.4 of evolution-mapi.
Comment 7 Fedora Update System 2012-06-28 09:37:29 UTC
evolution-mapi-3.4.3-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2012-9952/evolution-mapi-3.4.3-3.fc17
Comment 8 Canyon Bliss 2012-06-28 14:28:13 UTC
(In reply to comment #6) > OK, I've a fix for this, which is currently building. I thought that the > exchange server can write any property as stream, but it seems it cannot, > thus the patch fallbacks to SetProps if OpenStream fails for the given > property. The fix is committed for 3.5.4 and 3.4.4 of evolution-mapi. I was able to send the email after I updated to evolution-mapi-3.4.3-3.fc17 .
Comment 9 Milan Crha 2012-06-28 17:07:33 UTC
Good. Thanks for testing it.
Comment 10 Fedora Update System 2012-06-29 09:54:25 UTC
evolution-mapi-3.4.3-5.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2012-9952/evolution-mapi-3.4.3-5.fc17
Comment 11 Fedora Update System 2012-06-30 21:49:38 UTC
Package evolution-mapi-3.4.3-5.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing evolution-mapi-3.4.3-5.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9952/evolution-mapi-3.4.3-5.fc17 then log in and leave karma (feedback).
Comment 12 Fedora Update System 2012-07-10 16:29:29 UTC
evolution-mapi-3.4.3-5.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.