hello， Discussion on how to subscribe to the mailing list
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. 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.
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。
- 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。
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 reply doesn't work. You can
provide a custom version of this template with different wording if you
think you can improve it.
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.
If you set Subscription Policy to Confirm, you are saying that the user must confirm that that is their email address. This requires sending an email requesting confirmation to that address. If you don't want that step, you can set Subscription Policy to Open, but then anyone can maliciously subscribe third parties to the list.
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. 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=$tokenWe 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.
- 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.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
At 2023-01-17 15:56:35, "Stephen J. Turnbull" <stephenjturnbull@gmail.com> wrote:
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?
Yes, You got it. It is too cumbersome to ask the user to write a reply email for email confirmation.
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.
Yes.For service security, we will not set the Subscription Policy to open
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=$tokenIf 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".
Why do you need to modify the mailman-core service， I suggest we should modify the code of the postorius, We can refer to postorius to reset the user password process， Detail, through the postorius to send email to user, and user click the url in email to confirm subscribe the email，Currently I have achieved it this way。
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
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
朱超 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
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
朱超 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.
- 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. :-)
Steve
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
朱超 writes:
Yes, I know why 404 is reported，The url should be postorius not be mailman3,
In the stock configuration both "mailman3" and "postorius" invoke the same view, and I'm fairly sure several templates invoke "mailman3" rather than "postorius". I believe the logic was that casual users will recognize "mailman3" more readily than "postorius", and similarly for "archive(s)" vs. "hyperkitty".
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。
I don't understand what you're suggesting. A subscribed user necessarily has a confirmed address, and if a web administration app is running, they can log in and with a couple of clicks unsubscribe. Unsubscribe by mail does involve a confirmation step. As explained before, the reply confirmation is surely available to core; if you want I believe you can craft email templates to use the web confirmation either as an option or the preferred method.
Can we optimize for this？
What do you mean by "optimize"?
If you mean fewer steps for the user, I believe the FAQ explains how to create a one-click unsubscription URL (at least that was possible with Mailman 2). There is a mild denial of service possibility, of course, but it doesn't involve third parties and is usually recoverable since the unsubscribe generates an email to the "victim" who can check archives in the majority of cases and easily resubscribe.
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,
No, the templates used by core and by Postorius are stored in different databases. It's true that you can use Postorius to set core's templates, but they're still stored in core's database, not in Django. They *must* be, because core needs to be able to send email even if there is no web interface at all. I suppose you could arrange that one could be set by the other. If you want to define a protocol so that any application that speaks the REST API can do this, I suppose it could be added to Mailman. But we can't depend on web administration being installed at all, and we can't depend on it being Postorius.
Steve
At 2023-01-18 13:41:56, "Stephen J. Turnbull" <stephenjturnbull@gmail.com> wrote:
Yes, I know why 404 is reported，The url should be postorius not be mailman3,
In the stock configuration both "mailman3" and "postorius" invoke the same view, and I'm fairly sure several templates invoke "mailman3" rather than "postorius". I believe the logic was that casual users will recognize "mailman3" more readily than "postorius", and similarly
for "archive(s)" vs. "hyperkitty".
ok,I got it, I use the mailman-web not is https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/urls.py, that is https://github.com/maxking/docker-mailman/blob/main/web/mailman-web/urls.py
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。
I don't understand what you're suggesting. A subscribed user necessarily has a confirmed address, and if a web administration app is running, they can log in and with a couple of clicks unsubscribe. Unsubscribe by mail does involve a confirmation step. As explained before, the reply confirmation is surely available to core; if you want I believe you can craft email templates to use the web confirmation either as an option or the preferred method.
I am thinking that we can unsubscribe in postorius without logging in. Refer to the subscription process of postorius, fill in the email address that needs to be unsubscribed on mailman-web, and send an email template to the filled email address, but the electronic template carries confirmation The url of the link, click the url to confirm and unsubscribe successfully.
Can we optimize for this？
What do you mean by "optimize"?
If you mean fewer steps for the user, I believe the FAQ explains how to create a one-click unsubscription URL (at least that was possible with Mailman 2). There is a mild denial of service possibility, of course, but it doesn't involve third parties and is usually recoverable since the unsubscribe generates an email to the "victim" who can check archives in the majority of cases and easily resubscribe.
Could you give more information about one click unsubscribe url in mailman3?
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,
No, the templates used by core and by Postorius are stored in different databases. It's true that you can use Postorius to set core's templates, but they're still stored in core's database, not in Django. They *must* be, because core needs to be able to send email even if there is no web interface at all. I suppose you could arrange that one could be set by the other. If you want to define a protocol so that any application that speaks the REST API can do this, I suppose it could be added to Mailman. But we can't depend on web administration being installed at all, and we can't depend on it being Postorius.
Yes, when mailman-web is connected to mailman-core, the core stores uri information, that is the link, not the detailed information of the template. Of course, you can read the local template file and use it by configuring related parameters.
From Tom
On mar, 2023-01-17 at 10:55 +0800, 朱超 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.
Well, if the MUA complains, it is the one that is broken. The example is within the specified limits for an address local-part in RFC 5321 (current normative specification for SMTP) section 4.5.3.1.1.
-- Victoriano Giralt Innovation Director Digital Transformation Vicerectorate University of Malaga +34952131415 SPAIN
Note: signature.asc is the electronic signature of present message A: Yes.
Q: Are you sure ?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email ?
At 2023-01-17 18:06:17, "Victoriano Giralt" <victoriano@uma.es> wrote:
On mar, 2023-01-17 at 10:55 +0800, 朱超 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.
Well, if the MUA complains, it is the one that is broken. The example is within the specified limits for an address local-part in RFC 5321 (current normative specification for SMTP) section 4.5.3.1.1.
There some message by lookup RFC 5321 and section 4.5.3.1.1 4.5.3.1.1. Local-part The maximum total length of a user name or other local-part is 64 octets.
Some MUAs are very old , and allowed from RFC2821 and not allowed from RFC5321. There is some message in RFC2821: local-part The maximum total length of a user name or other local-part is 64 characters.
-- >Victoriano Giralt Innovation Director >Digital Transformation Vicerectorate University of Malaga >+34952131415 SPAIN >================================================================== >Note: signature.asc is the electronic signature of present message >A: Yes. >> Q: Are you sure ? >>> A: Because it reverses the logical flow of conversation. >>>> Q: Why is top posting annoying in email ?
朱超 writes:
Some MUAs are very old , and allowed from RFC2821 and not allowed from RFC5321.
August 1982 old? RFC 821 "Simple Mail Transfer Protocol" dated August 1982, section 4.5.3. "SIZES" provides the following guidance:
[E]very implementation must be able to receive objects of at least these sizes, but must not send objects larger than these sizes.
- TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION TECHNIQUES WHICH *
- IMPOSE NO LIMITS ON THE LENGTH OF THESE OBJECTS SHOULD BE USED. * user: The maximum total length of a user name is 64 characters. domain: The maximum total length of a domain name is 64 characters.
At least the example you give satisfied those minimum requirements (61 characters in the local-part, don't know how many in the domain but 64 is a lot), so the MUA(s) you're dealing with don't conform to the earliest reasonable specification.
participants (4)
-
Mark Sapiro -
Stephen J. Turnbull -
Victoriano Giralt -
朱超