Thanks for you apply.
At 2023-01-18 02:50:09, "Stephen J. Turnbull" <stephenjturnbull@gmail.com> wrote:
朱超 writes:
- It is not the MTA that refuses to send emails because the recipient's mailbox is too long, but the MUA that refuses to send the email because the recipient's mailbox is too long.
That's still non-conforming to RFC 821, published in 1982. Seriously, those mail clients are garbage and I have no sympathy for their users. We're certainly willing to make some changes to Mailman to make things a little easier for mailing list owners who have to deal with such users, but there's no excuse for using those MUAs in 2023.
https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token, but he reported 404.
If you mean that literally, of course it did. example.com, and its siblings in the org, net, and edu domains, as well as all subdomains, are domains reserved for examples in documentation. They all resolve to the same IP (owned by IANA), which simply provides a web page explaining what those domains are for. There's no Mailman there. :-)
For that to get a response from Postorius, at minimum you need to substitute your Mailman web host for "www.example.com", and the list's ID (usually the same as the posting address with "." substituted for the "@") for $list_id. You may also need to change the URL path, depending on the top-level urls.py you use for Postorius.
Yes, I know why 404 is reported，The url should be postorius not be mailman3, https://www.example.com/postorius/lists/$list_id/confirm/?token=$token, and it report success. I am curious why there is no similar processing logic for unsubscribing in postorius。Can we optimize for this？
- It is recommended to modify postorius, in order to keep the logic function of the underlying mailman-core unchanged,
More important than the detailed functions of mailman-core are the original requirements and design. Core should handle email (both in and out), and Postorius should handle web requests. It's asking for trouble to have core send mail to confirm subscription requests by mail, and Postorius to send mail to confirm subscription requests by web. Among other things it violates "Don't Repeat Yourself": if we (or you) change the confirmation template in core, we (or you) need to also change the confirmation template in Postorius. But it's very easy to forget, and an annoyance for reviewers to check.
It's possible that the other core devs will overrule me on this, but you shouldn't hold your breath waiting for that. I've been very good at channeling the consensus of the devs for around 20 years now. :-)
If you use mailman-web (include postorius and django-mailman3 and django-allauth and so on) to set the template information, the template obtained by mailman-core is obtained by requesting mailman-web, so mailman-web saves the template information and can be used by postorius Used to process subscription information, which will not violate the principle of repeating yourself, For other scenarios, it may be a bit troublesome, but at present, I can use the template confirmation information to help me solve my difficulties.
What we do is to make the mailman community better and better。
Thanks
Steve
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to tom_toworld@163.com