Delete no longer Purging from the Server

Long time user of K9 on Android Phone and Tablet using IMAP without issues. Currently running latest version 6.8 from Google Play.

A recent version has changed the behaviour of deleted emails on the server - they now remain in the Inbox and show as “marked as ‘to be deleted’ by an IMAP mail client.” and a copy is (correctly) placed in the Deleted Items folder. No changes have been made to the client settings for years! Same behaviour on tablet (Android 14) and phone (Android 12).

K9 Account Fetching mail Settings:
When I delete a message = Delete from Server
Erase deleted messages on server = Immediately
Sync server deletions = true
Mark as read when deleted = true

Is there a new setting I have to set in the new version, or is this a bug?

Help appreciated!

I just checked the webmail account where I deleted an email through my phone earlier and that email (along with others I previoulsy deleted) is in the Trash where it belongs.

I’m also on the latest version, 6.801 to be exact, using a Oneplus 9 Pro with an A14 custom rom. I didn’t change any settings with any of the recent updates.

Is it possible that your email provider changed something or has an issue with cache etc right now?

Unfortunately, no chance that the server has changed. I run my own dedicated email server and the software company that produced the software no longer exist :frowning: !

I tested with MS Outlook from a Windows PC (talks to the server via IMAP) and that still works correctly

If I delete an email from my Inbox in K9, it correctly creates a copy in the Trash folder (appears there in both the Android and the Server). The email disappears from the Inbox view in K9, but shows as still present on the Web Interface, struck through and marked as to be deleted.

I am not an Android developer, but if there are previous version APKs available somewhere, I can try back versions and see if the problem persists and identify which version introduced the issue?

Thanks for the help!

Previous releases can be found here:

The change was introduced in version 6.703. Version 6.702 deleted correctly.

I have not tried any more pre-release versions after this, but I presume I went from 6.603 straight to 6.8 via Google Play.

I hope this helps someone track down the bug. Many thanks to those who give their time to write and support this app!

Yes, there might be a change in K9 which caused this. But it seems to work for others so no general issue.

Also you write

And

So it might be that your mail server software is outdated and does not react properly to marking mails to be deleted.

But - I am not a developer of K9, cannot tell…

1 Like

Thanks for your time to reply, I had joined those dots!

As I have no software support available for the server and can pinpoint the client change causing the issue, I really hope one of the developers could revert/adapt the change in 6.703.

My only other option is to switch clients - a new email system is non-trivial, albeit ultimately inevitable! K9 has worked reliably against my platform for over a decade prior to this change…

It doesn’t look like anything related to IMAP has been changed between K-9 Mail 6.702 and 6.703. See Comparing 6.702...6.703 · thunderbird/thunderbird-android · GitHub

To get an idea what is going on at the protocol level, please record a debug log while trying to delete a message. See LoggingErrors · thunderbird/thunderbird-android Wiki · GitHub

1 Like

Apologies - I detailed the incorrect version numbers. The first affected version is 6.712 and 6.711 works OK. I suspect that ‘Added support for the IMAP MOVE extension’ is the root cause and my server software does not support the new method. Not a bug in k9 therefore, but a server platform incompatibility that has been introduced.

I have created debug logs for version 6.711 (showing it working) and 7.712 (not) and added them to ticket 7721. Would be very grateful if there was a way to test for server support for the new method and to use the legacy method if not.

@cketti : Many Thanks for version 6.802. Issue resolved. Very Happy!