magento2
magento2 copied to clipboard
SMTP mail send with tls and 2.4.8
Preconditions and environment
- Magento version: 2.4.8
- Using an external smtp server for email sending
Steps to reproduce
Setup the SMTP config as following
- Transport: SMTP
- Host: url.to.smtp.host
- Port: 587
- SSL: TLS
Expected result
Email is sent without further issues.
Actual result
We get the following error:
error:1408F10B:SSL routines:ssl3*get*record:wrong version number <] []
When we set up the config with 567 and SSL: SSL or none then emails are sent but according to the smtp server the port 567 should be setup as tls.
This seems to be an change in how emails are sent in the switch from Laminas to Symfony.
Additional information
No response
Release note
No response
Triage and priority
- [ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- [ ] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- [ ] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- [ > Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Hi @dmanners. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.
- For more details, review the Magento Contributor Assistant documentation.
- Add a comment to assign the issue:
@magento I am working on this - To learn more about issue processing workflow, refer to the Code Contributions.
Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.
Hi @engcom-November. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
- [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
- [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
- [ ] 3. Add
Area: XXXXXlabel to the ticket, indicating the functional areas it may be related to. - [ ] 4. Verify that the issue is reproducible on
2.4-developbranchDetails
- If the issue is reproducible on2.4-developbranch, please, add the labelReproduced on 2.4.x.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here! - [ ] 5. Add label
Issue: Confirmedonce verification is complete. - [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.
This seems to be related to an old symfony github issue https://github.com/symfony/symfony/issues/34846
Hi @engcom-Hotel. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
- [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
- [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
- [ ] 3. Add
Area: XXXXXlabel to the ticket, indicating the functional areas it may be related to. - [ ] 4. Verify that the issue is reproducible on
2.4-developbranchDetails
- If the issue is reproducible on2.4-developbranch, please, add the labelReproduced on 2.4.x.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here! - [ ] 5. Add label
Issue: Confirmedonce verification is complete. - [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.
Hello @dmanners,
Thanks for the report and collaboration!
We have tried to reproduce this issue in the latest development branch i.e. 2.4-develop and it seems the issue is reproducible for us:
main.ERROR: Transport error while sending email: Connection could not be established with host "ssl://localhost:1025": stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:
error:0A00010B:SSL routines::wrong version number [] []
Hence confirming the issue.
Thanks
:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-14883 is successfully created for this GitHub issue.
:white_check_mark: Confirmed by @engcom-Hotel. Thank you for verifying the issue.
Issue Available: @engcom-Hotel, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.
I encountered this same issue (inability to send mail via my 3rd party SMTP server) upon upgrading from Magento 2.4.7 to 2.4.8 version.
Magneto defaults to using TLS1.3 for STARTTLS connection to smtp servers on port 587. The TLS 1.3 protocol itself is designed with backwards compatibility, allowing it to negotiate with TLS 1.2. If a client initiates a TLS 1.3 handshake with a server that only supports TLS 1.2, the server will respond indicating it only supports 1.2. The client can then decide to fall back to TLS 1.2 or abort the handshake. Many SMTP servers only support TLS 1.2 or earlier (for example, the ubiquitous MS Windows Server versions prior to 2022.)
The upgrade to Magento 2.4.8 included a change from the (abandoned and unsupported) Laminas library laminas-mail module to the supported Symfony library Mailer module. Apparently Magento 2.4.8 does not automatically fallback to TLS1.2 should the TLS1.3 encryption negotiation fail. Laminas handled this circumstance (perhaps silently falling back to TLS 1.2 or no encryption) while Symfony does not.
We discovered this because we used a 3rd party SMTP mailer named Postmark that specializes in high deliverability of transactional emails in volume. Postmark relies upon Amazon as it's backend. While AWS introduced support for TLS 1.3 over a year ago, it is up to the AWS customer (i.e. Postmark in this case) to configure their encryption certificates. As of this writing, Postmark has not configured a valid encryption certificate for TLS1.3 on AWS, thus encryption will fail although AWS itself does support TLS1.3 encryption protocol. The SMTP server support for TLS1.3 and TLS1.2 can be easily tested using openssl commands.
openssl s_client -starttls smtp -connect smtp.postmarkapp.com:587 -tls1_3 connection fails because there is no valid certificate.
openssl s_client -starttls smtp -connect smtp.postmarkapp.com:587 -tls1_2 connection succeeds
While the RFC for port 587 doesn't explicitly require encryption, it is strongly recommended and often enforced. A less than desirable, but immediate, work around is to send without encryption via the deprecated port 25. An alternate workaround is to configure the Magento SMTP settings to not use encryption when sending email via port 587 with Stores > Configuration > Advanced > System > Mail_Sending_Settings > SSL = None.
Unfortunately, the unencrypted workarounds being successful relies upon the SMTP server NOT enforcing encryption. Well administered secure SMTP servers often block port 25 (the traditional, unencrypted port) and require email clients to use port 587 with encryption (i.e. STARTTLS) for sending emails. FYI, not being able to send email via an encrypted SMTP server would likely be considered a HIPAA compliance violation, see https://www.hipaajournal.com/hipaa-encryption-requirements/
If encryption is an a requirement, either update the server to properly negotiate a TLS 1.3 connection or switch to a different smtp server that is properly configured to support TLS 1.3, For example...
Sendgrid works with TLS 1.3... openssl s_client -starttls smtp -connect smtp.sendgrid.com:587 -tls1_3
Mailgun works with TLS 1.3... openssl s_client -starttls smtp -connect smtp.mailgun.com:587 -tls1_3
A preferred solution would be to patch Magento to offer a configurable choice to force a specific TLS encryption version for SMTP settings... i.e. something like Stores > ... > SSL = "None", "SSL", "TLS 1.2", "TLS 1.3" [Since you are in the neighborhood, Magento's label of the configurable field "SSL" is an archaic misnomer, it should be more properly be labeled something like "Encryption" or "STARTTLS"]
This problem is indeed correctly denoted as being P1 Critical because depending on your circumstances there might be no good workaround and you might not be able to send email from Magneto 2.4.8 following an upgrade.
Hi @dmanners,
Adobe Commerce Engineering team started working on this issue. We will reach out to you if we need more information and you will get notified once the issue is fixed. Please leave comments for any further questions.
Thank you!
Hi @dmanners,
We’ve delivered the fix as part of the Adobe Commerce 2.4.9 release: Commit Reference In addition, the same fix has been included in the upcoming 2.4.8-p2 release, which is planned for GA in August. We are also preparing a quality patch that will soon be made available for 2.4.8 and 2.4.8-p1 to ensure broader compatibility. For immediate resolution, you can apply the hotfix - github-39947-smtp-mail-send-with-tls.patch.
github-39947-smtp-mail-send-with-tls.patch
As the fix has been delivered across supported channels, we are closing this issue for now. Please feel free to reopen it or reach out if you have any further questions.
Thank you!
The link to the commit reference in the message above is incorrect. Here is the correct link: https://github.com/magento/magento2/commit/61170a49783ef743e92c39d88f16fd9fdeb8af00