We use this in production. This is very good software and easy to self host. Just use Amazon SES for email, S3 for storage and Postgres for database. That's it, you have an email server that costs pennies
Isn’t the main pain point with mailing lists clean IP address management/not being labeled as SPAM by the big 3 (Google/MS/Yahoo). And isn’t like 90% of that just being big enough that you have to be taken seriously?
I know there are a fair number of people on hn who run their own mail servers but I feel like their biggest complaint is being taken seriously by GMY…
Let's say that you have a very large marketing list with 200k people, but you only email once per month.
MailChimp = $1,190 per month if sent as marketing email priced on number of contacts, $200 per month if sent as transactional email priced as number of emails
SendGrid = $90 per month priced as number of emails
Just using ListMonk with SendGrid if you have a large number of subscribers would be worth it.
ListMonk represents the solution to mailing list management, IP reputation is a separate problem.
For things like charities that have tight budgets and potentially huge contact lists, ListMonk would really help them embrace email more because the pricing wouldn't put them off.
This is correct. Our listmonk instance has ~7mn subscribers to whom we've to send updates (sometimes mandatory regulatory ones within stipulated periods) every month.
The cost of hosting listmonk and Postal SMTP servers (that we scale up momentarily when sending a campaign) on EC2 is peanuts. With proper SPF + DKIM + not sending spam, we haven't had any IP reputation issues.
It's a really nice looking piece of software so I hope to use it the next time I find myself reaching for Mailchimp, and I like that if other companies are using it too that all of the changes will be public and have the potential to enhance the software.
Assuming you can connect this system to external servers for sending email, you could use something like ListMonk + Amazon SES to get a much cheaper solution than MailChimp etc. That would solve the spam problem.
Looks great! I've been looking for something like this in the FOSS world for a while now. Will give it a try.
Suggestion to the author: A demo link would be great (doesn't need to actually send mails) – but just clicking through the UI would help a lot to understand the scope and features of a product.
It is worth noting that setting up a local demo with their docker-compose based script is roughly 30s of work:
mkdir listmonk-demo
sh -c "$(curl -fsSL https://raw.githubusercontent.com/knadh/listmonk/master/install-demo.sh)"
This will setup a local server on localhost:9000.
That said, I would personally recommend inspecting the bash script first before running it. The script in this case is not malicious, but it's a good habit to have.
I'm not OK with the modern practice of recommending end-users download and execute a script from the big, bad web without first reading it.
I guess I'm just an old fuddy-duddy, and if you feel it's OK, knock yourself out. But I really think software developers should know better than to rely on this practice simply because it makes their install process into a one-liner. I'm sure they could do better than recommending users execute random scripts from the intarwebs, sight-unseen.
What is the difference between downloading and running a bash script vs. downloading and running a binary or a Docker image?
Surely, when downloading a piece of software from a (quasi?) trusted source, no developer is going to read all the lines of source code before running it. And if that's the case, how is downloading and running an .sh from the same source any different?
It's probably a bad idea to willy-nilly "docker run" something too - but in this case it's extra silly - the demo requires docker and docker-compose - so the downloading/instruction might as well have been just:
wget https://raw.githubusercontent.com/knadh/listmonk/master/docker-compose.yml
docker-compose up demo-db demo-app
And a note that demo app runs on port 9000. Even better would be a demo docker-compose.yml, so that "docker-compose up" was enough.
Now, should you run some random docker image(s)? Maybe not. But it's easier to see what's going on - maybe you spin up a vm and run docker there, isolated?
> What is the difference between downloading and running a bash script vs. downloading and running a binary or a Docker image
Docker images are slightly isolated. By default running a random one doesn't have access to your local filesystem or anything listening on your machine, unless you explicitly ask for it ( which a random docker-compose.yaml or bash script around a docker-compose.yaml and up can).
TBH, I've never downloaded a Docker image. I rely on Debian; I trust packages from the Debian repository (hell, I'm running their OS, so I already trust them).
Software from other sources: not so much. Maybe run it in a VM.
Look, I've used such commands myself - once upon a time that was the recommended way to install LetsEncrypt, I think. But I look at the script first.
You need to be on a desktop device, you need to have Docker running and you need to have port 9000 still available.
So I still think these are pretty high requirements to test a product out. Especially since this is a tool being used by non-IT people (E-Mails/Marketing). Might be helpful to have a demo, to help convince people who don't know what docker is, but can still vote/decide/argue for/against certain software solutions.
Been using it since June with Haraka for the email sending of small newsletters (around 50k recipients a day). It's working great. Love the simplicity of it.
Deliverability is affected by the IP address's trustworthiness and a few other factors. Avoiding spam filer is a bit harder as you likely have to set up your promotions to be way different from what most people think is normal. Add easy unsub headers, send few emails, make sure you don't send regular emails that have very low open rates, etc. You might be marked as spam (personally I don't mark as spam unless the unsubscribe request is ignored, or unwanted emails are sent daily).
For example, I always open Microcenter's somewhat frequent emails, so I'm probably beneficial to them. Make frequent newsletters or marketing opt-in, this will not only keep open rates high (only interested readers will sign up, thus high open rates) but will also help avoid more ML-based spam filters that take open rates into consideration. You might be classed under "promotions" in Gmail regardless but that's less bad than classed as spam.
warning: shameless self promotion.
If you want a desktop app to send emails (and SMS) to your list, I just released: https://github.com/cmitsakis/polysender but I don't recommend it for production use yet.
I have had a horrible time getting this to work with dokku/docker, etc. after a few days of wrestling. Once "up", a couple of pages would not render for me at all. So I moved to mailcoach (early days, just being honest. mautic was too heavy, mailtrain seemed dated). I am trying to move away from projects with a small number of developers; it's too hard on all involved. I greatly admire the work and overall generosity of the offering however.
That is very surprising to hear. listmonk is a single exe with no dependencies (except for Postgres connectivity). Running the Docker setup is as simple as `docker-compose up app db`. If you don't want Docker, you can just download the binary and do `./listmonk`.
I host my own email and most of the time I don't encounter any technical problems: I got rejected once (last week) since I started last year. Most of my problems have been trying to tell/have people read my non "@gmail/outlook/yahoo" domain! Probably depends on how you use your email, but it's been smooth pretty smooth sailing personally.
IIRC, you avoid most of the problems if you set up your DNS accordingly (DMARC, SPF, etc). But for a mailing list AWS SES is probably the way to go to avoid all the trouble.
Comparing with MailChimp and co, I’d say it’s definitely cheaper (going with SES for sending mails at least).
I like it because I own the data of my email lists and in this sense, the control is also a big plus point! Plus it’s open source, probably easier to get something custom working than with any big provider out there.
listmonk author here. Interesting to see it on the frontpage again. Some updates to the linked comment (which is from 2019):
- Tons of active development has happened and listmonk crossed 1.0 this year. 2.0 is on the horizon and there are quite a few listmonk instances in production.
- Our production setup at work now has ~7mn subscribers and listmonk works quite well. No issues with deliverability or IP reputation with our self-hosted EC2/Postal SMTP setup.
- listmonk now supports generic "Messenger" HTTP webhooks to which any message provider can be connected, allowing it to send arbitrary message campaigns like WhatsApp and SMS, not just e-mails.
Anyways, I wanted to ask a few questions, if I may:
1. Why is listmonk AGPLd? It doesn't look like listmonk is core to Zerodha (even if it is released on your personal GitHub) and so curious about the licensing, because MIT/Apache could have done just as nicely, especially since xGPLv3 software is pretty much a no at most tech firms.
2. How do you decide if a repo is going to land on knadh vs zerodha GitHub?
3. Any plans to take it fully serverless with Aurora Serverless + Fargate or fly.io, for examples.
1. I think AGPL is a good license for web apps that can also dissuade Elastic/Mongo-like fiascos. Mastodon, Metabase, Grafana, Minio etc. are AGPL and are widely used.
2. We see ourselves as a group of hackers and not really as a corporate entity. Many projects that come out of our team are largely individual efforts. For instance, I have spend considerable personal time working on listmonk over the last couple of years just because I like it. There is no Zerodha mandate involved. Only projects that have to be branded as Zerodha or involve a lot of multi-dev effort go under the official handle (ref: https://zerodha.tech/projects)
3. listmonk offers a one-click Heroku button (a bunch of simple scripts really), so it should just be a matter of creating deployment scripts for other platforms as well. I have not looked into it personally.
Nothing against the xGPLs, because they protect a user's freedom better than MPLs / EPLs / APLs, even if the license's nuances are not well-understood (which is why they're restricted for use by some tech firms).
What would their benefits for releasing it under a permissive license be?
AGPLv3 is a good trade, you get to use it for free but if you make improvements they need to be released, which often means that they are directly unstreamed as that is easier in the long in regard to code maintenance and tarball/source-control hosting for the modified sources.
So win-win for all users and the devs.
> even if the license's nuances are not well-understood
Which nuances are not understood?
> which is why they're restricted for use by some tech firms
Only those companies that want to actually modify the source and directly integrate it in a proprietary project, iow taking all but giving back nothing.
All companies that just want to use it unmodified, just accessing the API or integrate it in a compatible project with releasing any changes are just fine to do so.
> What would their benefits for releasing it under a permissive license be?
Similar benefits to a work released to the public domain (under permissive licenses such as BSD 0-Clause, CC-0, The Unlicense etc) versus any work that isn't. See the linked apache foundation blog-post in my comment above.
> AGPLv3 is a good trade, you get to use it for free but if you make improvements they need to be released...
This can be achieved with just GPLv3, and to an extent (but not quite) with EPLv2, MPLv2, and LGPLv3.
> Only those companies that want to actually modify the source and directly integrate it in a proprietary project, iow taking all but giving back nothing.
Even zerodha, which has closed sourced bits, would do well to seek counsel when using listmonk because there's danger they might violate AGPLv3 (ie, the rights of all contributors to listmonk) themselves if they're not careful enough.
>> AGPLv3 is a good trade, you get to use it for free but if you make improvements they need to be released...
> This can be achieved with just GPLv3, and to an extent (but not quite) with EPLv2, MPLv2, and LGPLv3.
No it cannot be achieved with those in generally, as Elasticsearch and other recent fiascos show.
Only AGPLv3 provides protection against "bad actor" SaaS providers.
>> Which nuances are not understood?
> Ex A: https://opensource.stackexchange.com/questions/5003/agplv3-s...
Seems like a pretty clear answer with lots of good sources backing it up.
I'd appreciate it if you could be a bit more specific in where you see the non-understood nuances.
>> Only those companies that want to actually modify the source and directly integrate it in a proprietary project, iow taking all but giving back nothing.
> Not really. Tech shops also tend to outlaw it for "risks involved". Ex A: https://opensource.google/docs/using/agpl-policy/
I know from personal experience that in practice this is not true in general, there are exemptions and AGPLv3 projects are used (but not derived or directly linked to!) – I cannot give out the specifics though, I'm afraid, so you'd need to take my word on that one.
> Only AGPLv3 provides protection against "bad actor" SaaS providers.
Elastic, Mongo, Redis et al moved away from AGPLv3 to an even more sterner SSPLv1. May be AGPLv3 isn't enough? Also the comparison seems odd since listmonk isn't in the same category as those; listmonk isn't core to the creator's business / income.
> I'd appreciate it if you could be a bit more specific in where you see the non-understood nuances.
Ref the part of the answer to the question which goes:
>> Q: What if in my case... the author of the library insist that the copyleft is triggered even if I am using the library unmodified and that I must redistribute the whole source code, including my own?
>> A: In this special case you should never ignore this interpretation (even though it looks clearly incorrect based on the facts I presented here) and you have two options...
> ...there are exemptions and AGPLv3 projects are used (but not derived or directly linked to!)
My best wishes to those proprietary-software selling tech cos for taking more risk than they should.
listmonk has nothing to do with Zerodha's business though. It's a personal project that I built prompted by usecases at work originally. I like AGPL because it increases the odds of improvements coming back to the upstream project, something into which I invest a lot of personal time.
> I like AGPL because it increases the odds of improvements coming back to the upstream project, something into which I invest a lot of personal time.
A note: MPLv2 (HashiCorp's license of choice) also achieves that just as nicely if improvements not getting back into upstream is a concern. xGPLv3 is of course better at it, but through its virality (not a bad thing but something tech cos are averse to it).
Besides, as mentioned above, Zerodha needs to be careful with its use of listmonk. They are at risk of violation of AGPLv3 themselves if they are not careful, ie violation of the rights of all contributors to listmonk, and not just that of the original author. IANAL.
I'd kind of forgotten about that. Ruby on rails smtp server? Any comment/idea on how it stacks up vis-a-vis postfix or opensmtpd in terms of performance and security?
Unsub has been available from day one. Bounce handling (generic webhooks, POP3, SES+Sendgrid webhooks) is already merged into the repo and will be available in the upcoming release.
It just works.