Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A self-hosted email engine

mailcoach.app

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Show HN: A self-hosted email engine

#51

Post by Isinlor »

theamk wrote: post #45
Isinlor wrote: post #18

Earlier quoted context omitted.

PHP is a very good choice. If you want to refresh your knowledge of PHP take a look here: https://phptherightway.com/ It's fast. PHP has great documentation. PHP ecosystem is now based around Composer, in comparison to mess of package management in JavaScript and Python, Composer is just wonderful to use. Packagist has ton of libraries. Share nothing architecture is very easy to maintain and scale. You can do strict…

I did a quick look through PhpTheRightWay website, and I saw no mention of the advice that php user should have no permissions to change app code -- or in other words, that "deploy" and "run" users should be different. Is this the recommended practice now? Because that was the main reason to avoid PHP codebases for me. Having an app where any code execution bug instantly leads to permanent compromise scares me deeply…

PHP was never receiving requests directly from the Internet. It was always a standard practice to talk to PHP trough a server. The separation between what you call deploy and run user is what you get as default by using Nginx or Apache on Ubuntu (root vs. www-data). If you feel very paranoid and don't mind some complexity you can put PHP code into a docker container and run it from there. In that setup, attacker targeting PHP code would need to break out of docker container to take full control over the server.

Re: Show HN: A self-hosted email engine

#52

Post by shortj »

PetahNZ wrote: post #28
rolleiflex wrote: post #19

I think this is a more modern alternative to Sendy ( https://sendy.co/ ) which is a little cheaper. (no affiliation except being a user) Sendy does look like it has more features though - and it has been around for far longer, corner cases debugged and all. I’d love to hear how this is any different from Sendy.

Sendy has abysmal performance for large lists though.

I'll never understand why they haven't fixed that. A while ago I ended up writing a little patch that parallelized list sends with Redis backing things and some worker processes. Took me maybe a day of work. If I remember right we were easily getting a few hundred sends a second, could have easily gone faster. Default Sendy was a few a second on the same machine/resources. SES can support tremendous send rates if you get limit lifts from AWS.

Re: Show HN: A self-hosted email engine

#53

Post by marcosdumay »

buboard wrote: post #40
sneak wrote: post #38

Earlier quoted context omitted.

If only it were that easy! This usually isn’t enough anymore. First off, you don’t really have control over your external IP reputation, unless you have your own IP space, which most people don’t. You’re at the mercy of your colo/hosting, really. You get whatever IP they give you, baggage included. I think the reputation is also subnet-based, not IP based, so your potential to be included in someone else’s blast radi…

then how do the email services , who post massive amounts of emails and many of them are spam manage to get through? do they have some kind of deliverability deals with gmail? (btw my mails also seem to get through and i haven't even set up DKIM)

Short story, yes, they do.

Plenty of people report that there is a minimum amount of email you have to send so that you can contact gmail and ask them to unlock you. They, of course have a set of rules you have to follow.

But you won't get them to receive your email if you just send some 3 messages a week.

Re: Show HN: A self-hosted email engine

#54

Post by robjan »

JoshTriplett wrote: post #50
masukomi wrote: post #46

Earlier quoted context omitted.

that's because SES HATES being used. IT's very much a "If you absolutely _must_ send and email from here.. fine. we'll let you, but you _really_ ought to use some other service."

Can you elaborate a little on that? SES looks reasonable from the outside; what problems does it have that other email services don't?

Not GP but I can give you my experience. SES seems to be a "good enough" solution if you use their API. There are a lot of missing features, such as logging anything other than metadata, which makes it not so useful if you are operating in a regulated industry.

The real problems come when you try to use the SMTP gateway. It's quite slow and unreliable and doesn't really work for parallel workloads. The only way to somewhat mitigate it is to deploy a postfix into EC2 and then queue your emails there.

Re: Show HN: A self-hosted email engine

#56

Post by theamk »

Isinlor wrote: post #51
theamk wrote: post #45

Earlier quoted context omitted.

I did a quick look through PhpTheRightWay website, and I saw no mention of the advice that php user should have no permissions to change app code -- or in other words, that "deploy" and "run" users should be different. Is this the recommended practice now? Because that was the main reason to avoid PHP codebases for me. Having an app where any code execution bug instantly leads to permanent compromise scares me deeply…

PHP was never receiving requests directly from the Internet. It was always a standard practice to talk to PHP trough a server. The separation between what you call deploy and run user is what you get as default by using Nginx or Apache on Ubuntu (root vs. www-data). If you feel very paranoid and don't mind some complexity you can put PHP code into a docker container and run it from there. In that setup, attacker targ…

That sounds nice -- but does this happens often in PHP world? Last PHP project I tried to install was OwnCloud, and it explicitly says (in [0]):

> Your HTTP user must own the config/, data/, apps/ respectively the apps-external/ directories so that you can configure ownCloud, create, modify and delete your data files, and install apps via the ownCloud Web interface.

[0] https://doc.owncloud.org/server/10.4/admin_manual/installati...

Re: Show HN: A self-hosted email engine

#58

Post by Isinlor »

theamk wrote: post #56
Isinlor wrote: post #51

Earlier quoted context omitted.

PHP was never receiving requests directly from the Internet. It was always a standard practice to talk to PHP trough a server. The separation between what you call deploy and run user is what you get as default by using Nginx or Apache on Ubuntu (root vs. www-data). If you feel very paranoid and don't mind some complexity you can put PHP code into a docker container and run it from there. In that setup, attacker targ…

That sounds nice -- but does this happens often in PHP world? Last PHP project I tried to install was OwnCloud, and it explicitly says (in [0]): > Your HTTP user must own the config/, data/, apps/ respectively the apps-external/ directories so that you can configure ownCloud, create, modify and delete your data files, and install apps via the ownCloud Web interface. [0] https://doc.owncloud.org/server/10.4/admin_manu…

A lot of PHP apps allow you to install plugins from within the app itself, without going trough the whole process of deployment. The app has to modify it's own code in that scenario. This is independent from programming language. If you allow users to independently install plugins you will allow them to execute third-party code - it's true for all programming languages.

I don't know ownCloud, but I would guess they have an option to disable plugin installation.

And as I said, if you feel paranoid, you can install PHP apps in docker container: https://doc.owncloud.org/server/10.4/admin_manual/installati...

Re: Show HN: A self-hosted email engine

#60

Post by filesystemdude »

mahesh_rm wrote: post #57

Listmonk was posted here some time ago, I have yet to try it out, but if you are not scared by alpha-quality code, it could be a good free performance-driven alternative to this: https://github.com/knadh/listmonk

Not intentionally picking on Listmonk (or you), but when I hear "alpha-quality code" and start thinking about the complexities of marketing emails with GDPR, CCPA, and the constant threat of blacklists and otherwise getting blocked by big G, I run for the hills.
Post reply on HN