8 ms·
Plunk: The open source email platform
- v3ss0n 2y agoWhy on top of SES? why not SMTP?
- Gys 2y agoBecause AWS SES offers an API for sending mails and IMAP is a protocol for a mail client talking to a mail server?
- v3ss0n 2y agoFixed, I meant SMTP. SES is not open protocol and it's not self hostable. no point in using this for selfhost env
- jdpedrie 2y agoBecause if you send marketing emails through SMTP, your delivery rate will be approximately 0.00%, or if you're leveraging a third party SMTP, they will ban you.
- v3ss0n 2y agoVery good point.Thats the most painful point in selfhosting email .
- prmoustache 2y ago> or if you're leveraging a third party SMTP, they will ban you. Not if you are paying them for the service. There are ommercial email services that aren't google/microsoft/aws. My former company used to use one (can't remember the name) that provided you with smtp servers and a set of dedicated IPs per customers that were preused by them to build a good reputation beforehand. I think the point is not necessary that you have to selfhost email (although it can be done, some people do), but depending on a single vendor through a proprietary service/API.
- aidenn0 2y agoBecause delivery rates through self-hosted SMTP are lower than through commercial e-mail delivery services; the latter being close to unity[1] and the former ranging from near-zero to about 7/8 depending on how much work and time you put into doing things. 1: My "close to unity" number comes from my experience with the mailgun APIs, I assume that SES is similar.
- crote 2y agoI absolutely hate how it feels like the e-mail delivery services and Google/Microsoft/whatever are working together to form a protection racket: sure would be a shame if your email were to get lost, better pay us to guarantee it makes it to its destination... Imagine the outrage if your national snail mail carrier were to shred 50% of all mail which didn't have a Premium Protection stamp. Why do we let the big cloud hosters get away with it?
- dartharva 2y agoTo this day I don't understand why email providers don't offer first-party Mail Merge facilities themselves. AFAIK Microsoft is the only one that offers the feature with Word and Outlook in its Office suite, and even that is very restrictive (besides being downright inaccessible from the newer apps).
- MrGreenTea 2y agoGMail offers this when you pay for Google Workspace.
- iamacyborg 2y agoProbably because it’s rarely used for anything other than unwanted email, aka spam.
- Spivak 2y agoOr batched transactional emails like monthly statements that need to have user/region specific variants. https://www.twilio.com/docs/sendgrid/api-reference/transactional-templates/create-a-transactional-template https://www.twilio.com/docs/sendgrid/api-reference/transacti...
- iamacyborg 2y agoNo one serious is using mail merge to send transactional emails.
- jszymborski 2y agoAwesome! Any comparison to Postal?
- prmoustache 2y ago> built on top of AWS SES. [...] can be considered as a self-hosted alternative to services Someone doesn't really understand self-hosting.
- gwbrooks 2y agoSelf-hosting the mail-composing, mail-merging and tracking functions while using third-party SMTP is well-trod territory. The former can be done on a pretty basic box and the latter, at scale, is a heavy lift. My guess is Plunk is for people who need a Mailchimp-like offering at a lower-than-Mailchimp price point.
- layer8 2y agoIt’s misleading to call it an “email platform” you can self-host though.
- cqqxo4zV46cp 2y agoIt confused you. That doesn’t make it misleading.
- Spivak 2y agoTo most shops, using SES is considered "doing it ourselves" so I somewhat get the characterization. It's very common for self-hosters to use DO, Lightsail, Hetzner because the thing you're hosting is the software. With SES the line between it and SG can be huge if you're using all of SG's high-level features or razor thin if you use SG as SMTP over API.
- rapht 2y agoMy understanding was that the main interest of SendGrid, Mailgun et al was precisely that they manage to (more or less) reliably mass send email through the great MS/Google/Proofpoint, where hitting the recipient's mailbox is less than guaranteed if you self-host.
- wildekek 2y agoMaintaining sender reputation is tough and I don't think anyone in their right mind should try this in house. If you're not a M3AAWG member, you'll probably hit a brick wall when trying to explain to Google why your whole IPV4 block is erroneously on a blocklist.
- stormbeard 2y agoHow can they call this self-hosted if it’s built on AWS SES?
- jmduke 2y ago(Disclaimer: I run Buttondown, which is an email-inflected product. I also have a comparison guide of various MTAs here — https://buttondown.email/comparison-guides/esps https://buttondown.email/comparison-guides/esps — and will add Plunk!) Nuances of self-hosting aside, I'd recommend caution looking at that pricing pane. The disclaimer is: > Calculated based on the plan that best matches the features of Plunk at 2500 emails per month. And the author then cites prices of $0.001/email for Plunk and $0.013/email for Sendgrid. I am neither a user or fan of Sendgrid but that feels like disingenuous anchoring. Sendgrid's free plan is 100/day; if you want to eliminate the free plan entirely and just focus on their cheapest paid option, it's $19.95 for 50K emails — or $0.000399/email, cheaper than Plunk's sticker price. It's not entirely obvious to me how that $0.013 was even calculated ($0.013 * 2500 = $32.50). Either way, be sure to spot-check against live sticker rates before making a decision there.
- pino82 2y ago"You will need an active AWS account with SES enabled to self-host it." That's an interesting way to see the world... Nooo, thx........
- v3ss0n 2y agoYou have a wrong understanding of self hosting. SES is not self hostable and require to depend on close source paid service. So this just makes an opensource email UI not platform
- bgentry 2y agoHaving recently adopted Resend and skimmed a bunch of different email APIs, I'm still waiting to find a single provider whose API supports Stripe-style idempotency [1] so that I can guarantee I don't send the same email through their API multiple times. I'd like to confidently avoid accidentally spamming a user if i.e. a background job retries multiple times due to an unrelated error, or merely from failing to receive the API response that an email was sent/created successfully. Plunk's API does not appear to offer any such feature: https://docs.useplunk.com/api-reference/transactional/send https://docs.useplunk.com/api-reference/transactional/send Unfortunately neither does Resend, Sendgrid, Postmark, etc. [1]: https://docs.stripe.com/api/idempotent_requests https://docs.stripe.com/api/idempotent_requests
- 01HNNWZ0MV43FF 2y agoYep I was shocked that SendGrid doesnt do this I don't even expect them to keep a list of IDs forever, just some best effort like "we don't send anything with the same id twice in a one-hour window" Gmail's API did support this I believe, and then ofc my org transitioned to Microsoft so my little homemade email service quit working
- johtso 2y agoThis is exactly what I've been wrestling with recently.. it's so disappointingly absent in all the offerings out there. The solution I ended up with was to build my own pseudo-idempotency around Postmark. It helps that Postmark at least has proper persistence so you can query their API to check if you've already sent a certain email. I had to move away from Mailchimp because, if an email gets queued for some reason, it isn't reflected as sent in the API so there's no way of knowing whether an email is hiding in "queued limbo". Postmark doesn't have this problem. The only caveat is that there is a delay between sending an email and it being reflected in the API (seems pretty standard across the different services). This means I had to implement a simple database backed lock to make sure I never try to send the same email more than once in quick succession. It's kind of ridiculous, but.. I couldn't find any alternative. Edit: Wonder if it would be worth wrapping something like this up into some kind of a self-hostable proxy service. You'd provide the idempotency key in a header and it would do the rest
- rbarnes01 2y agoGreat timing, I was just looking into Mautic. If I have multiple brands, would I need to set up a separate instance for each one?
- nrabulinski 2y agoBased on the title I thought it was something I could selfhost on my own metal, but the first sentence says > Plunk is an open-source email platform built on top of AWS SES. I’m out. That’s everything I needed to know about this project to never look at it again.
- mirzap 2y agoYou host it yourself. It's an email marketing platform (not an email server), but you use AWS SES as an email infrastructure because it is cheap and reliable. You cannot build or host your own infrastructure since emails are hard these days, you use AWS SES or alternative to send emails like most of these services and apps do. It's so easy to get blocked or blacklisted by other email providers.
- PakG1 2y agoThe wording is awkward and suboptimal. If you don't know what AWS SES is, you'd easily get the wrong impression. In fact, I'd even say it's factually incorrect. It's not built on top of AWS SES. It's built to utilize AWS SES for its functionality. Slightly different, pedantic really.
- szundi 2y agoOn point though
- deleted 2y ago[deleted]
- layer8 2y ago“Platform” normally implies that it includes the infrastructure that implements the intended functionality, or what is named in the product/project name (“email platform”). In that sense the name is misleading.
- egamirorrim 2y agoLooks kind of cool. When sending a transactional email can I pass loads of custom parameters to be substituted in to placeholders in the template? I can't see anything in the docs about it.
- driaug 2y agoYou can! https://docs.useplunk.com/working-with-contacts/metadata https://docs.useplunk.com/working-with-contacts/metadata
- driaug 2y agoAll, Founder of Plunk here. Yes, Plunk is designed to work with AWS SES. I was not the one that made it hard for folks to self-host their own email infrastructure. SES is simply the cheapest and most reliable option out there. Reminder, we are not talking about a private "let's send 10 emails a day" solution. This needs to deliver marketing emails at scale. Does that mean you have to use SES, no. The code is open-source, swap it out for another provider if you truly believe that you can do it better. I'm open for contributions. That's the beauty of open-source.
- vetrom 2y agoEmail platforms are actually two platforms, composition, and delivery. In the before times, I helped build and was a lead engineer on a team building a delivery platform from scratch, with very minor composition bolted on. (For a time reference, this was before HTML email was even common.) Some of the lessons from then are very relevant still today. A big one that comes to my mind is 'idempotent' email isn't really possible, because SMTP has no 'send iff message-id has not been received' primitive. You can get to try-send-only-until-2.5.0-code, but even that can be non-trivial engineering. We went to a rather large degree of effort to do that ourselves, since repeat emails are a terrible signal, but I think thats only a marginal benefit to the larger operators. Idempotent delivery even isn't a direct benefit to advertisers or most sending actors: Primarily, for the majority of the market, they don't really care about duplicated deliveries below some statistical model, since the costs are heavily externalized. Secondarily, since those parts of the industry depend on out-of-band read-indicators, engineering to improve delivery idempotentcy doesn't reflect into a market advantage. Email's gotten prettier in the two decades since then, but its quality at every point in the stack I think has gotten worse. I routinely have to firewall whole ASNs because the bigger bulk operators (salesforce marketing cloud im looking at you) have no functional mechanism to call out particularly spammy customers, and thats after aggressive greylisting. Sure, the greylisting cuts out >95% of my spam, but the noise level on that last 5% is still horrendous. Forwarding with headers to abuse@ should be a universal paradigm but thats 99% a noop these days. Given the lesser upside and relative difficulty of the delivery problem, it seems only natural that most of the effort in email platforms these days is in composition. Even if you want to work on the delivery half, with IP reputation, aggressive antispam, and the general enshittification of all things email, the barrier to entry is orders of magnitude higher than it was in 2000. I don't want to say its impossible, but I think you'll have a bad time if you're trying to do it anywhere that doesnt have enough size/inertia or money that email receiving operators choose to negotiate with you rather than preemptively block you.