Mark Sapiro writes:
On 1/16/23 18:55, 朱超 wrote:
Hi, When I subscribe the email list in Subscription Policy is confirm, Some problems happen in here： 1.Some mail mua reject send the confirm the message, because the length of recipient is too long. for exmaple: requirements-confirm+9605556e0b35a5da280c1de0d34a3e6f770f8ea5@domain, and the mail mua reject to modify about this.
The default English template says in part:
Before you can start using GNU Mailman at this site, you must first confirm that this is your email address. You can do this by replying to this message.
Or you should include the following line -- and only the following line -- in a message to $request_email:
confirm $tokenI.e. It gives an alternative method if
replydoesn't work. You can provide a custom version of this template with different wording if you think you can improve it.
The problem is the reply address, though. Changing the template to suggest only the "confirm $token" in body method doesn't help people who hit R expecting that should work, especially since many "user fiendly" (misspelling intentional) MUAs don't display the address. Avoiding that requires code changes, I guess?
2.It is inconvenient for users to use. Many people will mistakenly think that after clicking the subscribe button, it will be successful, and they will not process the email.
step, you can set Subscription Policy to Open, but then anyone can maliciously subscribe third parties to the list.
*Please* do not do this if your server is exposed to the Internet. There are bots that search for such servers, and sell lists of them to people who want to DOS mailboxes. You may find yourself banned across the Internet.
The only real alternative to confirmation is approval by moderators. I believe Mailman 3 offers that alternative as Mailman 2 did, can't check at the moment.
Regarding the discussion on the subscription method of the mailing list, should we consider optimizing the subscription method of the mailing list, for example:
- use the method of sending a verification code to subscribe by email，When you receive the verification code sent by the mailing list and fill it in again, you can subscribe successfully。
How is this different from the present method.
Just wording. I think they are thinking of the "invite" option that was provided in Mailman 2 mass subscribe (again, I think Mailman 3 retains it but I never ever used it so I don't recall for sure). But it doesn't make sense for a user-initiated interaction.
If you want, you can make a custom template and include something like:
Alternatively, you can confirm by going to the URL
https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token
If I understand the OP's PoV correctly, I think I would change the list information page to say "Send a personal invitation to join the list to [email address here]. If you aren't a subscriber, you can invite yourself." And change the word "confirm" in the confirmation template to "subscribe".
We don't include that in the default template because Mailman core doesn't know if you even have a web UI or how to access it if you do.
We should fix that, at least if the web interface is Postorius (wishlist, assigned to me): https://gitlab.com/mailman/mailman/-/issues/1055
@mark https://gitlab.com/mailman/mailman/-/issues/901 Maybe we can close this? I'm not sure why it was left open since there's no action proposed for Mailman improvement.
- use the email to send a connection to confirm the subscription，People click the link to be redirected to a confirmation page to subscribe to the email。
See above.
Indeed, AFAICS almost everything the OP is suggesting amounts to an identical procedure as far as the Mailman server is concerned, it's just described to the subscriber differently. The one exception is the suggestion to eliminate the confirmation step, and while that is supported, it's quite likely to cause problems for third parties and eventually for the Mailman site unless you have an alternative ground source of truth such as an employee database.
Steve