Mail: May be incorrectly forcing initial TLS usage #3896

New Issue

OVERLORD · 2026-02-05T07:47:44+03:00

OVERLORD commented

2026-02-05 07:47:44 +03:00

Originally created by @ssddanbrown on GitHub (Jul 3, 2023).

As per https://github.com/solidnerd/docker-bookstack/issues/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.

Originally created by @ssddanbrown on GitHub (Jul 3, 2023). As per https://github.com/solidnerd/docker-bookstack/issues/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.

OVERLORD added the 🐛 Bug 📖 Docs Update 🏭 Back-End labels 2026-02-05 07:47:44 +03:00

OVERLORD closed this issue

2026-02-05 07:47:46 +03:00

OVERLORD commented

2026-02-05 07:47:50 +03:00

@ssddanbrown commented on GitHub (Jul 3, 2023):

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.

@ssddanbrown commented on GitHub (Jul 3, 2023): No direct way to do this. Open issue on [Symfony Mailer exists](https://github.com/symfony/symfony/issues/48297). 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.

OVERLORD commented

2026-02-05 07:47:57 +03:00

@MattijnP commented on GitHub (Jul 4, 2023):

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?

@MattijnP commented on GitHub (Jul 4, 2023): 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?

OVERLORD commented

2026-02-05 07:47:58 +03:00

@ssddanbrown commented on GitHub (Jul 4, 2023):

@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.

@ssddanbrown commented on GitHub (Jul 4, 2023): @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.

OVERLORD commented

2026-02-05 07:48:01 +03:00

@MattijnP commented on GitHub (Jul 4, 2023):

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

MAIL_ENCRYPTION=null

@MattijnP commented on GitHub (Jul 4, 2023): Thank you for your swift reply! I was just about to comment that doing exactly that has fixed my issue. ``` MAIL_ENCRYPTION=null ```

OVERLORD commented

2026-02-05 07:48:06 +03:00

@ssddanbrown commented on GitHub (Jul 4, 2023):

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 commented on GitHub (Jul 4, 2023): 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](https://github.com/ssddanbrown/symfony-mailer) 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.

OVERLORD commented

2026-02-05 07:48:10 +03:00

@ssddanbrown commented on GitHub (Jul 4, 2023):

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 😞

@ssddanbrown commented on GitHub (Jul 4, 2023): ### 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 :disappointed:

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#3896