Bug 1868041

Summary: Enable sendmail to stop using STARTTLS after a certain amount of previous failures
Product: Red Hat Enterprise Linux 8 Reporter: Daniele <dconsoli>
Component: sendmailAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED ERRATA QA Contact: Patrik Moško <pmosko>
Severity: medium Docs Contact: Prerana Sharma <presharm>
Priority: high    
Version: 8.2CC: jskarvad, lmanasko, pmosko, presharm, psklenar, tkorbar
Target Milestone: rcKeywords: FeatureBackport, FutureFeature, Patch, TestCaseProvided, Triaged
Target Release: 8.0Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sendmail-8.15.2-33.el8 Doc Type: Enhancement
Doc Text:
.Sendmail now supports `TLSFallbacktoClear` configuration With this enhancement, if the outgoing TLS connection fails, the sendmail client will fall back to the plaintext. This overcomes the TLS compatibility problems with the other parties. Red Hat ships sendmail with the `TLSFallbacktoClear` option disabled by default.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 15:51:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1894575    

Description Daniele 2020-08-11 13:30:48 UTC
Description of problem:
We would like to have the possibility to enable sending mails to smtp servers if TLS handshake fails during SMTP negotiation. 

Currently, the mail is never delivered unless the workaround mentioned in https://access.redhat.com/solutions/63306 is applied and TLS is explicitly disabled for specific site.

Would it be possible to integrate the sendmail patch http://www.sendmail.org/~ca/email/patches/tls_failures.p1 or confTLS_FALLBACK_TO_CLEAR option mentioned in 8.16.1 release? Described on
https://marc.info/?l=sendmail-announce&m=159394546814125&w=2

Version-Release number of selected component (if applicable):
8.15

How reproducible:
100%

Actual results:
A mail is never delivered if the TLS handshake fails.

Expected results:
have the possibility to enable sending mails to smtp servers if TLS handshake fails during SMTP negotiation. 

Additional info:
A patch for this already exists upstream (http://www.sendmail.org/~ca/email/patches/tls_failures.p1) and seems to be part of the 8.16.1 release (https://marc.info/?l=sendmail-announce&m=159394546814125&w=2). Downstream, we're shipping 8.15 and the only current workaround is to disable TLS completely: https://access.redhat.com/solutions/63306

Comment 2 Jaroslav Škarvada 2020-08-11 13:53:31 UTC
It seems upstream dropped tls_failures used in the mentioned patch and switched to the confTLS_FALLBACK_TO_CLEAR. I think we should backport confTLS_FALLBACK_TO_CLEAR to be consistent with the upstream. Also I like the confTLS_FALLBACK_TO_CLEAR approach more, because it's better configurable and it cannot happen that with the default configuration after the 5 re-tries it will switch to the plain connection as with the original patch. Such behaviour could surprise customers.

The backport of confTLS_FALLBACK_TO_CLEAR is doable and it doesn't seem to pose additional risk.

Comment 9 Jaroslav Škarvada 2020-10-15 23:05:14 UTC
There is possible security aspect of this backported feature. With the TLSFallbacktoClear enabled the attacker, if capable of doing the MITM attack, could malform the TLS packets which will lead to downgrade of the SMTP connection to the plaintext. Then the attacker will be able to read the content of the outgoing e-mails. I think this should be emphasized in the release notes for customers to know the risk of enablement of this features. We will ship sendmail with this feature disabled by default.

Comment 33 errata-xmlrpc 2021-05-18 15:51:09 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (sendmail bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1858

Comment 34 Red Hat Bugzilla 2023-09-15 00:46:17 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days