Well, if your SMTP server does not support STARTTLS, why would it advocate STARTTLS in its capabilities ? That's expliictly against the spec.

The symfony/mailer component will use STARTTLS only if the SMTP server advocates that it supports it (and we are not already using a TLS connection to that server as double encryption would be useless).

We've had similar issues with maildev and decided to not fix this on Symfony's side, see #34242.

Hallo @derrabus @stof,

I found this issue here and I think this is a realy bad behaviour.
We had the issue that a wrongly configured SMTP-Server but we where not able to get the administrator of the server to fix it. So we had no chance to get the application running only by removing th "!" infront of the if clause.

So I had to explain the user that he can't use the application because of his wrong configured SMTP-Server.

I know that in a perfect world this is the right way, but there a a lot of administors out there who are not able to configure a SMTP-server the correct way.
I hope you can build this switch to enforce disable TLS.

@h2Entwicklung note that removing the ! will not fix the issue: it will make your connection work with your broken server but will break usage with spec-compliant servers.

In our case app is hosted on windows server, in internal corporate network with some kind of proprietary SMTP gateway that "ensures email security", and we can not use anything else. Of course it reports STARTTLS capability, but does not work with PHP.

We have mitigated this by creating copy of EsmtpTransportFactory that supports only "smtp" scheme and always passes false as $isTls argument to new EsmtpTransport instance. Instruction for registering custom mailer transports: https://albertmoreno.dev/posts/creating-custom-symfony-mailer-transports/

Well, if your SMTP server does not support STARTTLS, why would it advocate STARTTLS in its capabilities ? That's expliictly against the spec.

The symfony/mailer component will use STARTTLS only if the SMTP server advocates that it supports it (and we are not already using a TLS connection to that server as double encryption would be useless).

See the use-case described above in nextcloud/server#39452.

The fact that the smtpd announces STARTTLS capability does not mean that it has a valid certificate for e.g. private IPs or domains that are resolved only internally.

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

We have the same problem. Server admin says he can't/won't change the config so the application is unable to send any emails. Explicit option like in swiftmailer encryption=false would be nice.

Can you take a look at #53545 (comment) and provide some feedback if updating the stream context as described there does work?

Thats not really a solution as this would mean to change all code pieces where mails are sent. We need an option to globally enable/disable this via config.

Can you please try it nonetheless so that we can at least figure out a potential pass on how to implement this feature?