Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for other email providers #7

Open
chris104957 opened this issue May 10, 2019 · 5 comments

Comments

@chris104957
Copy link
Owner

commented May 10, 2019

Is your feature request related to a problem? Please describe.
AWS has a lengthy sign up process and requires you to enter billing details even if you have no intention of exceeding the free limits, and submit a support request to take your account out of the sandbox before you can start sending messages.

Describe the solution you'd like
Implement support for other email backends with lower barriers to entry, e.g. Mailchip, SendGrid, etc.

Additional context
This ticket is mentioned in the product roadmap

@kontsevoy

This comment has been minimized.

Copy link

commented May 25, 2019

I would simply add SMTP support. Email sending never needed an "API", every email provider supports SMTP with TLS [Mailgun, Sendgrid, etc]. Every UNIX machine already has sendmail CLI command which is usually implemented as an alias to the underlying SMTP sender, usually exim or postfix, to send mail.

Another nice benefit is that many existing Linux tools (cron) already support sendmail, i.e. you'll be giving markdown superpowers to numerous existing utilities.

@chris104957

This comment has been minimized.

Copy link
Owner Author

commented May 25, 2019

This is probably quite easy to achieve with smtplib. Leave it with me, will get on the case as soon as I find some time

@kontsevoy

This comment has been minimized.

Copy link

commented May 25, 2019

Chris, there are two quite different options IMO:

  • Native SMTP support via smtplib. Pros: no dependencies. Cons: you will have to implement additional maildown configuration for SMTP ports, TLS, authentication, etc.
  • SMTP support via sendmail. Pros: trivial to implement (simply exec sendmail with the recipient(s) as arg(s) and pipe the message into its stdin) and compatibility with every SMTP server out there. Cons: sendmail needs to be installed (it's true for MacOS and most Linux distros).
@chris104957

This comment has been minimized.

Copy link
Owner Author

commented May 26, 2019

I can see a use case for both, and may therefore implement both, starting with sendmail (which will simply be called via subprocess). The difficulty here is refactoring maildown.utilities to support switching of backends, but once that's done the rest should be super easy

@chris104957

This comment has been minimized.

Copy link
Owner Author

commented May 26, 2019

Also, once I've done that refactoring, it becomes way easier for people to contribute their own handlers to this project

@chris104957 chris104957 self-assigned this May 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.