Ron wrote:

I'm subscribed (via email to ...-request@...), however, when I go to the web page and try to log in, I get:

...

Server error

An error occurred while processing your request.

I'd expect a different result (I do not yet have an account via the web interface).

Thus far, as far as I'm aware, with Mailman 3, and the documented procedures, e.g.: https://docs.mailman3.org/en/latest/migration.html etc. for migrating from Mailman 2 to Mailman 3, though roster (membership) and archives (and or course the list themselves) get migrated over, the user web login, old passwords, their preferences, etc., as far as I can tell, none of that gets migrated over. 8-O And theoretically user just uses web GUI to create account (if they so wish), and then can use that to manage their list subscription(s), preferences, etc. And the mail interface for managing list subscriptions is very limited, mostly just subscribe, unsubscribe, and wee bit more. No passwords or anything of that sort via the mail interface.

However, seems it would be at least theoretically possible (perhaps I well take note and look into it further, and for many hundreds of users I pro'lly well ought do so), seems though user preferences aren't a one-to-one mapping between Mailman 2 and Mailman 3, much of it has one-to-one mapping, and could extract that from Mailman 2, and then theoretically set same in Mailman 3. However, also, all Mailman 2 users have a per-list password (even though there's option to change them all at once for same user), whereas Mailman 3 password is with GUI interface, global (per user), and is independent of the user even being member of any list(s). Maybe if I used a precedence pecking order for users to set 'em up in GUI? Not even sure if that's easily feasible. But if I did, could pick password in precedence order when creating such an account ..., e.g.: Announce Talk Admin Test Whichever of the existing lists, first found password for, in that preference order, could then initially set that password. Anyway, yeah, a thought. Because I do rather like the idea of users not losing most of their settings.

Reminds me, I also need to review the user's password reset options and make sure that works (e.g. if they forgot their password, as I don't think they get email reminders not can request Mailman 3 to send them their existing password).

Yeah, mail interface doesn't offer a whole lot, from the help: confirm - Confirm a subscription request. echo - Echo back your arguments. end - Stop processing commands. help - Get help about available email commands. join - Join this mailing list. leave - Leave this mailing list. stop - An alias for 'end'. subscribe - An alias for 'join'. unsubscribe - An alias for 'leave'.

And 3 of those are aliases for other commands, and echo and end are pretty trivial, and help a given. So, logically, it's basically just: help subscribe confirm unsubscribe echo end Only a half dozen truly distinct commands, and half of those are help, echo, end. So really only three biggies: subscribe, confirm, unsubscribe.

I'm also thinking next BALUG meeting: Maliman 3: Part 2 (more details, etc., and probably other related list and MTA stuff).

Well, at least Mailman 3 doesn't store user's password in the clear - yay!

And ... this post done from the web GUI (kind'a handy that, though also has its minor disadvantages too). Egad, if spammers/bots figure out how to do that, one more thing to deal with ... but spammers/bots were never that "smart" with Mailman 2, so maybe that'll (mostly?) remain a non-issue.

Oh, and "of course" ... I do it from the GUI, and there's only Reply, no Reply-All, etc. - and yeah, that makes sense, on account of sending perms and SPF and DKIM and spammers, etc., etc.