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.
I can read the installation instructions of Sendy and say "yup, I can do that. Upload a file, point my web browser towards it".
I read the installation instructions of MailCoach and wonder whether this Composer thing is what I would use if I had a server that's not a DigitalOcean server, and whether this is something I can install without becoming a PHP wizard.
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.
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."
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.
> 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.
Ah, that's helpful to know. I would normally have wanted to use the SMTP gateway as a more portable API, to avoid tying things to Amazon-specific APIs. But it sounds like doing so would add substantial fragility.
We send our newsletters via mailtrain - https://github.com/Mailtrain-org/mailtrain with postmark as the backend. Where mailtrain falls short is the template editor but since we are geeks we get by with some raw html :)
Is there a way to try mailcoach without paying for it first? Is there an API to import users?
As someone who has been out of the PHP game for a long time, is it still a viable choice for new software? I don't have fond memories of the language at that time, so seeing PHP in the demo video poster frame was an immediate mark against pitching this at my company. That made me wonder whether it's a reasonable reaction to have.
Edit for the downvoters— this is an honest question and I very much agree that we can never have too much high-quality self-hosted software. If that can be done with PHP I'm open-minded.
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 typing. There are static code analysis libraries like Psalm and PHPStan if you want features normally offered by compilers. It's easy to hire devs. There are two wonderful frameworks that moder PHP is centered around: Laravel and Symfony. There is also community body issuing standards to ease framework interoperability: https://www.php-fig.org/psr/
The app seems to be written in Laravel, so you can take a look here if it's your coup of tea: https://laravel.com/
Having said that, Wordpress and other old code bases are still a mess. But stable mess, and business like stable :) .
The hazard is that it was such a big mess in the past that if you want to hire someone to work on your self-hosted app, there are going to be a lot of applicants who want to use PHP the wrong way.
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.
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.
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.
That said Node.js has IMO an interesting architecture because it's event driven, combine that with Typescript and it's solid.
Python type support, and event driven frameworks (e.g. async/await) were only (fairly) recently made accessible, there's a few frameworks that can utilize it well like FastAPI, but many of the popular ones like Django are still behind on async/await support for the a lot of features like the ORM and still is lacking typing support. IMO the python web development system is going to be really awesome once Django gets robust types and async support.
Disclaimer: Current job uses python/Django and js. I have little experience with other languages/frameworks.
PHP is getting a lot better these days. There is still a lot of clunky legacy syntax but the performance and features are pretty much on par with other scripting languages now.
When you can't exactly tell what was bad about PHP, then it may just be an impression given to you from a lousy programmer who would just blame the tools instead or from some messy code which apparently isn't the fault of the language.
What's wrong about it really?
If you're an author of an opensource web app, it's a smart choice to pick PHP to have as much audience as you could get. PHP is the primary candidate for any VPS.
I understand not wanting to write PHP for an app I have to maintain as part of my daily work, but for something like this where you want to sell it to anyone and have it run anywhere, it's hard to be more universal than "PHP and MySQL" (though it does make me smile when SQLite is an option as well).
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.
Hosting your own email service is way more difficult than just spinning up a smtp server and some interface. Most big providers (like gmail) are more likely to flag incoming mails from unknown servers.
That's the reason why stuff like Sendy[1] is so popular. You host your own interface, settings and so on, but the ugly part of sending your email is handled by AWS SES.
That's only true if you're spamming people a lot. Running your own postfix server is trivial, and you'll have a fine reputation so long as you aren't sending marketing BS.
Unfortunately, this is the total opposite of my experience. I've never sent any spam from my domains and yet Gmail refused constantly to let any of my emails through regardless of my VPS provider, my DKIM/SPF setup and so on. The _only_ way I could solve it is by letting my email be managed by some other email service provider (I went with Zoho but I don't think it matters).
Running own SMTP server for personal use is hard. Google is the worst adversary just because of their market share.
I have a mail server for personal use, and I send less than 10 mails per day for many years. DKIM, SPF, DMARC are all properly set up. I am signed up to all possible postmaster tools, including that of Google.
Still, Google started blocking mail sent from my IPv6 address in December. I switched to IPv4, and it fixed the issues for existing gmail recipients, but new recipients usually see my mail in Spam. When I don't get a reply for a few days, I mail them from my backup @gmail.com account and ask to unmark me as spam and add to contacts. So far, this helps.
P.S. I also run a community website on a different domain and IP. It sends tens of thousands of notification emails per month, and it fares better in Google Postmaster Tools. User-reported spam is within 1% and it seems that this is acceptable behaviour for Google.
My current impression is that Gmail is sort of broken in general. There isn't really anything you can do to insure that an email will get delivered to Gmail with 100% certainty.
Presumably people who actually care would not be on a free email service in the first place...
This isn't true. When running my own server Google will send me emails but will not allow me send emails to my Gmail account. I know it is configured properly because I can email other services just fine.
I found many servers will block you if you first send them email (e.g. greylisting). If you can get them to send you an email first, then everything tends to work from then on.
I'm surprised that someone is having problem sending email to gmail from their own smtp server. I am doing this for years with tens of thousands emails delivered every week (sometimes daily), yet had no issues. Here are few advises:
- ensure your external IP reputation is good. Check blacklists.
- configure correct dns/reverse dns (PTR) records.
- setup SPF (maybe DKIM with DMARC but I'm not using these)
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 radius is increased.
Also, even with a clean IP, the steps you outlined are not sufficient to send significant numbers of non-spam messages and not get spamboxed. Gmail seems to be mostly okay with erring on the side of false positives.
Source: been running my own email servers for 25 years
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)
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.
One reason is that the services are actually quite cheap if you are running a real business. Likely better to spend time on your core thing instead of tinkering with mail server.
Please endure my ignorance, but what is this? Spamtool with a potential feedback trough images in html mail that report back if email was viewed? I just don't get it, this can be acomplished very simply with shell script and web server... or?
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.