IMAP delete email not working on iPadOS

Hi Pankti, Thanks for investigating. I've done more testing, and the failure follows how this server's folders are flagged, not my credentials or access. 1) Second account on another host (Simply.com): delete works. Its folders all have SPECIAL-USE flags and no namespace prefix: * LIST (\HasNoChildren \UnMarked \Trash) "." Trash * LIST (\HasNoChildren \UnMarked \Archive) "." Archive * LIST (\HasNoChildren \UnMarked \Sent) "." Sent * LIST (\HasNoChildren \UnMarked \Drafts) "." Drafts * LIST (\HasNoChildren \UnMarked \Junk) "." Spam 2) The one.com account (Dovecot, prefix "INBOX.", separator ".") only has a flag on Junk: * LIST (\HasNoChildren \UnMarked) "." "INBOX.Trash" * LIST (\HasNoChildren \UnMarked \Junk) "." "INBOX.Spam" * LIST (\HasNoChildren \UnMarked) "." "INBOX.Sent" * LIST (\HasNoChildren \UnMarked) "." "INBOX.Drafts" * LIST (\HasNoChildren \UnMarked) "." "INBOX.Archive" 3) Tests on the one.com account in Newton on iPad: - Move to Spam works (INBOX.Spam has \Junk). - Archive fails with the same "error occurred while creating the requested folder" (INBOX.Archive has no flag). - Delete fails with the same error (INBOX.Trash has no flag). So the account can log in, read and write. Only actions targeting a folder without a SPECIAL-USE flag fail. The attached screenshot shows the same thing: INBOX.Spam is mapped to Newton's built-in Spam, while INBOX.Archive, INBOX.Drafts, INBOX.Sent and INBOX.Trash are listed as plain labels under "All labels", and the built-in Archive/Sent/Drafts/Trash have no server folder behind them. 4) A failed delete creates no folder on the server (checked in webmail), which fits the server rejecting a CREATE. Could you log which folder name the app tries to create? That should show the cause directly. 5) Minor: a stray folder INBOX.INBOX.Sent (created earlier by macOS Mail, not Newton) is gone on the server but still listed in Newton. Folders deleted on the server aren't removed from Newton's list. 6) The same account works in Mail.app, Spark and Edison. To reproduce: run a Dovecot instance with `namespace inbox { prefix = INBOX. }` and no `special_use` set on Trash/Archive/Sent/Drafts. This is common on shared hosting. Suggested fix is in my feature request above: use SPECIAL-USE first, fall back to common names while respecting the namespace prefix, let users pick folders manually, and never CREATE a folder when a matching one exists or the user has chosen one. Happy to test a build with extra logging.

Hi Kristoffer, We’ve tested this issue internally, and as you mentioned, it does seem to be specific to this IMAP account. The account also doesn’t seem to be getting the required access from the server side. If you have another IMAP account, could you try adding it to Newton and see if deleting emails works there? If you get a chance to try it, let us know how it goes - it’ll help us narrow this down further.

I dug deeper with help from Claude, and it seems that it should be a feature request: Let users manually assign Trash/Sent/Drafts/Junk/Archive folders per IMAP account Summary Please add per-account "Mailbox behaviors" settings, like Mail.app, Spark and Edison have, where the user picks which server folder is used for Drafts, Sent, Junk, Trash and Archive. Auto-detection should stay the default, with manual selection as an override and fallback. Why Some IMAP servers don't advertise RFC 6154 SPECIAL-USE flags, so the app can't identify the Trash folder. My account (one.com, Dovecot, prefix "INBOX.", separator ".") is one example. LIST output: * LIST (\HasNoChildren \UnMarked) "." "INBOX.Trash" * LIST (\HasNoChildren \UnMarked \Junk) "." "INBOX.Spam" * LIST (\HasNoChildren \UnMarked) "." "INBOX.Sent" * LIST (\HasNoChildren \UnMarked) "." "INBOX.Drafts" * LIST (\HasNoChildren \UnMarked) "." "INBOX.Archive" Only Junk has a flag. The same account works in Mail.app, Spark and Edison, so the server setup is not the problem. Observed behavior (iOS/iPadOS) - Deleting a message (button or swipe) fails with: UnexpectedException: An error occurred while creating the requested folder. (at ExpoModulesCore/Promise.swift:56) - Manually using "Move" to move the same message to INBOX.Trash works. So the folder is reachable and usable; the failure is specific to the delete action, which seems to try to create a folder instead of using the existing INBOX.Trash. See my separate bug report. Suggested behavior 1. Detect folders via SPECIAL-USE flags first. 2. If a flag is missing, fall back to common names (Trash, Deleted Items, Sent, Drafts, Archive, ...), taking the namespace prefix and separator from the server (NAMESPACE / LIST) into account. 3. Let the user override each folder in account settings, and always respect that choice. 4. Never CREATE a new folder when a matching one already exists or the user has selected one. Only create a folder if none exists and none was chosen. Expected result Delete works on accounts without SPECIAL-USE flags, and users can fix wrong auto-detection themselves.

Not working on my iPhone as well. I am aware that it might be specific for my IMAP account, but I'm not able to figure out why.