Hi Jerry,
For your information the problem has been definitively solved with this
ticket: https://issues.apache.org/jira/browse/JAMES-2949
As you identified it, the best way to solve this kind of problem is
'finding all situations where...'. To do this, we relied on strong
typing (introducing a Username class instead of String) and the compiler
helped us to find every place where usernames were used. Then the fix
was "just" to ensure that username is always lower case.
Hope this is solving your concern.
Regards,
Raphaël.
Le 29/10/2019 à 18:23, Jerry Malcolm a écrit :
Hi Duc, Thanks for the response.
I don't have an implementation yet. I want to be sure I do the
'right' implementation first... Here's the fundamental problem:
I don't believe there is any enforcing of case on usernames. Hence I
theoretically could have a JAMES user name of je...@malcolms.com. I do
know for certain that there is downstream code in the mailbox writing
area that IS case sensitive on the username (i.e. mailbox name) and
throws exceptions if the case passed in on the target acct name does
not match the username case. Granted we could go find all downstream
code and ensure all code is not case-sensitive. But I'm not a big
proponent of 'finding all situations where...' because there's always
going to be one place I missed, especially where there is one single
point that could alternatively fix the problem for all cases.
ToSenderFolder calls AbstractUsersRepository.getUser(...)
AbstractUserRepository.getName(...) calls asString() which returns
localPart + "@" + domain.asString()
Domain.asString() returns normalizedDomainName which is:
removeBrackets(domainName.toLowerCase(Locale.US));
So right now, ToSendeFolder is using the original case of localPart
plus lowercased domainname, which still will possibly not match the
case of the user account name and will throw the exception.
One fix is to simply localPart.toLowerCase(). But that is only good
if ALL usernames are forced to be all lowercase, which I'm not sure is
a change we want to force (unless it's already being forced).
The other fix (which I'm proposing) is for AbstractUserRepository to
convert the derived username to the correct case found in the list of
account names (JAMES_USER). Simply do a case-insensitive lookup using
"je...@malcolms.com" which will return the correct case of
je...@malcolms.com found in JAMES_USER to be returned to the caller
(e.g ToSenderFolder mailet).
My question is what is the correct way to do a 'case-insensitive
lookup of <username>' that spans all of the various implementations of
user name storage (not just JPA/JDBC, etc).
Thanks
Jerry
On 10/29/2019 3:15 AM, Duc Tran wrote:
Hello Jerrry, can you provide me a block of code of the
implementation, I didn't found the place where it lowercases the sender.
I had looked in `UserRepository.getUser(MailAddress)` implementations
(`AbstractUsersRepository`, `ReadOnlyUsersLDAPRepository`)
Or if better, you can open a pull request with a new test to prove
you argument, so we can get what you want to describe quickly
Duc Tran
On 28/10/2019 04:40, Jerry Malcolm wrote:
My previous post explains a problem when there are capitalization
inconsistencies between the target acct name and the user name. I've
traced through the code and see how this is happening:
The "To" and "Sender" fields can be any case: je...@xyz.com.
usersRepository.getUser(sender) lowercases the domain portion of the
address, but does not lowercase the name portion of the address. It
will return je...@xyz.com, which has no correlation to the actual
account name. This results in the mailbox "ReadOnly" exception
which actually means mailbox not found.
I believe the usersRepository.getUser(sender) should do a lookup in
the usersRepository and return the actual user name and case from
the repository. And if the derived 'user name' doesn't match an
account, I think an error should be returned.
I can make the changes. But again, I want to make sure I'm not
violating what was intended with this function. I just need
confirmation that what I'm proposing is correct.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
