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

Reply via email to