I haven't tested this yet, but it's tentatively as simple as the following:

        ssl      = settings[:enable_ssl]
        starttls = settings[:enable_starttls]
        ssl      &&= Hash.try_convert(ssl)      || {}
        starttls &&= Hash.try_convert(starttls) || {}

        imap = Net::IMAP.new(settings[:address], port: settings[:port], ssl: ssl)

        imap.starttls(starttls) if starttls

Some mail servers use self-signed certificates. There is not much wrong with that because they mainly care about encryption (which self-signed provides), and care less about MITM (because that's pretty rare on server to server communication). So I would keep the default VERIFY_NONE. If we do decide to change it then make sure to update the major gem version number, because this will break stuff for some people.

This library is used in plenty of situations where the identity of the remote server cannot be safely assumed without verification.

Although I understand this will be considered a breaking change by some people, as far as I'm concerned this is shocking behavior. It's broken for everyone now, to put it mildly. Fixing security bugs this severe should not cause a major version bump for the simple reason that a major version bump will prevent users from receiving the security fix. Every bugfix changes behavior, by definition, and that always runs the risk of being backward incompatible for someone. The API is compatible and it should only affect servers or clients that have been misconfigured.

We might not have been surprised by this as the default in 2012 (unfortunately). But in 2023, there is frankly no excuse for a TLS client to not verify the server's identity by default. If users can't figure out how to set up Let's Encrypt or add a ca_file or ca_path to their SSLContext, then they should be forced to explicitly ask for VERIFY_NONE. This is how nearly every other piece of client software has worked for over a decade.

From RFC-3501 (2006):

During the [TLS] negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate that the server's identity is suspect.

For the purposes of a library like this gem, requiring the user to add an explicit verify_mode: OpenSSL::SSL::VERIFY_NONE to their configuration would satisfy the "explicit user confirmation" requirement. And, fortunately, PR #1587 should make it relatively easy for users who want to do so. 🙂 (Although, why not set ca_file instead?)

Also, for what it's worth, net-imap v0.4.0 was released last week, and it does include ruby/net-imap#175. Please let me know if PR #1587 needs any changes. I could even make it slightly simpler to disable host verification, if that's deemed necessary. 😉

I asked Google Bart about the he number of mail servers with a self-signed certificates, and after some prodding it came up with 7%, stating that most of those would be on internal corporate networks (where you can't easily get a certificate). No idea about the accuracy. Anyway, I'm fine with the PR as it stands, I'm sure the people who need it can find a way to disable verification again, but the mail gem maintainers are the ones to convince.

I'm sure the people who need it can find a way to disable verification again

I'm currently working on SASL-related PRs for both net-smtp and net-pop. And, although net-imap has deprecated this particular call signature (Net::IMAP.new(host, port, true, ca_certs, verify)) in favor of the ssl: ssl_context_params, I notice that net-smtp uses has tls_verify and tls_hostname keyword params, in addition to ssl_context_params.

So, if it's important, I think it's fine to add tls_verify: false as a shortcut for ssl_contect_params: {verify_mode: OpenSSL::SSL::VERIFY_PEER}.

FYI the deprecation warning in Net::IMAP has appeared. I appreciate the discussion above regarding 'breaking changes', but if this issue isn't addressed one way or another reasonably shortly all use of IMAP by users of this library will break.