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

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: IMAP, defect)

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.

Comment 13

[sir.luislara]

same issue here Linux Centos7 60.8.0 (64-bit)

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to sir.luislara from comment #13)

same issue here Linux Centos7 60.8.0 (64-bit)

Do you still see this when using version 68?

Comment 15

[Wayne Mery (:wsmwk)]

Gene, ever see what is described in comment 5 ?

Comment 16

[gene smith]

Would need to see the imap log for myself to understand what is going on. For one thing, "deleting" a message doesn't literally delete it but instead marks it with a \deleted flag. So until the folder is expunged (compacted) the message is still there and can be "undeleted" by setting delete method to "just mark it as deleted" and right-click undeleting any marked out messages.
Also, depending on the server, the "trash" folder may not "list" as having the "Trash" special attribute and the user will need to select a trash destination. This is true when the destination shows "choose folder".
Again, would need to see a log and discuss with user as to why they see a permission denied and other problems.

Comment 17

[Phoenix]

Resolved per whiteboard
Feel free to reopen if you'll get the data