Mail: May be incorrectly forcing initial TLS usage

[ssddanbrown]

As per solidnerd/docker-bookstack#406.

I think we're forcing TLS usage in scenarios which need STARTTLS to occur instead of TLS from the start.
Example case looks to be Gmail SMTP over port 587.

Need to check if there's a way to force STARTTLS to be started if MAIL_ENCRYPTION=tls/ssl.
Otherwise, option becomes somewhat redundant.

[ssddanbrown]

No direct way to do this. Open issue on Symfony Mailer exists.
Could implement custom transport but surface area gets quite large as would end up working around/re-implementing multiple layers (Laravel Mail Manager > Transport Factory > EsmtpTransport). Can't seem to make targeted changes due to how this is built.

Do we instead just update the docs to state the new behaviour? With MAIL_ENCRYPTION=tls/ssl forcing full TLS, and STARTTLS being used wherever otherwise announced? How do we test that?
Or do we go back to MAIL_ENCRYPTION doing nothing?

Edit with Bonus option: Fork Symfony mailer temporarily until we decide what to do, offer patch upstream.

[MattijnP]

Hi there, I think i might be experiencing this issue. The new update broke connection to the mail server.
My configuration is:

MAIL_PORT=587
MAIL_ENCRYPTION=tls

And the error i get when attempting a test email:

Error thrown when sending a test email:
Connection could not be established with host "ssl://***:587": stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:
error:0A00010B:SSL routines::wrong version number

My email server provider mentions that STARTTLS should be selected in their documentation.
Setting the port to 465 does not work, the mail server does not expose that port.
Is there a current workaround?

[ssddanbrown]

@MattijnP Setting MAIL_ENCRYPTION=null or commenting out that option with a proceeding # should act as a workaround. STARTTLS will still be used in that scenario but there's just no assurance of TLS/STARTTLS.

[MattijnP]

Thank you for your swift reply! I was just about to comment that doing exactly that has fixed my issue.

MAIL_ENCRYPTION=null

[ssddanbrown]

Tried to add custom mailer transport classes to BookStack, extending Symfony mailer where possible, but then had issues in onward testing due to hardcoded use of EsmtpTransport class, so overriding/extending would need have a very high surface area.

Went with a forked repo/package to make it easier to track changes relative to upstream. Will see if this kind of thing can be added upstream.

Changes here to be part of the next patch release.

[ssddanbrown]

Doc Updates

• Update docs for MAIL_ENCRYPTION to ensure they are correct with now added behaviour.
• Probably need to have another update note for this since it does represent a change in what our guidance previously said 😞