Show HN: We made a CLI and API to automate inbound email
10 comments
Founder here, we've been hard at work getting an API going so that people can get programmable email addresses. It's been a surprisingly complex project, because email has a lot of legacy around it.
Would appreciate some feedback and tough questions!
Would appreciate some feedback and tough questions!
Given that Zawinski's Law of Software Envelopment[0] still seems to hold true, this all looks super powerful.
What type of uses does the CLI have? Is it for triggering actions?
One thing I think would be cool is if I could write a program that would run on one of my servers that would execute some automation when mailscript triggers an action. I assume there is some generic webhook support in mailscript that I could use to implement this, but the automation I'm thinking of is not the kind of thing I'd want to expose as a web-hook (like alarm remediations) so I guess I'd be looking for something more secure.
Typing that out gave me another idea for a potential category of actions: AWS (and other cloud providers). I could implement this on my own with the previous feature, but if it makes sense it could be cool to have them baked in if the user provided creds for a AWS API user with some IAM roles and let me template API calls to be run as actions.
A less glamorous but very interesting use case to investigate might be Linux kernel maintainers, whose workflows are heavily based around email (e.g. the use of git send-email [1] and all of the conventions in the Submitting patches guide[2]).
This looks like fun and I can totally imagine some use cases for this with personal projects. Excited to see where this goes!
[0] "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." -- Jamie Zakinski [1] https://www.kernel.org/doc/html/v4.17/process/email-clients.... [2] https://www.kernel.org/doc/html/v4.17/process/submitting-pat...
What type of uses does the CLI have? Is it for triggering actions?
One thing I think would be cool is if I could write a program that would run on one of my servers that would execute some automation when mailscript triggers an action. I assume there is some generic webhook support in mailscript that I could use to implement this, but the automation I'm thinking of is not the kind of thing I'd want to expose as a web-hook (like alarm remediations) so I guess I'd be looking for something more secure.
Typing that out gave me another idea for a potential category of actions: AWS (and other cloud providers). I could implement this on my own with the previous feature, but if it makes sense it could be cool to have them baked in if the user provided creds for a AWS API user with some IAM roles and let me template API calls to be run as actions.
A less glamorous but very interesting use case to investigate might be Linux kernel maintainers, whose workflows are heavily based around email (e.g. the use of git send-email [1] and all of the conventions in the Submitting patches guide[2]).
This looks like fun and I can totally imagine some use cases for this with personal projects. Excited to see where this goes!
[0] "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." -- Jamie Zakinski [1] https://www.kernel.org/doc/html/v4.17/process/email-clients.... [2] https://www.kernel.org/doc/html/v4.17/process/submitting-pat...
Thanks for the kind words. I'd love to hear more about the use cases. Anything we can help you dev? Please let us know if you get started!
I have used the MailScript solution, cli and api, for a project. I never thought someone would make such a easy to use integration for email sending.
I would say there's no other so easy solution out there. I will follow the project close with great expectations!
I would say there's no other so easy solution out there. I will follow the project close with great expectations!
Thanks Artur! We've been very happy to help your team automate their GitHub emails
Congrats, looks like a solid project, email is indeed full of legacy stuff to work around so props on that.
I realized pricing page is a clone of index, maybe you could get rid of it since it's not that much needed for your layout
I realized pricing page is a clone of index, maybe you could get rid of it since it's not that much needed for your layout
Oh thanks for the feedback! Have you tried it out yet?
Been really interesting to watch you grow. Can't wait to see what you innovate next!
Mailscript lets you create programmable email addresses. It works headless, via the CLI, API (we use Swagger to support most languages). You can even run it as a daemon on a server (to run functions when emails arrive).
Once you get [email protected], you can create as many aliases as you'd like (including on the fly support for *@username.mailscript.com). Just like in Gmail, we support adding . or +. Every address gets an SMTP key as well, so you can use your favourite email client e.g. Gmail...
We've been working hard on making the CLI and API easy to understand, and take a trigger/actions approach. We even have parsers for GitHub emails (so you can automate Issues, PRs, Actions). You can see what the code looks like in our templates: https://github.com/mailscript/cli/tree/main/packages/templates
Example use cases: - send Zabbix alerts to SMS if 2 messages in one minute! - post Github releases to Discord - save pdf attachments to Google Drive - create shared email addresses You can even collaborate on your email infrastructure on GitHub by exporting it as a YAML file.
If you'd like to learn more: Docs: https://docs.mailscript.com API playground: https://api.mailscript.com
We'd really like to hear your feedback, especially the harsh criticism. If you'd like any help with building automations, we'll take the time to help you code them. Feel free to ask for help on our Discord (https://discord.gg/US24HAVYq2) or at [email protected]!