Files
kumomta/docs/reference
Wez Furlong fbed08567f add remember_broken_tls option
This provides a simpler and easier to use option for dealing with broken
TLS.

The back story here is that sites with broken TLS ideally should result
in a TLS failure and return us to a clear text SMTP session that we
could use for the remainder if we are in opportunistic mode.

In practice, it's not that simple:

* The rustls implementation provides into_fallible() to enable this mode
  of operation, but certain handshake errors result in the session being
  unusable once the failed handshake has been communicated
* Openssl is perfectly capable of operating this way, but the Rust
  ecosystem bindings do not expose the handshake failure in a way that
  allows the clear text session to continue

If we wanted to allow the session to communicate with the failed host in
clear text we will need to make a new separate connection for this case.

There is a concern that this will bump a connection counter in a
reputation system implemented on the destination host, but it is
reasonable to wonder if a site that has broken TLS would be sufficiently
sophisticated to employ such a system.

If we did want to allow making a new connection to the same host, it is
a bit awkward to fit into our current mx host connection plan system.

So, with all that in mind, this commit tries a slightly different
approach:

* A new `remember_broken_tls = "3 days"` field in the egress path config
  will enable an in-process cache to keep track of the site_names that
  advertise STARTTLS and for which we failed to handshake, or failed to
  re-EHLO after a handshake.

* That will cause the connection plan to move on to subsequent hosts, if
  any.  It won't cause us to re-attempt the current host.

* Subsequent connection attempts (which may be immediate if there are
  additional hosts in the current session plan) will consult the
  broken tls cache for the site, and use that to decide on the
  availability of TLS

* If we previously encountered broken TLS, we will effectively treat
  the site as not advertising TLS in EHLO, but will generate an
  appropriate error message if TLS is Required.

Since we track the breakage in a cache with per-item TTLs, you
can set the duration as appropriate to your situation.

The cache will be cleared when the process is restarted.

There is no sharing of the cache between nodes.

This is a much lower complexity solution than the existing workaround
using TSA automation rules to override the site with Disabled TLS, and
will help to minimize the number of rules for that purpose in the TSA
daemon.

Note that this commit doesn't change any behavior; we can do a followup
commit to replace those TSA rules with this mechanism.
2024-10-31 13:11:49 -07:00
..
2024-10-24 12:10:53 -04:00
2024-10-14 09:57:29 -07:00
2024-10-31 13:11:49 -07:00
2023-08-11 21:44:40 -07:00
2024-06-10 09:30:17 -07:00
2023-05-09 15:28:01 +00:00
2024-06-10 09:30:17 -07:00
2023-02-25 10:50:58 -07:00