Thank you so much for this detailed reply. I haven't decided on the tech stack yet. I wanted to deal with the toughest choice first.
At first I was thinking to use SQL to store an original version and a "searchable" version, which is basically the email stripped out of HTML tags.
After your reply I think of starting with (1). Never have been using ElasticSearch, so would be pretty nice to learn it along the way. Problem with (1) would be inode count at some point, but I guess I will stumble upon an easy fix.
Also about attachments, I don't think I will be receiving emails with any of them. So whenever I get some I guess I'm going to be compressing them and keeping them somewhere just in case.
Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Glad I could be of help - feel free to ask if you need more input. I think you still will have some decisions to make down that road, depending upon your actual requirements and the system you're about to build - talking also about amount of messages that should be stored in total, amount of messages incoming per day/hour, ... . But not having to deal with attachments is something making this thing a bit easier.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you so much for this detailed reply. I haven't decided on the tech stack yet. I wanted to deal with the toughest choice first.
At first I was thinking to use SQL to store an original version and a "searchable" version, which is basically the email stripped out of HTML tags.
After your reply I think of starting with (1). Never have been using ElasticSearch, so would be pretty nice to learn it along the way. Problem with (1) would be inode count at some point, but I guess I will stumble upon an easy fix.
Also about attachments, I don't think I will be receiving emails with any of them. So whenever I get some I guess I'm going to be compressing them and keeping them somewhere just in case.
Again, thank you for sharing!
Glad I could be of help - feel free to ask if you need more input. I think you still will have some decisions to make down that road, depending upon your actual requirements and the system you're about to build - talking also about amount of messages that should be stored in total, amount of messages incoming per day/hour, ... . But not having to deal with attachments is something making this thing a bit easier.