1428825 - delete mail from imap fails - "The current operation on 'Inbox' did not succeed. The mail server for account xxx responded: Permission denied."

Status: REOPENED

Description

[moby]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180103230655

Steps to reproduce:

Go into any imap email account in Thunderbird 58.0b3 and try to delete an email.


Actual results:

You get an error message that permission was denied.


Expected results:

The email should have been deleted.

Comment 1

[Wayne Mery (:wsmwk)]

(Priority is for developers)

a) please provide the exact text that you see for the error
b) Does the problem reproduce in safe mode? https://support.mozilla.org/en-US/kb/safe-mode-thunderbird
c) if it does reproduce in safe mode please check tools > error console for relevant information and post it here

Please provide both bits. Thanks.

Comment 2

[moby]

Thanks Wayne.

a) The message pops up in a window in the system tray (I am running on Windows XP). The exact text is "The current operation on 'Inbox' did not succeed. The mail server for account xxx responded: Permission denied."  This is when attempting to delete an email in Inbox, and xxx is the account name. Same problem occurs in any other folder. 

b) Problem exists in safe mode as well.

c)Nothing shows up in the error console.

The problem is no with permissions or the imap server etc since other versions of Thunderbird (and other imap clients) work just fine.

Comment 3

[moby]

Following shows up in the error console right after I clicked save on the previous comment:

2018-01-13 12:04:16	autosyncActivities	ERROR	OnDownloadError: Suse of [e-mail]

  log4moz.js:685
2018-01-13 12:04:16	autosyncActivities	ERROR	OnDownloadError: Suse of [e-mail]


2018-01-13 12:04:17	autosyncActivities	ERROR	OnDownloadError: Suse of [e-mail]

  log4moz.js:685
2018-01-13 12:04:17	autosyncActivities	ERROR	OnDownloadError: Suse of [e-mail]


[e-mail] is the account name in this case.

Comment 4

[moby]

Just found out that doing a shift-delete (immediate delete) works and does not produce the error message. The "normal" delete that is failing is configured to move the message to the Trash folder (Also on the imap server).

Comment 5

[moby]

Some more data:

Looks like the whole imap mail deletion business is messed up in 58.0b3.

The account is using a Cyrus IMAP server backend. Under "Server Settings" for the account, under "Advanced", personal namespace is set to "INBOX.". Under "When I delete a message",I have "Move it to this folder" but no folder is listed, the folder name indicates "Choose Folder". This setup works fine with Thunderbird 58.0b2. Deleted messages get moved in to a folder called Trash correctly. Looking in the server logs, I can see TB copying the message to Inbox.Trash and then deleting it.

Exactly the same upgrade as above, when upgraded to 58.0b3, results in message deletion prompting a response of permission denied from the server. Looking in the server logs, I see that TB tried copying the message to Trash, instead of Inbox.Trash.

I reconfigured the account settings in TB 58.0b3 and explicitly choose the folder Trash (in my namespace) as the folder to move the message to upon deletion. Now, when I delete a message, the message disappears with no errors. Looking at the server logs I see that TB delete the message instead of copying it to the chosen folder.

This is a bit scary that configuring a folder to move deleted messages to instead results in immediate deletion of the messages. Looks like more than one bug in handling of message deletion in 58.0b3.

Comment 6

[moby]

Nothing thus far? Was it something I said?! :)

Comment 7

[Wayne Mery (:wsmwk)]

(priority field is reserved for developer use)

Perhaps one of the people I have cc can assist you.

Comment 8

[moby]

Thanks Mery. I am not asking for assistance, just trying to report what appears to be a serious bug in the current beta. The release versions of TB are working fine, I just thought the developers would be interested in knowing about bugs in the beta, especially bugs as serious as this one.

Comment 9

[Wayne Mery (:wsmwk)]

moby, Do you still see this with the newest beta 60.0b8?

Comment 10

[moby]

The bug is fixed in 60.0b8. I tried it just now and delete works just fine. Thanks.

Comment 11

[Phoenix]

Resolved per whiteboard and Comment 10

Comment 12

[ElDiablo]

After an update from 52.9.1 to 60.3.0, we ran into the same bug, on three different computers.
We are in exactly the same configuration than Moby (Comment 5).

mail.server.server1.trash_folder_name was not set before the upgrade.
Setting manually the destination folder to "INBOX/Trash" fixes the problem.