For MUAs operating on an offlineimap/isync/fetchmail imap-synced copy of mails it might be nice if py-autocrypt could create and maintain a parallel directory structure with all mails in the clear (and put that into notmuch, for example, to get full fast search on all mail). For those of us who mainly use a laptop to read e-mail (and only rarely use webmail or mobile apps) it might be nice then to automatically delete mails that are older than N days in the local IMAP folder, which then would also be removed from the server-side IMAP folders. The parallel cleartext-directory would not be affected, i.e. deletes do not propagate from IMAP to the parallel folder.
This would then also more easily allow to change and eventually forget an old secret key -- deletable mail ("Forward security") as all collected mail-in-transit copies would then become unreadable if the secret is gone.
right now, muacrypt is used in one-shot mode and it's unclear if the functionality suggested here should rather make use of it, rather than its implementation be contained here.
For MUAs operating on an offlineimap/isync/fetchmail imap-synced copy of mails it might be nice if py-autocrypt could create and maintain a parallel directory structure with all mails in the clear (and put that into notmuch, for example, to get full fast search on all mail). For those of us who mainly use a laptop to read e-mail (and only rarely use webmail or mobile apps) it might be nice then to automatically delete mails that are older than N days in the local IMAP folder, which then would also be removed from the server-side IMAP folders. The parallel cleartext-directory would not be affected, i.e. deletes do not propagate from IMAP to the parallel folder.
This would then also more easily allow to change and eventually forget an old secret key -- deletable mail ("Forward security") as all collected mail-in-transit copies would then become unreadable if the secret is gone.
right now, muacrypt is used in one-shot mode and it's unclear if the functionality suggested here should rather make use of it, rather than its implementation be contained here.