This looks great but delivery via Amazon SES is a problem. I'm an academic and I tried to set up a work newsletter like this with Listmonk recently, but SES rejected my request to relieve me of sandbox mode for unspecified 'security reasons'. Everything was set up properly, it was under a domain under my personal name, I gave links to my profile page on my university website, ample explanation about what I would do with it (one email ever few months), that I would be the only sender, but they rejected it. So in the end I've opted for a hosted solution... anyone else had similar issues?
philip1209 6 hours ago [-]
Postcard originally used Postmark. But, Postmark deliverability has been decreasing. And, for the open-source version, I wanted to simplify dependencies. So, I moved it to SES. It works for small lists, but won't scale to massive ones.
I welcome PRs to add additional sending providers - it wouldn't be onerous.
cornfieldlabs 44 minutes ago [-]
Just 4 years ago, I was recommending Postmark to everyone who faced deliverability issues with sendgrid.
Would be nice to have just send using sendmail or what ever smtp server we chose. This is HN, and some of us have already done ip warming and to avoid any big players, as they all drop/block emails without telling their users and are not be trusted for reliable communication.
Nextgrid 4 hours ago [-]
SMTP is a must. My advice is to never bother with proprietary mailer APIs - you will need to change providers sooner or later (sometimes on short notice, if your current provider temporarily suspended you on a false positive for example), which is much easier when you just need to swap the SMTP credentials vs implementing yet another proprietary API. Plus it makes local testing easier - there's no shortage of "fake SMTP for development" projects out there.
Of course, tech bros don't want you to do it, as it reduces their vendor lock-in.
philip1209 4 hours ago [-]
That's fair, I can add smtp config.
Really I was just concerned about configuration overload from too many options. Seems like SMTP is worth splitting out, though.
Nextgrid 4 hours ago [-]
I think SMTP is the way to go unless you're actually using specific proprietary mailer API features and there's no way to do the same via SMTP.
Solution is:
* SMTP by default
* if you want, some setup examples of using third-party mail services using their SMTP endpoint (most offer one)
Again you don't have to, it's an open-source project and you owe nothing to anyone. But if you fancy doing it, this is the way to go and will save headaches later.
pirsquare 5 hours ago [-]
postmark is a garbage now. This is coming from a previous postmark advocate and moved to SES.
SES is terrible in the past but now it is at least on-par if not better than postmark.
Only issue with SES is setup can be tedious.
toomuchtodo 3 hours ago [-]
What provider doesn’t suck in this space?
ethan_smith 1 hours ago [-]
For academic newsletters with SES sandbox issues, consider using Mailgun or Postmark which often have more straightforward verification processes and reasonable free tiers for low-volume senders.
f_devd 4 hours ago [-]
I actually had the same issue getting rejected for SES since I didn't have any reputation or something and ended up re-implementing the SES (and SNS) api for use with a regular IMAP/SMTP server, I intended to clean it up and open-source it but never got to it.
miga 3 hours ago [-]
While I admire social-network-friendly websites, I am afraid that performance is too bad to allow its use instead of a social network.
Indeed it is so performance sensitive, that it has blocked my region.
Would it not be better to get a static site generator from a standard Markdown posts, and thus assure it is both performant and accessible?
Your original blog post links to www.postcard.page, which throws a Cloudflare SSL error, but the bare domain https://postcard.page appears to work fine.
philip1209 9 hours ago [-]
Ah, thanks. Just pushed a fix for this.
10 hours ago [-]
ho_lee_phuk 9 hours ago [-]
[flagged]
tomhow 5 hours ago [-]
This is what the guidelines mean by "generic tangent", "shallow dismissal" and being "curmudgeonly". The comment is not about the project or topic, it's just a general expression of discontent with things related to the project, without any consideration of whether that pattern applies to this project or whether this project may in fact be an exception to the pattern.
Please avoid comments like this on HN, and make an effort to observe the guidelines.
I'll join your demise! I have a similar opinion and came up with my own answer.
Ruby is effectively Rails. Something about this has always bothered me because I don't like ruby and it gets SOO much praise from users. Which all almost universally happen to be using Rails. I've never used rails so I could not say why authoritatively. I did find someone recently on here that talked about it and mentioned that Rails is steeped in "magic". That it is unbeatable for a single person founder to create a project of any size. The problem is all that "magic" becomes a huge point of contention/confusion/friction when non rails zealots get involved, which is basically everyone.
Or to be more to the point Ruby and rails has a very specific use case and that use case has nothing to do with the application you are building rather the type and size of Team you are assembling.
To me its just a more obscure Python with a much smaller more enthusiastic user base.
darrenf 7 hours ago [-]
The only Ruby tool I (knowingly) use is homebrew, including distributing internal tools at my employer via private taps. I feel like migrating to nix would be a hard sell, so I'm hoping homebrew isn't on its way out just yet!
theappsecguy 9 hours ago [-]
I mean, do you have a rationale or examples? I find that JS ecosystem is where projects go to die, whether npm libraries or projects.
Rails and Ruby on the other hand offers one of the best ecosystems and a lot of stability
I welcome PRs to add additional sending providers - it wouldn't be onerous.
Who's the relatively better provider now?
Edit: A useful article about IP Warm up https://blog.healthchecks.io/2023/08/notes-on-self-hosted-tr...
Of course, tech bros don't want you to do it, as it reduces their vendor lock-in.
Really I was just concerned about configuration overload from too many options. Seems like SMTP is worth splitting out, though.
Solution is:
* SMTP by default
* if you want, some setup examples of using third-party mail services using their SMTP endpoint (most offer one)
Again you don't have to, it's an open-source project and you owe nothing to anyone. But if you fancy doing it, this is the way to go and will save headaches later.
SES is terrible in the past but now it is at least on-par if not better than postmark.
Only issue with SES is setup can be tedious.
Indeed it is so performance sensitive, that it has blocked my region. Would it not be better to get a static site generator from a standard Markdown posts, and thus assure it is both performant and accessible?
My hosting setup is . . peculiar: https://www.contraption.co/a-mini-data-center/
Please avoid comments like this on HN, and make an effort to observe the guidelines.
https://news.ycombinator.com/newsguidelines.html
Github, Airbnb, Shopify, Stripe, Basecamp, Instacart, Zendesk, Square, and others seem to be staying online, too.
I've written more about my Ruby opinions here: https://www.contraption.co/rails-versus-nextjs/
(Discussed on HN here: https://news.ycombinator.com/item?id=43130546 )
Ruby is effectively Rails. Something about this has always bothered me because I don't like ruby and it gets SOO much praise from users. Which all almost universally happen to be using Rails. I've never used rails so I could not say why authoritatively. I did find someone recently on here that talked about it and mentioned that Rails is steeped in "magic". That it is unbeatable for a single person founder to create a project of any size. The problem is all that "magic" becomes a huge point of contention/confusion/friction when non rails zealots get involved, which is basically everyone.
Or to be more to the point Ruby and rails has a very specific use case and that use case has nothing to do with the application you are building rather the type and size of Team you are assembling.
To me its just a more obscure Python with a much smaller more enthusiastic user base.
Rails and Ruby on the other hand offers one of the best ecosystems and a lot of stability