I have an account on an SMTP server. The server has a storage quota. I’d like the delete stuff from the server but keep it locally in case I need it. Just in case.
I’d like to be able to access the mail somehow on other computers and hopefully mobile devices on my network so that it can be searched when needed. I’m not sure what the best interface for that would be. A webmail client?
One option would be to use Thunderbird or another client to download the mail once in a while but disable deleting local messages when they are removed from the server. Would Thunderbird store the messages in a format I can use readily with other applications? Or should I use something else to download the mail?
What about situations where messages are moved from one folder to another on the server? Would I get a duplicate locally of the message appearing in both locations? Not sure how the storage and metadata actually are.
Also, is it possible in such a situation to put a message back on the server if I realize it was deleted in error?
Any idea would be welcome. I am a bit stuck.
I can use the command line comfortably but ideally I’d have a solution that doesn’t rely on the terminal to find find messages and such. I don’t really like terminal mail clients.
I’d say run a local imap server rather than dealing with the weirdness of storage shares across multiple OS’s.
I still have every email I’ve ever received, going back now more than 20 years. My solution isn’t terribly fancy, but it gets the job done.
I have a Synology here at home running a mail server. You don’t need a Synology specifically, just a simple mail server with access to a lot of disk space. The server isn’t on the Open web or anything and doesn’t support SMTP. It’s just running IMAP to serve the local mail around the house.
I connect to it from Thunderbird on my various machines. I also use Thunderbird to connect to my actual mail servers to do my day-to-day mail stuff.
Every six months or so, I move old mail messages from my actual mail servers over to the archival one. Generally, I keep the mail on the archival server in folders; one per year, that keeps the loading time to a minimum. For example, come January 1st 2024, I’ll be moving mail from January 2023 - June 2023 to the
/2023folder on the archive.Searching is done via Thunderbird just like you search any mail account, and on my desktop machine, I let Thunderbird keep copies of the mail locally for quick searching. On my laptop though, I ask it to not keep copies to save disk space.
@danielquinn @crank That’s pretty cool. How much storage does 20 years of personal emails actually take up?
It’s actually not as crazy as you might think:
$ du -sh .Maildir/ 13G .Maildir/That’s going back to
20001995, both sent & received. The first email I have in there is from a friend of mine offering to send me an MP3 she downloaded.You were downloading and sharing mp3s in 1995?? Didn’t the file extension only come out in 1995?
I think she would have gotten the file via hot… something, this little file sharing network that predates Napster.
Edit: It was probably Hotline, which was launched in '97, so there’s probably some corruption to the received email date somewhere. I wasn’t exactly tech savvy 25 years ago ;-)
Look into isync / mbsync in combination with maildir utils (mu/mu4e) or notmuch.
Thanks I am looking at these. Do you think maildir format is the best to try to work with? When I was researching I find there are other formats such as mbox, or more program-specific formats. I was not having an easy time discerning which is the most portable, robust format.
I havent looked into these other formats because maildir works for me. I can saxe local backups, remoxe mail from the serveg, and even put it back later. All plain text.
If you put your maildir on a (disk attached to a) raspberry pi, install mutt, and make that pi accessible by ssh you always have access to your mail.
Does mutt have search capabilities? Is it optimized such that it would be effective with large mailboxes? Thanks!
Mutt (and neomutt) has very nice search capabilities, supporting regex search within specific mailboxes. However, it is a relatively slow search - unbearably slow for full text search in large mailboxes.
Here, notmuch is usually used to complement mutt. It’s a very fast (full-text) mail indexer, which can be directly integrated in mutt and allows much faster searching (among other things such as advanced mail tagging, virtual mailboxes and more).
It is generally a royal pain to set up with so many moving parts but once you do it is a very fast, comfortable mail environment if you’re comfy with the terminal.
Thanks for this! I’m going to try to get this set up. It sounds perfect.
So I think the way I would want to do this is with something like mailpiler (https://www.mailpiler.org/). It’s been on my long list of things to dive into for a while.
I am currently working on this. Finally got the Docker working and am importing my 15GB mbox as we speak! I’ll post back here about how it works out.
That’s awesome, I’ll definitely be interested to see how it all works out.
Did it work?
Alas, no! Things seemed to be going well: I got >90k messages imported from my Google Takeout mbox file before the import was interrupted (not mailpiler’s fault). At this point, I logged into the “auditor” account and was able to see my emails and search them. But, then I resumed the import. By the end of today, the import was finished (~150k messages total). When I logged in with the auditor account, I got some error “No search results” and nothing I could do about it. This is actually what happened last time I tried mailpiler, too, now that I recall. All seemed fine, but, it seems, the database got corrupted or something along the way… So, now it’s useless. I might try it one more time over the next few days. I’ll keep y’all posted.
Oh no!
This kind of tool needs to be something you can rely on if it’s to be used in the way I am intending. If there is a master copy of the mail (as it sounds like you are working from) it’s not as big a deal as you can always go back to that. But if the application is relied upon to be doing its job, possibly in silence for long stretches, it can’t just combust.
I am not sure I really like the word “database” in this context. I don’t understand them and I can’t fix them. Am feeling that maildir, where each email is simply a text file, should be the primary storage. If there is another tool that can index or interact with the maildir then that’s handy, but the mail itself should stay in a plain, interoperable filetype. (Unless that is how mailpiler works? I might be mis understanding.)
I also see that mailpiler encrypts everything. I do not love that. My hdd is already encrypted. I do not want things further encrypted because it also means I am unlikely to be be able to fix any problems.
I think this application is too complex for me. I need something that I can easily administer. Hopefully set up and leave it to be for a long time and not have too much to relearn if something needs to be fixed. It is perhaps suitable for a more advanced user/admin.
Yes, I’m coming to similar conclusions myself. To be fair, encryption is a configurable option with Mailpiler. But, yes, it is all digested and stored in a mysql database, which is definitely more opaque than plaintext in the filesystem. I might try the mutt + notmuch solution described by @marty_relaxes@discuss.technics.de below. Sounds like it might be a challenge to set up but would work great forever after. I’ll need to figure out how to convert my mbox files to maildir, but Google suggests there are tools for that. Good luck to you, let us know what you ultimately figure out! I’ve been working on this off-and-on for a few months now without figuring our a good solution!
Edit: I guess, if you want fast full-text search, a database will have to enter the equation somewhere, though.
Honestly i could live without fast. If its a text file there is always grep, ripgrep, silver searcher etc. But there is nothing in my deleted email demanding immediate attention. Any situation i forsee would accommodate waiting hours or days. I was kind of hoping to continue interacting with it in a webmail kind if way because piling up too many new things for something i wont be working on regularly is just asking for a mess.
The mutt/notmuch proposal is a solid solution for the right person. To me, learning like 5 new major tools just for one project is a big risk. I played around with this stuff a couple years ago and failed at creating even a simple setup to do regular mail stuff. It is absolutely not clear.
So i might try one if the intermediate solutions mentioned elsewhere. A solution that digests mail be acceptable as an addon extra.
Well, I’ve solved it! I now have a web interface (accessible via VPN, although, in principle, I could expose it to the internet) that allows fast, full-text search of all my old emails. Here is the recipe:
- Maildir: I converted all my mbox files to maildir using this python script: https://superuser.com/questions/1169371/how-to-convert-mbox-mail-files-as-found-in-thunderbird-dir-to-maildir#1343019
- Installed notmuch via my distro’s repository and set it up (
notmuch setup¬much new). This creates a new folder in your maildir directory containing full-text search info. - Installed netviel via
python3 -m pip install netvieland then ran it viapython3 -m netviel
That’s it! This let’s you search locally. I actually did a few more steps because I wanted to containerize this thing so I could run it on my NAS. I’d be happy to go into detail about that too, if you’re interested. One hiccup was that, for some reason, netviel binds to 127.0.0.1 instead of 0.0.0.0, and there is no way to change that without compiling the project yourself. But, I found a workaround for my Docker container where you can use socat bound to 0.0.0.0 to redirect requests to netviel, so that requests from other computers appear local to netviel.
Anyway, that makes it all sound more complicated than it is. I am super-pleased to have solved this problem at last!
Well it is literally exactly what I was asking for. :) But as you allude to the setup is not trivial and would be a bit of a project. It is useful to know about because it could help find a somewhat simpler alternative. And I will add it to my own list in case I find none.
edit:
Led me to
polo2ro/imapbox: Dump imap inbox to a local folder in a regular backupable format: html, json and attachements. Which is a different take on the same problem. I am not sure if I like the email all being converted to html like this. It could be a really nice addition but somehow I feel that keeping more original-formatted emails would be wise too. It does also create for each message “A gziped version of the email in .eml format” alongside the html but I would have to look more into what can be done with that.Yeah, I started working on it once a couple years ago and getting it spun up was a chore. Life got busy and I never finished.
That imapbox looks pretty interesting. Thanks for tracking that one down.
If you didnt already, see rest of comments on this thread.
