3 ms·

I'm in a similar mindset... I've had on my personal todo to play with wildduck or similar for a few months, I had setup a Mailu server last year and it ran okay

I'm in a similar mindset... I've had on my personal todo to play with wildduck or similar for a few months, I had setup a Mailu server last year and it ran okay, though I didn't use it much. I switched to a dedicated hosted server account a few months ago, and didn't migrate my mailu setup as I wanted to do it a little differently. In the end, it feels like email is still way over priced for what it is, with a wierd contrast between too few complete options, and plenty of complex or commercial ones. I'm not sure where the right balance is when you're one person with multiple domains and a handful of family/friends. I had relied more on Google Domains' free email forwarding, of course with them selling the domain business, who knows how that will land. I noticed I could do the same with Cloudflare and an email worker, even it a bit of a PITA, though kind of nice in that I can do an email distribution list with their email workers. In the end, it's such a mixed bag of bad to worse options, I'm not sure how to feel, or how much effort is actually worth it in the end. And that doesn't cover spam or filtering.

figassis 3y ago
I've implemented an email service using wildduck (https://get.bantumail.com https://get.bantumail.com). It works great, and the storage architecture is great, but I'm afraid it will cost a lot with scale, because I do not want to manage a large, business critical mongo cluster that stores attachments. I'd rather store these in object storage and have messages in postgres, so I'm considering implementing that for wildduck. But for your use case (family and friends), wd is a great choice.
- tracker1 3y ago
  Yeah... I had similar feelings about it... I'm planning on just running a single node stack via docker-compose for my use, with daily rsync for backup. Should be more than enough for the handful of users I'm likely to have. I'd probably break attachments into object storage first, ahead of touching the rest of the MongoDB. If you do that, read replication for mdb should be relatively easy, or possibly just rely on their hosted/managed option. If you're in AWS, they have that as well. I get the feeling though, had to recover a borked cluster about a decade ago when Azure was going up/down for a few hours and the oplogs were hopelessly out of sync... Fortunately, they were just read replicas, not sharded, so was faster in the end (after trying other options) to just break and re-build the two replica nodes. No idea how I would have handled things depending on the scenario if it was sharded. When I've used Mongo, I'll push the record update into a queue, that then gets stored in object storage. Worst case would be importing everything in to the collections from object storage. Mongo definitely isn't the first thing I reach for at all since then, and I'd rather use pg or cockroachdb myself.

figassis 3y ago

I've implemented an email service using wildduck (https://get.bantumail.com https://get.bantumail.com). It works great, and the storage architecture is great, but I'm afraid it will cost a lot with scale, because I do not want to manage a large, business critical mongo cluster that stores attachments. I'd rather store these in object storage and have messages in postgres, so I'm considering implementing that for wildduck. But for your use case (family and friends), wd is a great choice.

tracker1 3y ago
Yeah... I had similar feelings about it... I'm planning on just running a single node stack via docker-compose for my use, with daily rsync for backup. Should be more than enough for the handful of users I'm likely to have. I'd probably break attachments into object storage first, ahead of touching the rest of the MongoDB. If you do that, read replication for mdb should be relatively easy, or possibly just rely on their hosted/managed option. If you're in AWS, they have that as well. I get the feeling though, had to recover a borked cluster about a decade ago when Azure was going up/down for a few hours and the oplogs were hopelessly out of sync... Fortunately, they were just read replicas, not sharded, so was faster in the end (after trying other options) to just break and re-build the two replica nodes. No idea how I would have handled things depending on the scenario if it was sharded. When I've used Mongo, I'll push the record update into a queue, that then gets stored in object storage. Worst case would be importing everything in to the collections from object storage. Mongo definitely isn't the first thing I reach for at all since then, and I'd rather use pg or cockroachdb myself.