Mail configuration / Adapters #232
Comments
|
Some of this is related to #49 as well. |
|
Yar, I mainly wrote it because I totally forgot that ghost-cli doesn't do any mail config. Short term anything goes, long term mail should probably be adapters, which needs work in Ghost as well. Have done 4 successful beta.1 -> beta.2 updates btw 🎉 |
refs TryGhost#232, TryGhost#216 - this is the most straight forward pass through adding mail config options - there is loads of small tweaks possible here, but they are not required E.g. - auto-set transport to smtp if any other argument is supplied - use grouping to make the output better - stronger use of implies?
refs TryGhost#232, TryGhost#216 - this is the most straight forward pass through adding mail config options - there is loads of small tweaks possible here, but they are not required E.g. - auto-set transport to smtp if any other argument is supplied - use grouping to make the output better - stronger use of implies?
refs #232, #216 - this is the most straight forward pass through adding mail config options - there is loads of small tweaks possible here, but they are not required E.g. - auto-set transport to smtp if any other argument is supplied - use grouping to make the output better - stronger use of implies?
|
Hi @ErisDS I landed on this issue from #8933. BackgroundWhen I enabled the newsletter feature in my instance of Ghost (v3.38.3), I noticed that all confirmation emails were ending up in the spam folder for Gmail accounts. I checked the docs for email config and it turns out Ghost is using the "direct mail service". To avoid the issue, I decided it would be better to switch to using a dedicated Gmail/G Suite account for all outbound emails from Ghost. I did some research and settled on creating a G Suite email address with 2LO authentication (2-legged OAuth2) enabled. Now, my challenge is that the NodeMailer shipped with Ghost bundles NodeMailer v0.7.1, which is from 7 years ago ... SuggestionPerhaps we could take a step back and come up with a design that allows us to eat our cake and have it too? I think we could arrive at a design that allows old instances of Ghost to continue with the old version of NodeMailer, while newer instances could check for the presence of a flag to use newer versions of NodeMailer. What do you think? |
|
Our bot has automatically marked this issue as stale because there has not been any activity here in some time. The issue will be closed soon if there are no further updates, however we ask that you do not post comments to keep the issue open if you are not actively working on a PR. We keep the issue list minimal so we can keep focus on the most pressing issues. Closed issues can always be reopened if a new contributor is found. Thank you for understanding 🙂 |
We haven't yet got a plan for handling mail config with Ghost-CLI.
Short term, this will need to be a configuration task. It may also be worth adding a line at the end of
ghost installtelling users to read a page on configuration, which covers the stuff ghost-cli doesn't do yet, like nginx client_max_body_size and mail.Whilst we're here, I thought I'd write down my long term idea somewhere to percolate on:
Long term, my original thought was that we would upgrade nodemailer to the new version where different kinds of mail handling are separate, and that we would use our concept of adapters to make it possible to override the default mail adapter.
Alternatively we could do a similar thing, using adapters and then use modules like mailgun-js directly instead of going through nodemailer.
Install process
Either way, we'd need some concept in ghost-cli of being able to run a command to add an adapter. Adapters would be npm modules which follow some pattern or convention.
E.g.
ghost adapter type nameorghost adapter npm-module-nameghost adapter mail smtporghost adapter ghost-mail-adapter-smtpOne idea would be to read the package.json file for the module, to verify the module is something that Ghost-CLI can understand. We already did this in the Casper package.json: https://github.com/TryGhost/Casper/blob/master/package.json#L19 with the
gpmkey.Config
An adapter would probably need to provide it's own config requirements. E.g. mailgun-js needs a domain and api key whereas the nodemailer mailgun thing has a standard format that looks more similar to SMTP config. Perhaps this is speced in a special format, maybe in the package.json, etc, or maybe all Adapters expose a function for this.. many things are possible.
Enable/disable
It may be necessary to have a set of adapter commands rather than a single one:
ghost adapter install ghost-mail-adapter-smtpghost adapter enable ghost-mail-adapter-smtpghost adapter config ghost-mail-adapter-smtpghost adapter disable ghost-mail-adapter-smtpThis is just a brain dump for now!
The text was updated successfully, but these errors were encountered: