Re: Retiring the File mail queue from James 3.7.x
+1 Le 06/09/2021 à 14:54, Jean Helou a écrit : awesome :) On Mon, Sep 6, 2021 at 1:52 PM btell...@apache.org wrote: Hello Jean, On 06/09/2021 18:42, Jean Helou wrote: Hello benoit, There are some alternatives: embedded activeMQ has zero dependencies. Furthermore migrating is easy: just migrate with an empty queue - which can be done easily with a SMTP downtime. Also the component is deprecated for 1.5 years, given the many flows it have, given that no contributors shows up to keep it alive, I advocate removal. Sounds fine to me. Maybe make sure the documentation/sample server explains how to properly configure activemq to have filesystem based msg persistence (https://activemq.apache.org/kahadb) as an inmemory only activemq would reduce the safety of the mailqueue ? KahaDB with an embedded AcctiveMQ is already the default for MailQueue (ActiveMQMailQueueFactory) for Spring and JPA-guice products. Regards jean - 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
[jira] [Commented] (JAMES-3643) VirtualHosting: using both b...@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=17410594#comment-17410594 ] Raphael Ouazana commented on JAMES-3643: I agree, but that was also my purpose, do we really want to handle this case? At which point can we ensure the two domains won't overlap regarding usernames? I've checked and you have implemented good solutions to this problem, I'm just telling that I'm not sure it's really necessary to handle these edge cases and having a simple default domain in the case of activated virtual hosting could handle most of the real use cases. > VirtualHosting: using both b...@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 > 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 *b...@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 > *b...@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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Retiring the File mail queue from James 3.7.x
awesome :) On Mon, Sep 6, 2021 at 1:52 PM btell...@apache.org wrote: > Hello Jean, > > On 06/09/2021 18:42, Jean Helou wrote: > > Hello benoit, > > > > > >> There are some alternatives: embedded activeMQ has zero dependencies. > >> Furthermore migrating is easy: just migrate with an empty queue - which > >> can be done easily with a SMTP downtime. > >> > >> Also the component is deprecated for 1.5 years, given the many flows it > >> have, given that no contributors shows up to keep it alive, I advocate > >> removal. > >> > > Sounds fine to me. Maybe make sure the documentation/sample server > explains > > how to properly configure activemq to have filesystem based msg > persistence > > (https://activemq.apache.org/kahadb) as an inmemory only activemq would > > reduce the safety of the mailqueue ? > KahaDB with an embedded AcctiveMQ is already the default for MailQueue > (ActiveMQMailQueueFactory) for Spring and JPA-guice products. > > Regards > > > > jean > > > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
[BUILD-STABLE]: Job 'james/ApacheJames/master [master] [253]'
BUILD-STABLE: Job 'james/ApacheJames/master [master] [253]': Is back to normal. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Retiring the File mail queue from James 3.7.x
Hello Jean, On 06/09/2021 18:42, Jean Helou wrote: > Hello benoit, > > >> There are some alternatives: embedded activeMQ has zero dependencies. >> Furthermore migrating is easy: just migrate with an empty queue - which >> can be done easily with a SMTP downtime. >> >> Also the component is deprecated for 1.5 years, given the many flows it >> have, given that no contributors shows up to keep it alive, I advocate >> removal. >> > Sounds fine to me. Maybe make sure the documentation/sample server explains > how to properly configure activemq to have filesystem based msg persistence > (https://activemq.apache.org/kahadb) as an inmemory only activemq would > reduce the safety of the mailqueue ? KahaDB with an embedded AcctiveMQ is already the default for MailQueue (ActiveMQMailQueueFactory) for Spring and JPA-guice products. Regards > > jean > - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Retiring the File mail queue from James 3.7.x
Hello benoit, > There are some alternatives: embedded activeMQ has zero dependencies. > Furthermore migrating is easy: just migrate with an empty queue - which > can be done easily with a SMTP downtime. > > Also the component is deprecated for 1.5 years, given the many flows it > have, given that no contributors shows up to keep it alive, I advocate > removal. > Sounds fine to me. Maybe make sure the documentation/sample server explains how to properly configure activemq to have filesystem based msg persistence (https://activemq.apache.org/kahadb) as an inmemory only activemq would reduce the safety of the mailqueue ? jean
[jira] [Closed] (JAMES-3641) A default JWT key is shipped in the default configuration
[ https://issues.apache.org/jira/browse/JAMES-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JAMES-3641. - Resolution: Fixed Merged > A default JWT key is shipped in the default configuration > - > > Key: JAMES-3641 > URL: https://issues.apache.org/jira/browse/JAMES-3641 > Project: James Server > Issue Type: Improvement > Components: JMAP >Reporter: Benoit Tellier >Assignee: Antoine Duprat >Priority: Major > Labels: security > Fix For: 3.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > A quick audit found that a JWT public key is specified in the default > configuration, which goes against the principles expressed in > https://www.mail-archive.com/server-dev@james.apache.org/msg70783.html - > namely we should not specify default cryptographic materials which could be > seen as back-doors if not replaced, and rather encourage people to generate > their owns. > Here the people having the private key (not part of the repository) could > gain JMAP access and use the given server. > This JWT public key was required for JMAP based servers to start - a > requirement I found could be relaxed. I thus propose to relax this > requirement and drop the JWT-public-key wich is of use to noone as the > corresponding private key had long been lost. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[BUILD-FAILURE]: Job 'james/ApacheJames/master [master] [252]'
BUILD-FAILURE: Job 'james/ApacheJames/master [master] [252]': Check console output at "https://ci-builds.apache.org/job/james/job/ApacheJames/job/master/252/;>james/ApacheJames/master [master] [252]" - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-3642) Buggy behavior with Android Email mobile application
[ https://issues.apache.org/jira/browse/JAMES-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JAMES-3642. - Resolution: Fixed Merged > Buggy behavior with Android Email mobile application > > > Key: JAMES-3642 > URL: https://issues.apache.org/jira/browse/JAMES-3642 > Project: James Server > Issue Type: Improvement > Components: IMAPServer >Affects Versions: 3.6.0 >Reporter: Benoit Tellier >Priority: Major > Fix For: 3.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > h3. Actual behaviour > GIVEN Samsung Email mobile application > AND connected to an IMAP account located on an IMAP James server > AND load you emails (swap down if needed) > WHEN Refresh your emails (swap down a second time) > THEN the email account is rendered empty, only emails received since are > displayed > Another refresh restores the original email list > h3. Explanation > The second refresh uses QRESYNC SELECT command with the last known > modification sequence modifier. > Thus James needs to compute the vanished responses (messages deletes since > the last known modseq). > As James do not store expunges, we should interate the supplied range and > identify the missing items, for which we will send vanished responses. > But James specifically filters out old messages from the liveness search, > which results in all messages prior to the last known modification sequence > to be considered deleted, effectively removing them from client cahe. > h3. The fix > Remove this buggy modseq condition: we should not answer that all old > messages are deleted! > Also to avoid a full scan we can detect the deletions from the UID <-> MSN > mapping of the mailbox we just selected (yeah). > h3. Alternative > We could add a projection table tracking expunged messages - along with the > modseq. > However we should store all the history of deletions - otherwize some values > as last known modseq would be rejected, and no client behaviour is specified > in the spec if so. > Also storing even more data have a bitter-sweat taste to me... -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JSPF-40) Change jSPF project entry on openspf.org
[ https://issues.apache.org/jira/browse/JSPF-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17410418#comment-17410418 ] Benoit Tellier commented on JSPF-40: URL update to http://www.open-spf.org/Implementations/ > Change jSPF project entry on openspf.org > > > Key: JSPF-40 > URL: https://issues.apache.org/jira/browse/JSPF-40 > Project: James jSPF > Issue Type: Improvement > Components: Documentation Site >Reporter: Bernd Fondermann >Priority: Major > Fix For: 1.0.1 > > > Change the project reference entry on http://www.openspf.org/Implementations: > Name: jSPF -> Apache James jSPF > Contact: "see website" -> "project mailing list" (referencing URL > http://james.apache.org/jspf/mail-lists.html) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JSPF-103) Library upgrade
[
https://issues.apache.org/jira/browse/JSPF-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JSPF-103.
---
Resolution: Fixed
The pull request is merged...
> Library upgrade
> ---
>
> Key: JSPF-103
> URL: https://issues.apache.org/jira/browse/JSPF-103
> Project: James jSPF
> Issue Type: Improvement
>Reporter: Benoit Tellier
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> [INFO] The following dependencies in Dependency Management have newer
> versions:
> [INFO] commons-cli:commons-cli ... 1.2 ->
> 1.4
> [INFO] dnsjava:dnsjava ... 2.0.8 ->
> 2.1.9
> [INFO] junit:junit . 3.8.1 ->
> 4.13-beta-3
> [INFO] log4j:log4j . 1.2.14 ->
> 1.2.17
> [INFO]
> [INFO] The following dependencies in pluginManagement of plugins have newer
> versions:
> [INFO] org.apache.maven.doxia:doxia-core . 1.2 ->
> 1.9
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JSPF-106) Create an automated build for JSPF
[ https://issues.apache.org/jira/browse/JSPF-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JSPF-106. --- Resolution: Fixed See https://ci-builds.apache.org/job/james/job/ApacheJames-JSPF/ > Create an automated build for JSPF > -- > > Key: JSPF-106 > URL: https://issues.apache.org/jira/browse/JSPF-106 > Project: James jSPF > Issue Type: New Feature > Components: Core >Reporter: Benoit Tellier >Priority: Major > Fix For: master > > Time Spent: 20m > Remaining Estimate: 0h > > Today committers needs to run test manually before merging contributions as > we did not (yet) set up any build for the JSPF components. > Also, we do not currently publish snaposhot. > We should leverage the Apache CI to set up a build for MIME4J in order to > address this issue. > I propose we inspire ourselves from the Apache James JenkinsFile. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JDKIM-40) Move mailet from JDKIM to James
[ https://issues.apache.org/jira/browse/JDKIM-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JDKIM-40. --- Resolution: Fixed Moved to james-project/server/mailet/dkim > Move mailet from JDKIM to James > --- > > Key: JDKIM-40 > URL: https://issues.apache.org/jira/browse/JDKIM-40 > Project: James jDKIM > Issue Type: New Feature >Reporter: Antoine Duprat >Priority: Major > > Mailets are James components, we should move the implementations from JDKIM > to James. > That way JDKIM will not need dependency to James and will have it's own > release cycle. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JDKIM-46) Create an automated build for JDKIM
[ https://issues.apache.org/jira/browse/JDKIM-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JDKIM-46. --- Resolution: Fixed https://ci-builds.apache.org/job/james/job/ApacheJames-JDKIM/ > Create an automated build for JDKIM > --- > > Key: JDKIM-46 > URL: https://issues.apache.org/jira/browse/JDKIM-46 > Project: James jDKIM > Issue Type: New Feature > Components: build docs >Reporter: Benoit Tellier >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Today committers needs to run test manually before merging contributions as > we did not (yet) set up any build for the MIME4J components. > Also, we do not currently publish snaposhot. > We should leverage the Apache CI to set up a build for MIME4J in order to > address this issue. > I propose we inspire ourselves from the Apache James JenkinsFile. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JSIEVE-117) Create an automated build for JSIEVE
[ https://issues.apache.org/jira/browse/JSIEVE-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JSIEVE-117. - Resolution: Fixed Done. See https://ci-builds.apache.org/job/james/job/Apache-James-JSIEVE/ > Create an automated build for JSIEVE > > > Key: JSIEVE-117 > URL: https://issues.apache.org/jira/browse/JSIEVE-117 > Project: James jSieve > Issue Type: New Feature > Components: JSieve (Main) >Reporter: Benoit Tellier >Priority: Major > Fix For: master > > Time Spent: 20m > Remaining Estimate: 0h > > Today committers needs to run test manually before merging contributions as > we did not (yet) set up any build for the JSIEVE components. > Also, we do not currently publish snaposhot. > We should leverage the Apache CI to set up a build for MIME4J in order to > address this issue. > I propose we inspire ourselves from the Apache James JenkinsFile. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
