IMO nobody ever uses + in a username. If somebody ends up being in this case, he could migrate user data into a new username without the + prior to the upgrade using https://james.apache.org/server/manage-webadmin.html#Change_a_username
-- Best regards, Benoit TELLIER General manager of Linagora VIETNAM. Product owner for Team-Mail product. Chairman of the Apache James project. Mail: btell...@linagora.com Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) On Oct 11, 2023 5:38 PM, from Wojtek Enhancing MailAddress seems sensible. I'm somewhat surprised that `+` was allowed previously (I understand that given it was valid address it was allowed/accepted but still :) ). I'm wondering though, what would be the upgrade path in this case and how to possibly handle it (and if anyone ever used it like that tbh…). Wojtek On 10/10/2023 11:50, Benoit TELLIER wrote: > Yes sure. This time with the one and only MUA I should trust <3 > > Imo sub addressing are properties of MailAddress. > > user+s...@domain.tld > user+s...@domain.tld > And u...@domain.tld > > Are all 3 distinct mail addresses diverging from their sub addresses. > > We can normalize them to u...@domain.tld. > > So I think the most straightforward is to add the following methods to > MailAddress: > > ``` > record class SubAddress(String value) > > Optional<SubAddress> subAddress(); > > MailAddress normalize(); > ``` > > This should enable to implement all expected behaviours... > > A first version of this parsing could be naïve and ignore comments inside > email address, escape sequences, etc... > > Also we may have to forbid '+' usage in user names, which should likely be > documented in upgrade instructions as a breaking change. > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
