SMTP server does not support TLS auth
While configuring SMTP server it does not accept TLS auth configuation for nodemailer. Since most SMTP servers are running on TLS authentication nowadays, it is important to have mail functionality fluent.
Doesn't nodemailer use STARTTLS by default if available?
I realized main concern is SSL support. I am trying to setup my yandex account which requires SSL first before TLS. That means on plain text greeting nodemailer does not get any reply (smtp server requires encrypted greeting).
To overcome this, i've added secureConnection: true, to strider-mailer. I am checking how strider getting ENV parameters, if everything works, I will send a pull request.
Strange enough, when I check environment parameters, although I can see my SMTP_USER is set (echo $SMTP_USER on shell), when I print process.env, I can not see it there. SMTP_HOST, SMTP_POST, SMTP_PASS is there, but only SMTP_USER is missing. For that reason I could not test my implementation, yet.
$ [email protected] strider
Somehow only above works.
https://github.com/bariscicek/strider-mailer/commit/f5146b547254080d765a5bc9844406d7cdea5d23
@bariscicek Personally, I would prefer being able to control the behavior through an environment variable instead of relying on a specific port being used. Especially since the rest of the SMTP configuration is done through environment variables as well. What do you think?
@oliversalzburg I am not an expect, but from my understanding port 465 has a special case to serve as SMTPS port. I have not tested it with an SMTP server on port 587 which looks like standard port for STARTLS and SMPTS.
Reference is here: https://en.wikipedia.org/wiki/SMTPS
Initially I thought SMTP_SECURE would be a good environment parameter, but it is a little bit ambigiuos. Port 465 has its own peculiarity on SMTPS so a check looked safe. And I did not want to introduce something more radical like an environment variable as a first bugfix. If you think it is better I do not see any issue with this.
Just send a PR. If noone else sees a problem, it should just be merged. It's probably best to get some some fix in place and your change probably works for most deployments.