On 10/06/2021 18:43, Andreas Joseph Krogh wrote:
> 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.
So you only use the content of /protocols/imap, correct?
This means that you had been implementing / will be implementing some
mailbox-api implementation of your own, correct?
>
>
> > - 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.
@Test void arbitraryCharInLocalPart() {
assertThatCode(() -> Username.of("Whatever_I- want3$$$###_! as lons I do
not give a domain"))
.doesNotThrowAnyException(); }
The only constraint if a domain part is unspecified, is the size of 256
character and the absence of @.
To come back to your original problem, what prevents, for instance the
user scheme to be: <username>_<customer-key> ?
>
> 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.
The truth is that the IMAP stack is not independant of the James server
and as such, in another thread propose to move it back into
server/protocols folder to make this clear. While generifying the IMAP
code is noble, we will end up finding out that Username usage is
enforced at mailbox-api usage and we start getting quite inside James guts.
That being said, I think having more generic CommandParsers (that can
thus be used outside of James context) and modular IMAP Processor/
command processor would allow for greater power for people reusing this
code. This should allow people to choose precisely which part of the
IMAP stack they wish to use.
Regarding your immediate problem, I personally no problems having
Username protected to allow one to subclass it if need be. Likely this
is the simplest option here. Feel free to open a pull request.
Regards,
Benoit
>
> 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>
>
