朱超 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