Re: TLS 1.3 and SNI; test script included
Matthias Andree <[email protected]>
| Newsgroups | gmane.mail.getmail.user |
|---|---|
| Message-ID | <[email protected]> |
Am 09.02.19 um 05:10 schrieb Charles Cazabon:
> Going from not supplying SNI at all to supplying SNI by default could
> break
> things regardless of whether certificate checking is in use or not; that's
> what I'm worried about.
>
> I am *not* keen on adding another abstruse configuration option to getmail
> (use_sni) to complicate its SSL configuration options even more which most
> users will not understand and will just cargo-cult their way through based on
> random forum postings ("try setting use_sni=True", "no, try setting it to
> False"). But neither am I keen on breaking working configs for getmail users
> because getmail suddenly starts sending an SNI value that their mail server
> doesn't understand or doesn't like.
>
> So if I'm going to make getmail send SNI whenever the underlying Python and
> OpenSSL versions support it, I need to know it's NOT breaking connections with
> previously-working configs.
Charles,
I know that at least two major several distributors have added SNI to
/fetchmail/ *unconditionally*, among them Fedora and FreeBSD. I take it
I should have heard of ill effects at least from Fedora by now if those
caused massive regressions on sites other than Google, but I don't see
anything relevant in Redhat's or FreeBSD's Bugzilla, and Ubuntu's
Launchpad is a mess that I don't care to wade through. I am not making
promises, but distributors seem to have chosen to take the risk.
The commonly used patch to add SNI to fetchmail, in C code, and not
directly portable to Python's IMAP library, is, for reference,
https://gitlab.com/fetchmail/fetchmail/commit/9b8b634312f169fab872f3580c2febe5af031615
HTH
Matthias