You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Raphael Ouazana (Jira)" <se...@james.apache.org> on 2021/09/01 14:40:00 UTC

[jira] [Commented] (JAMES-3643) VirtualHosting: using both bob@domain.tld and bob as a connection identifier

    [ https://issues.apache.org/jira/browse/JAMES-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408204#comment-17408204 ] 

Raphael Ouazana commented on JAMES-3643:
----------------------------------------

Wouldn't it be more straightforward to allow configuring a default domain when virtual hosting is on?

> VirtualHosting: using both bob@domain.tld and bob as a connection identifier
> ----------------------------------------------------------------------------
>
>                 Key: JAMES-3643
>                 URL: https://issues.apache.org/jira/browse/JAMES-3643
>             Project: James Server
>          Issue Type: Improvement
>          Components: IMAPServer, POP3Server, SMTPServer, UsersStore &amp; UsersRepository
>    Affects Versions: 3.6.0
>            Reporter: Benoit Tellier
>            Priority: Major
>             Fix For: 3.7.0
>
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> Following this message: https://www.mail-archive.com/server-dev@james.apache.org/msg70640.html
> This is a problem I had during the last deployments I did carry over: explaining people their credentials were *bob@domain.com* and not *bob* as they had the habit of. (A I turn on virtual hosting then I do need to have the domain name for usernames)
> Recently I and my team at Linagora had been tasked to support both *bob* and *bob@domain.com* connection identifiers for the POP3 protocol, which we did implement in a private (tailor-made) project. 
> However, we strongly believes this would also benefit the Apache project as well (removes some barriers for the initial migration), thus would propose adoption here too.
> h3. Design
>  - *UsersDAO* class can list username with a given localpart
>  - *UsersReposiotry::getUserByName* could then attempt a resolution when virtualhosting is enabled but the username is only a local part:
>        - The list of user with that local part is empty -> not found
>        - The list of user with that local part have one item -> return it
>        - The list of user with that local par several items -> fail (ambiguous)
>  - We then adapt SessionProvider to rely on that code path
> Local part resolution for JPA and Memory is trivial, requires one projection with Cassandra, requires one more configuration field (uid) for LDAP.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org