Feature / new action export_mailbox to mbox

[aheissenberger]

Use Case Backup existing E-Mails including attachments.

• for each mailbox create a folder structure which is based on the IMAP folder structure
• store all per rules selected email including attachments into on file in mbox format
• supports all existing rules
• can be combined with all existing actions: delete, remove_attachment, save_attachments

roadmap

• [ ] append emails to existing mbox files if message id is new - this would allow to resume a download which has been killed by a connection problem
• [ ] define a different folder for the export (currently shared with save_attachments)
• [ ] allow to install with homebrew

[axllent]

Hi @aheissenberger - firstly thanks again for your contributions, it's great to have others that are not just using my tools, but also contributing back!

Now about this export to mbox functionality (your merge request)... I'm not seeing the link between imap-scrub and "imap-export", as I think that it serves a completely different purposes. Not only that, but I see a whole lot of potential for what you are trying to do (and that there are many, many more changes to come!), all of it having nothing to do with the goal of imap-scrub (cleaning one's emails, reducing mailbox size).

So I propose that you actually start a completely new/separate project for this instead, for example imap-export. You can of course copy the parts of mine that are applicable to yours.

I have a few big ideas for yours too, ones that I have been thinking about for quite a while but have never gotten around to do (because I can't find the time) - basically an IMAP backup and restore tool. There are many online, but most I have found are commercial or don't support linux, and the others suck. I have been using gmvault for quite a while now, but I have to run it inside a docker container because it requires a whole bunch of specific python stuff and I got nothing but conflicts on my system when I started it. The concept however is good - although not limited to just Gmail of course but rather any IMAP server. Each message is stored as a separate compressed file (although you could have options for this if you preferred it in mbox format or something). Of course Gmail can include the same message in multiple folders (labels) which would mean duplicate messages, so there would be some interesting challenges (or sacrifices ~ keeping multiple copies of the same message).

I would use such a tool for:

• backups
• restoration
• transfer of data from one account to another (eg: adding the backed-up messages to an existing IMAP account)
• it could optionally be limited to a single folder (eg: just to back up just the "All Mail" folder), or all of them, or a list of folders

So what do you think? You clearly have some ideas already, and I really believe you should make this a new project of your own ;-)

[aheissenberger]

I do understand the purpose of the tool and love it that you want it to be single focused, but for me I used this option to backup the mails before they get modified (e.g. scrubbed from attachment) by this tool. It made me feel better in the case something went wrong.

I also like the ideas you had for creating a tool to backup and migrate IMAP servers but I currently have no time and no need to take on such a project. Do not expect the ideas I wrote about to be happen any soon as I there are no use cases for them on my side.

I still would appreciate your feedback on my changes even and have no problem if you decide to not include them in your repository. My golang skills are so rudimentary that you would do me a great favour to point out any problems my code could produce.

Thanks Andreas :-)

[axllent]

Although I won't merge this into my codebase, I think what you have written makes sense, straightforward and easy to read (good job!). If this suits your situation, then you should continue to use your fork so you at least have the export capability you need.

I definitely wouldn't want to be overwriting an entire export every time though, but rather append new messages to that instead. That however introduces the another level of complication whereby you are more-or-less syncing with an existing mailbox (if it exists). Also for future reference, don't include things like .vscode/launch.json in your repo and/or pull requests ;-)