thank you for your reply
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. Of course, you can use the confirm $token message to dev-request@domain for confirmation. This is a comparison Troublesome process, by visiting https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token, but he reported 404.
It is recommended to modify postorius, in order to keep the logic function of the underlying mailman-core unchanged, and optimize postorius at the application layer to increase user experience; even if there is no mailman-web service or postorius service, mailman-core can still run normally. If you look at the separation of the application layer and the underlying software, I think it is possible
From: Tom
At 2023-01-17 19:44:20, "Stephen J. Turnbull" <stephenjturnbull@gmail.com> wrote:
朱超 writes:
Yes, You got it. It is too cumbersome to ask the user to write a reply email for email confirmation.
Surely clicking on "reply" then "send" is not cumbersome (unless there's a way to get rid of confirmation altogether). Your problem is that some of your subscribers can't do that.
I have not previously heard of a MTA that refuses to *send* mail because the addressee's mailbox is too long. IIRC there's a limit of 256 characters on domains, but only the (long-obsolete) recommendation that lines in the message be 998 bytes or less restricts the length of the local-part.
I don't really see a good reason to change this default because there are a number of configurations where there is no web service available. I suggest a partial remediation in the issue I just filed. (I think dealing with the rest of the issue is a Simple Matter of Programming, but the question of determining existence and status of an appropriate web service is more complex so I did address that.)
Why do you need to modify the mailman-core service， I suggest we should modify the code of the postorius,
We are not going to do that, because
- Mailman provides no guarantee that any web service is present, and we're not going to make changes that require one.
- Mailman provids no guarantee that the web service is Postorius even if there is one, and we are definitely not going to make creating compatible implementations more annoying than necessary.
Currently I have achieved it this way。
We encourage you to use your code. ;-) But using it exclusively to accomplish this change would go against several of our goals in term of separation of concerns. If we can do it in an alternative way that serves those goals, there's no point in complexifying Postorius in this way as well.
Regards, 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