Email server update - migration from Mailman 2

[Kevin Kofler]

Am Montag, 6. Februar 2023 02:28:19 CET schrieb Neal Gompa:
> Most people expect normal proportional fonts when reading mail, not
> monospaced text. Even my email client doesn't show email in monospaced
> text by default.

But using a proportional font breaks:
* complex indentation, as I had already mentioned,
* nicely aligned text tables,
* ASCII art drawings,
making mails using any of those display incorrectly. All those constructs 
can come up in technical discussions among tech-savvy persons such as here 
on kde-core-devel. (We are not "most people".) Keep in mind that code is 
usually displayed using a monospace font, too, and that e-mails on KDE 
mailing lists are likely to contain code snippets.

I see no technical advantage in using a proportional font by default, only 
drawbacks. (And for those who want it, a JavaScript-heavy interface such as 
HyperKitty could make it switchable with one click and/or keypress. E.g., 
in KNode, you just push the X button on your keyboard to switch instantly. 
Wheeras Trojitá just always uses a monospace font for plaintext (non-HTML) 
e-mail.)

>> And finally, HyperKitty is largely unusable without 
>> JavaScript. If you turn
>> off JavaScript, significant portions of the interface just do not work,
>> whereas Pipermail was completely free from client-side code. This is a
>> regression in browser compatibility and in accessibility. HyperKitty also
>> uses cookies, Pipermail does not.
>
> This is an unreasonable demand. Most of the internet does not function
> without JavaScript today.

Most of the Internet is broken, so let us break our site too?

There are browsers that by design do not handle JavaScript, such as lynx. 
Such browsers are used in various accessibility-related contexts, as well 
as in emergency situations. E.g., what if KDE Plasma fails to start up for 
you, you are stuck in text mode, and you are looking for a solution on KDE 
mailing lists using lynx?

And the JavaScript-heavy stuff does not just require any JavaScript, but 
tends to require a very recent browser, refusing to work even on maintained 
LTS branches of browsers, such as QtWebEngine LTS (which is public and FOSS 
unlike the rest of Qt LTS). Some websites have already started breaking on 
QtWebEngine 5.15 LTS, e.g.:
* the Nextcloud PDF viewer: 
https://github.com/nextcloud/files_pdfviewer/issues/684
* Discourse: 
https://forum.manjaro.org/t/new-version-of-discourse-dropped-support-for-qtwebengine-5-15-lts/132543

The reasons why they stopped working are pretty spurious in both cases: 
Nextcloud could trivially (a one-line change) switch to the "legacy" branch 
of PDF.js which is compatible with many more browsers than the default 
build (and I also blame PDF.js for not making the "legacy" build the 
default, the current default build is only suitable for bundling in, e.g., 
Firefox and NOT for the web!), and the stricter browser check in Discourse 
appears to be entirely unnecessary (since it works when I adblock the 
browser-detection script).

If the same were to happen with HyperKitty, that would be a particularly 
serious issue for KDE mailing lists because Falkon is the official KDE 
browser and currently stuck on QtWebEngine 5.15 LTS. (Moving to Qt 6 will 
be needed to get a newer Chromium again, unless someone makes, e.g., 
QtWebEngine 6.2 LTS work with Qt 5 somehow.)

I do not see how or why it is unreasonable to expect something that has 
worked without JavaScript for decades to keep working without JavaScript. 
There are things for which it may be necessary, but displaying static 
mailing list archives is not.

>> Broken links sound like a showstopper to me. […]
>
> openSUSE developed a way to map legacy discussions on mlmmj to
> HyperKitty, while Fedora just retained the old Pipemail static pages.
> Either works.

So either solution would need to be implemented on KDE mailing lists too.

        Kevin Kofler