Ralf Bergs writes:

This conservative approach at some point stops working. Looking through the Changelog: FAM/Gamin was replaced with inotify in 2021. I do not remember what versions are in Debian, but I'm pretty sure they're even older than that.
Debian stable is using "1.0.16" currently, which is from March 2021. Duh. :-(

And the next release was the one that replaced FAM/Gamin with inotify. Very unfortunate timing.

The same release of Courier that switched to inotify was also the release that implemented the TLS ALPN extension (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation),

A number of self-promoting, mostly vacuous "security scanners" detect lack of ALPN support as a security issue.
I work as a security guy in my day job, and I would not buy into that assessment.

This is where I'm going to disagree. The entire purpose for having ALPN is when:

1) You have a proxy, say an HTTPS proxy, And let's say the proxy is to a network that contains only HTTPS servers that are deemed secure.

2) The proxy does anything that you want it to do. Including telling it to "CONNECT internal_lan_hostname:993", or whatever the actual syntax is, I'm too lazy to look it up.

3) The proxy obediently makes the proxy connection to the IMAP server.

With the ALPN extension it will be the IMAP server that'll turn the proxy away. In any sane world if a proxy should only be connecting to HTTPS ports then the proxy should only be able to connect to HTTPS ports and reject all other connections, instead of just connecting to any random port, and making it the port's responsibility to tell it to go pound sand.

That's completely upside down, but that's the only reason for ALPN to exist.


Attachment: pgpUUcuoEuDh2.pgp
Description: PGP signature

_______________________________________________
Courier-imap mailing list
Courier-imap@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap

Reply via email to