Hello, I think it makes perfect sense to add XOAUTH2 (and OAUTHBEARER, let's not forget this SASL mechanism too, if XOAUTH2 in implemented then OAUTHBEARER is trivial).
Great to see Roundcube working with this as a managedSieve frontend. > Maybe it would be a nice idea to abstract these command handlers behind a >common interface. There was once upon a time, long before I joined the project, a plan formaking protocols-imap more fit into the protocols-api but I am really not sure this is achievable with the current implementation IMAP do not consume upon receiving the command the input but does this as needed upon parsing, amongst other notable differences. A generic abstraction for handling SASL (~authenticate) accross all protocols could be beneficial, and I believe other mail servers do have such abstractions, but appart subttle nuances in syntax an other obstacle to this is the all protocols have no direct dependencies to the authentication layer (there is an indirection). If we succeed to identify the right APIs / abstractions in order to implement a common SASL layer as part of the protocol API, allowing code reuse and SASL modularity, without injecting too much complexity then of course , I am in favor of it. -- Best regards, Benoit TELLIER General manager of Linagora VIETNAM. Product owner for Team-Mail product. Chairman of the Apache James project. Mail: btell...@linagora.com Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) Le juil. 23, 2025 9:25 AM, de Felix Auringer <felix.auringer@giz.berlin>Hey, we are planning to run James as the mailserver for our small company. We are using Roundcube with OIDC for our employees and this works fine with IMAP / SMTP and James. However, we also want to use managesieve (e.g. for automatic out-of-office messages) but the managesieve-Server component only has plain authentication. I did a spike for the implementation of XOAUTH2 authentication and you can find the result here: github.com/apache/james-project/pull/2773 Is this a change that you would be willing to include upstream? Of course, I would make necessary changes to it after a review. While adding the authentication mechanism to managesieve, I also noticed that there are already two different implementations: one for IMAP and one for SMTP. Because command handling is also very different for those servers, I did not see an easy way for me to reuse the old implementations of other authentication mechanisms. Maybe it would be a nice idea to abstract these command handlers behind a common interface. I saw that the netty server is already reused for the different protocols (which makes TLS possible for all of them), but I think it would simplify it even more if there would be a LineCommandHandler interface (or something similar) that also unifies (parts of) the session, the authentication, connection limit handlers, and the ChannelUpstreamHandler. As far as I have seen in all these areas, the different servers for different protocols behave very similar but all have their own implementations. Best regards, Felix --- Gesellschaft für interkulturelles Zusammenleben gGmbH (GIZ) Felix Auringer IT Reformationsplatz 2 13597 Berlin Tel: 030/513 0100 00; Fax: 030/513 0100 09 giz.berlin; felix.auringer@giz.berlin Amtsgericht Charlottenburg HRB 200872 B Geschäftsführerin: Dr. Britta Marschke --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
