I just merged the changelog updates, this should be better now.
On 10/01/2024 11:26, Jean Helou wrote:
hmm the linked changelog doesn't list any unreleased changes is that normal
?
Le mar. 9 janv. 2024 à 09:17, Benoit TELLIER a écrit :
Hi,
I would like to propose a new vote for 3.8.1
+1
On 09/01/2024 09:17, Benoit TELLIER wrote:
Hi,
I would like to propose a new vote for 3.8.1 release of the Apache
James server.
You can find:
- The maven release staged in repository.apache.org as the artifact
#1077:
+1
On 09/01/2024 09:15, Benoit TELLIER wrote:
Hi,
I would like to propose a new vote for 3.7.5 release of the Apache
James server.
You can find:
- The maven release staged in repository.apache.org as the artifact
#1079:
Hello Jerry,
I confirm that different email applications uses the IMAP protocol in
different ways.
I confirm that some clients uses the IMAP SEARCH results upon
resynchronisation, and thus that inacurate results could result in bad
synchronisation.
That being said, having traffic capture
Hopefully rendered correctly in plain text...
-
Hello Jamers!
As part of my work at Linagora, we are looking toward
- better integrating James within our product suite and for us this
means support "Single Sign On" and "Single Log Out" for JMAP following
Hello Tung,
Thanks for the feedback.
On 03/11/2021 11:24, Tung Tran Van wrote:
> Hello Otto,
> Very interesting,
>
>> Delay on authentication failure (S)
> I will follow how it will be implemented. Right now, I think about Redis
> with expire time key-value, with key is the fingerprint of the
+1
On 23/07/2021 16:00, btell...@apache.org wrote:
> Hello all,
>
> Following a first email on the topic [1] I would like to call for a
> formal vote on Apache James Hupa retirement.
>
> [1] https://www.mail-archive.com/server-dev@james.apache.org/msg70575.html
>
> Rationnals:
> - The latest
On 21/07/2021 18:06, Quan tran hong wrote:
> Hi Benoit,
> Thanks for your great reviews.
>
>> Or we can just do several selects, one for each mimeMessageIds.I
> personaly likely prefer this option.
>
> This will make the upper logic layer more complicated. But I agree with
> your suggestion
Hello all,
Just a word about this,
The INFRA requests us to armor our signature on the download page,
I received the following message:
|> Sorry, but the download page is still wrong. |||> | |||> |The links for the
hupa artifacts are missing the /hupa/ subdirectory |||> |segment. > ||
A quick follow up to state that
https://github.com/linagora/james-project/pull/4110 implemented that ;-)
Cheers,
Benoit
Le 03/12/2020 à 09:08, btell...@linagora.com (OpenPaaS) a écrit :
> Nice to see we are on the same wave length!
>
> Regarding the upgrade path, I'm in favor of
Le 04/12/2020 à 03:21, Jean Helou a écrit :
> Hello fellow jamers !
>
> The Jenkinsfile in the PR works, up until the test suite fails, the tests
> failures are from seemingly "unstable" tests that fail because of timing
> issues. Benoit fixed the first one in
>
Hi,
I'm currently trying to increase overall efficiency of the Distributed
James server.
As such, I'm pocking around for improvement areas and found a huge topic
around LWT.
My conclusions so far are that we should keep LWT and SERIAL consistency
level out of the most common use cases.
I know
Nice to see we are on the same wave length!
Regarding the upgrade path, I'm in favor of requiring an empty mailQueue.
Rationals: if there is any sort of retro-compatibility, then an attacker
controlling ie the JMS solution would still be able to control the
deserialized payload (and trigger all
13 matches
Mail list logo
