Thanks @ntninja this looks very good, but I don't want to ship a breaking change (especially so soon after one), can we come up with a way where that's not necessary?

The only thing, I can think of is adding an additional value to tlsMode called "auto" that for bewCloud v3.x implements the new behaviour suggested here, while the null default retains the previous meaning. We could then emit a warning on startup if people have .email.port set to a value different from 465, but did not set .email.tlsMode.

For bewCloud 4.x null and "auto" will then become equivalent. (I could leave a PR open for that if you want.)

Sounds good enough?

There's no need to change the .env.sample file; email is only used for signup or MFA, nothing else, and I don't plan to use it for anything else.

The previous comment is wrong though: These variables do not (with or without this patch) enable signup email verification or multi-factor authentication via email.

Instead these variables have previously (and still do with this patch) only provided the authentication information when connecting the Mail Submission Agent. Not providing any authentication information is a better default than sending fake:fake as “credentials”.

I forgot to mention this, but without this patch connecting to the Mail Submission Agent is currently broken. This is because nodemailer will attempt PLAIN authentication if any .auth fields are present, but then the PLAIN authentication backend will (correctly) refuse to perform PAIN “authentication” without any credentials (doesn’t make sense and is, to my knowledge, prohibited by RFC).

Sounds good enough?

I might be missing something, but why can't we not allow null, default to auto, and have auto behave as it does now?

The previous comment is wrong though

I suppose you can change enable to use, then.

Sounds good enough?

I might be missing something, but why can't we not allow null, default to auto, and have auto behave as it does now?

Because null as implemented here, mean “immediate TLS on port 465, required StartTLS otherwise”, while the previous default in bewCloud is “immediate TLS on port 465, opportunistic StartTLS otherwise”.

The proposed mechanism is for “auto” (the new recommended value mentioned in sample config) to mean “immediate TLS on port 465, required StartTLS otherwise”, with the default null retaining the previous bewCloud behaviour of “immediate TLS on port 465, opportunistic StartTLS otherwise”. They can then become one and the same in bewCloud 4.

The null default value is intended is an indefinite stop-gap for backward-compatibility during bewCloud 3 only.

The previous comment is wrong though

I suppose you can change enable to use, then.

So would this be OK then?

#SMTP_USERNAME=""  # optional, if you want to use signup email verification or multi-factor with an email service requiring authentication
#SMTP_PASSWORD=""  # optional, if you want to use signup email verification or multi-factor with an email service requiring authentication

@BrunoBernardino: Commit 471a182 implements the legacy compatibility behaviour for tlsMode.

@BrunoBernardino: Should hopefully be OK now

Fixed the multi-line comment

This is live in v3.3.0!