On 2021-09-20 02:11:06 +0000 (+0000), Paul Wise wrote:
[...]

Normally one would get "Connection refused" when connecting to a port
that isn't open, but at this site one gets "No route to host", as if
there is no network path to reach the host, which is clearly not true
since the HTTP port works. I wasn't aware it is even possible to have different routing for each TCP port, I guess this is a feature of
OpenStack?

No need to reach for OpenStack behaviors on this. All our servers
have IPTables rulesets using reject-with icmp6-adm-prohibited in
their default deny rules in order to avoid the complexity of
protocol-specific rejection rules. I noticed we're still using icmp-host-prohibited in our v4 rules because long ago kernels lacked
support for sending icmp-admin-prohibited (also noted in the iptables-extensions(8) manpage), but at this point we
should be quite safe to switch that so I've pushed up a change for
it just now.

That said, for IPv4 it's still an ICMP "host unreachable" error,
merely with the "admin prohibited filter" flag set, which many
clients don't do a great job of differentiating. Thankfully for
folks with working IPv6 an ICMP6 "destination unreachable" error
with "unreachable prohibited" set is often interpreted by clients as "permission denied" which is a little more obvious, but when clients automatically fall back from v6 to v4 on errors the end result isn't
much better.

If there's a reason we should prioritize an HTTPS
implementation there over other [Mailman 2] work,

User subscription passwords are transferred to the Mailman subscription/options web interface, which is on the same site as
the web mailman archives.

Yes, they are. They're also transferred unencrypted over SMTP and
MM2 can be triggered anonymously to do so at any time via a
"password recovery" form in its WebUI so long as you can guess the
E-mail address of a subscriber (trivial to do when there are also
public list archives). We debated that adding HTTPS for that
interface could actually do more harm than good by giving a false
sense of security to users who did not consider that aspect. Users
*should* be wary of the security of that service, full stop.

Thankfully, MM3 provides a modern password reset solution which
won't leak plaintext passwords to people sniffing SMTP
communications, so we do intend to add HTTPS when upgrading to that,
which ought to be fairly soon.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmFIj99fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCnKDw//UiAybo1gvSxKGoTKIAjO1A763035GF0+QGRfWNTNawiZpp6GoCMOilmG YsyTE7mCFNBr4HR/yxMMzHg21LseQF49Jki9cmSF29FpxQ7R6RKTIL2VxXuAf3ST hmB3oJEpm3Nk7d4sC2UBHJLQU5HkNR/gR7CvBawDfbx+Dt5tJ3kPUAAioiavF/BW GFelHgotUEfK2hd9srnY4M++dJDTWz7NBEvBmFM/HEM8mkmWF6ZyifeAlwQr231x MW/T1NDtASfOBAzNrbKmAl3y9cQ/awLhHs8pNcuZL9Wb7cLzUVJi8J6CkaJD2JLe nu8gCytY3vw/TB4Z3M86SlN+5rhLQJhR/6pngvNzdEZv+6Jynf4QIeBUUedwFbV0 RikMLJXpekYB5G1IuLRW/s0jRN7Xk+AGCixwXR1I+ynI0YvkmuE1XZCZc2Hp2B7V 8KzqyBaP2vzkraxpWa5czIK8HF5Y9DIk4GPI00Z+b+8xos1eVJJnwbbu3WBvdVki T/UYc4A8lbQxRmR0HKSpfnRb5mYUGqTVxZctGEhXu07VNdQabSO+Obm6vZRRfBzS 8wOkfbgxOXtDHQIR/FeZrcJDQ5qg75qIHNEbWMFNJmD1hqDuxLqdyiHFq1w9iSdL E22gxf7zPPYz76lebnZWXwTbTRjJyb3fP/+Q7PcgVcwsR8K9uLs=
=ukRF
-----END PGP SIGNATURE-----

--- SoupGate-Win32