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.
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 @[email protected] 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:
notmuch setup¬much new). This creates a new folder in your maildir directory containing full-text search info.python3 -m pip install netvieland then ran it viapython3 -m netvielThat’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!