På torsdag 10. juni 2021 kl. 05:09:50, skrev btell...@apache.org <mailto:btell...@apache.org> <btell...@apache.org <mailto:btell...@apache.org>>: [...] > 1. The login-parser should do just that parse the login-command and > provide the Strings /as //is/, not try to do anything meaningful og > enforce constraints on it, as Username does. Having login-parser agnostic of James internal logic would seem like a fair point to me, I can agree with that.
(We could introduce a new POJO that do not enforce constraints in order to preverve strong typing.) > > 2. The logic in Username seems flawed: > - Why a limit on length? Nothing in the protocol dictates this. James has to be working with several protocols, not just IMAP. Implementation details (JPA) might have been pushing these kind of concerns to the Username POJO. Username is not really a POJO, by definition, as it does lots more than just holding on to the "iserid". I agree that having a Username-type is cool for type-safety, but it should only wrap the "userid"-String, nothing else. > - The username used for IMAP-LOGIN is completely decoupled from > whatever <local-part> is in an email-address. Yes, they /could/ be > related but are often not, even if modern MUAs like to think so. > Username should make no asumptions about local-part/domain-part in the > provider userid. Here likely lies the root cause: contrary to (say) SMTP, IMAP so far is hard coupled with the James implementation, with hard dependencies on things like mailbox-api. We only use JAMES for IMAP. > - According to the spec the LOGIN-command is: > login = "LOGIN" SP userid SP password > userid = astring > astring = 1*ASTRING-CHAR / string > string = quoted / literal > > So any string will be valid for "userid", and it's up to the site > (where the IMAP-server is used) to interpret the userid case-sensitive > or insensitive, so JAMES show not enforce anything and just "leave it > as is". I understand that James is free to do whatever it wants with userId validation. I understand that tooling is missing to allow people to override that behaviour in James / James IMAP stack. [...] > So - I'm proposing to refactor so that Username only wraps the parsed > "userid"-String, nothing else. If validation or other stuff is needed > I think that should be handled by some other /interface/ which the > JAMES-project is free to provide a default-impl of, but it must be > possible to implement custom logic. Also proposing to pull out all the > from*-factory-methods. > > What do you think? Personally I am reluctant to weaken data validation , that is already reasonably permissive, without understanding the impacts on the code base. I do think that there is other alternatives than hard-coding logic into usernames. You could rely on custom API / classes to make the bridge between usernames and your custom logic. Do you mean "we can, as of James-3.6" or in "som future version".I don't understand how we could accomplish that in v-3.6 due to the limitations of the Username-type, which I'm describing in this thread, and that Username is used "all over" in the IMAP-API. It's an integral part of UserRepository and lots of other classes mentioned in previous emails, so it's impossible to implement an IMAP-server using James-3.6-API without using it, unless I'm missing something. Turning off virtual-hosting will also remove the limitation of the domains that as I understand is the point limiting you. The only thing which is limiting us is that Username is enforcing constraints not specified by the IMAP-standard for "userid". We don't use virtual-hosting or other JAMES-stuff, only the IMAP-stack for being able to act as an IMAP-server. We have implemented custom stuff to retrieve/store data in our custom-modelled database, and everything works well in that regards. As I've mentioned earlier, we get around this by using Base32-encoding for the "localPart" in Username, and decode it wherever we need the value, but we'd really like the restrictions enforced by it to be removed, to comply with the IMAP-standard. Thanks. -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>
--------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
