John Harrison via Mailman-users writes:

My goal here is to have as little friction as possible for nontechies to join and participate in an email discussion list. So that means

• HTML

Supporting HTML templates would be a lot of work, not only to design and implement, but it would also induce ongoing support requests. We have long resisted doing it for those reasons.

 formatted hyperlinks in all emails including the welcome email
 to subscribe, unsubscribe, see the archives, etc.

Don't most modern email clients format email addresses as mailto: links and other URLs as links? I think for many of your members this is a cosmetic issue, not a "nothing to click" issue.

The big problem with all those links is that the major clients have decided in their infinite wisdom that supporting RFC 2369 is not worth it. RFC 2369 provides for URLs to do all those functions, leaving it up to the client to format them nicely as buttons and menu items. This would be better because users would know where to look for them since they'd be formatted and located consistently (in each client, different clients would likely do things differently).

• no need for a password ever for anything they'd want to do.

There is a plethora of "social authentication" (ie, use your Facebook, Google, Fedora, etc account to authenticate) available in Django. IIRC most of the more popular ones (eg, the ones just mentioned) are configured by default in the Mailman web applications. If not, that's easy to do.

If you have a single-sign-on system for your website, it's simple to have the webserver pass those credentials to Postorius and HyperKitty.

• A simple click to subscribe, unsubscribe, see the archives. All hyperlinks.

One-click operations are frequently used to harrass people. There is a proposal for a standard way to support them more safely but it doesn't address the harassment problem completely. It's most attractive for marketing mailing lists.

I've been playing with the welcome template and it seems maybe this can't do what I am looking for (html formatting).

As with plain text, some clients will detect those and format HTML elements even though the mail is declared plain text. But this is really risky, and has become less and less common over the past few years.

It would be possible to hack the sources to tell clients that the email is HTML, and then this would work. But I'm not interested in doing that, and definitely I'm not willing to support users of such a feature.

I'm wondering also why it's doing some sort of soft wrap with line breaks which is breaking longer urls in the template.

That's not Mailman, that's your client, I'm willing to bet. See the "Archived at:" URL from your post on Mailman Users copied below. There's a line break after "at:", but none in the URL which is 109 characters long. Also compare the URLs in the footer of the mail you'll receive through the list. If you see line breaks in any of these URLs, that's not Mailman.

Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan