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 740627 - [IMAPx] Cannot append to a write-only folder
[IMAPx] Cannot append to a write-only folder
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.12.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-11-24 14:36 UTC by Kai Engert
Modified: 2016-05-11 14:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed eds patch (853 bytes, patch)
2014-11-25 13:47 UTC, Milan Crha
none Details | Review
proposed eds patch ][ (1.69 KB, patch)
2014-11-25 15:29 UTC, Milan Crha
none Details | Review

Description Kai Engert 2014-11-24 14:36:46 UTC
It's impossible to move a message to an IMAP folder that's write-only.

Inspecting the CAMEL_DEBUG=imapx log, one can see that evolution attempts to "select" the target folder, and gets a permission denied.

Then evolution apparently gives up.

This is a regression, it worked correctly with evolution 3.10.
(It also works with Thunderbird 31. This shows it isn't a server issue.)

FYI, the purpose is using a spam filtering provider, which uses write-only IMAP folders for spam classification.
Comment 1 Milan Crha 2014-11-25 13:47:23 UTC
Created attachment 291458 [details] [review]
proposed eds patch

for evolution-data-server;

This should fix it. It doesn't do anything inventive, trying to check folder permissions and react appropriately seemed to me as an unnecessary overhead, thus I let the SELECT eventually fail, but ignore the error and continue with the APPEND command. If there is something really wrong (like the folder couldn't be even writable), then the APPEND should fail in a similar way as the SELECT.

I do not have any server with a write-only folder, thus I'd like to ask you to test the patch. To make it easier for you, I built a test package for Fedora 21 with the patch included:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=8228124

Let me know whether it works, please.
Comment 2 Milan Crha 2014-11-25 15:29:35 UTC
Created attachment 291469 [details] [review]
proposed eds patch ][

for evolution-data-server;

After a live test, the first patch is not enough. I made more changes around this, though I'm still not sure whether it'll be sufficient. I'm not so happy with these changes, but I do not have anything better right now too.
Comment 3 Milan Crha 2014-11-25 16:40:51 UTC
I setup a write-only folder on my cyrus account with your help and then I made the changes finally work. it makes the patch slightly more complicated.

Created commit ab8756d in eds master (3.13.9+) [1]
Created commit 86fb887 in eds evolution-data-server-3-12 (3.12.9+)

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=ab8756d
Comment 4 Kai Engert 2014-11-25 17:09:22 UTC
The patch works for me, for one of the scenarios (move false negative spam that went through, from my server, to the target server).

(No endless loop, as I saw with one of the intermediate patches!)

I couldn't yet test the other scenario (release a false positive), because I rarely see them (only once every few days).

I'll let you know when I was able to test the second scenario.

So far, thanks a lot for the fix!
Comment 5 Kai Engert 2014-11-26 12:40:16 UTC
(In reply to comment #4)
> I couldn't yet test the other scenario (release a false positive), because I
> rarely see them (only once every few days).
> 
> I'll let you know when I was able to test the second scenario.

I confirm that works, too (moving within one server to a readonly folder).
Thanks again
Comment 6 Milan Crha 2016-05-11 14:58:02 UTC
As we spoke downstream at [1], there is an issue in 3.18.x+ that the second attempt to move a message to that write-only folder fails with an error
"No mailbox selected". I realized it was caused by the internal IMAPx state not being properly updated when the SELECT command fails, it thought the previously selected mailbox is still selected, but it wasn't.

Created commit 1007998 in eds master (3.21.2+)
Created commit d6a1304 in eds gnome-3-20 (3.20.3+)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1331751