[jira] [Commented] (JAMES-3958) Failure to DKIM sign mails with some invalid headers

2023-11-07 Thread Benoit Tellier (Jira)


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

Benoit Tellier commented on JAMES-3958:
---

No I just mean "this is the header of an attachment of the mail for which DKIM 
signing fails"

> Failure to DKIM sign mails with some invalid headers
> 
>
> Key: JAMES-3958
> URL: https://issues.apache.org/jira/browse/JAMES-3958
> Project: James Server
>  Issue Type: New Feature
>  Components: Mailet Contributions
>Affects Versions: 3.8.0
>Reporter: Benoit Tellier
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Sample input:
> {code:java}
> Content-Type: message/rfc822; name=BNPP ADVICE LOLO.eml
> {code}
> (in attachments)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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] [1177]'

2023-11-07 Thread Apache Jenkins Server
BUILD-FAILURE: Job 'james/ApacheJames/master [master] [1177]':
Check console output at "https://ci-builds.apache.org/job/james/job/ApacheJames/job/master/1177/";>james/ApacheJames/master
 [master] [1177]"

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

[jira] [Created] (JAMES-3960) Hints to ensure UID/ModSeq consistency in case of disaster

2023-11-07 Thread Benoit Tellier (Jira)
Benoit Tellier created JAMES-3960:
-

 Summary: Hints to ensure UID/ModSeq consistency in case of disaster
 Key: JAMES-3960
 URL: https://issues.apache.org/jira/browse/JAMES-3960
 Project: James Server
  Issue Type: Improvement
  Components: cassandra, mailbox
Reporter: Benoit Tellier


h3. Why?

{code:java}
Given James runs on data-center-1
AND connects in LOCAL_QUORUM and LOCAL_SERIAL to a 3 node cassandra cluster in 
data-center-1
AND cassandra live replicate itself to a backup DC in data-center-2
WHEN a disaster render data-center-1 unusable
THEN I want to connect James to data-center-2
{code}

Doing so can be done by flipping local.dc in cassandra.properties

But uid/modseq monoticity can not be guarantied in the switch as dc2 is out of 
the quorum. This may result in email loss/failure to synchronise a given mail 
thus preventing a user to see it.

We are looking for an heuristic to prevent such inconsistencies

h3. How?

Upon the switch add a defensive amount to all uids and modseq. This will 
prevent double allocation.

This can easdily be conffigured in cassandra.properties: uid.modseq.increment: 
an integer defaulting to 0 added to each uid / modseq

h3. Definition of done

Unit tests showing that the configuration is well applied.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Created] (JAMES-3959) Starting distributed James without OpenSearch

2023-11-07 Thread Benoit Tellier (Jira)
Benoit Tellier created JAMES-3959:
-

 Summary: Starting distributed James without OpenSearch
 Key: JAMES-3959
 URL: https://issues.apache.org/jira/browse/JAMES-3959
 Project: James Server
  Issue Type: Improvement
  Components: elasticsearch
Affects Versions: 3.9.0
Reporter: Benoit Tellier


h3. Why?

While doing some resiliency tests (PRA: Activity Recovery Plan) we noticed that 
it is compulsory to have the OpenSearch cluster online in order to start James.

However, in case of disaster, I should be able to start James without having an 
OpenSearch cluster online. Indeed, search is a (very) nice to have feature but 
not an absolute necessity for sending / receiving mails. And restauring an 
OpenSearch service could take significant time. Being able to start without the 
OpenSearch cluster would thus allow to significantly accelerate the recovery 
plan.

Today one could start even the distributed server in scanning mode, so without 
OpenSearch but this is not a good idea for two reasons:

 - The search would thus be implemented by scanning entire mailbox thus a few 
user doing search could have significant impacts thus worsening the incident.
 - The documents to index would be lost and some sorts of full reindexing would 
also be needed when coming back online.

h3. Expectations

I expect the following:

 - being able to start without OpenSearch
 - Search operations hitting the search index fails. But SearchOverrides would 
succeed, offering a minimal search service for non search operations eg imap 
resynchronisation...
 - No index attempt is performed but events would be stored in the right place 
in event dead letter to eventually get replayed...

h3. How?

Provide a `opensearch_disabled` search index implementation:

 - reject search not satisfied  by search overrides
 - save events into event dead letter for later processing

h3. Definition of done

Integration tests matching the expectations.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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] [1176]'

2023-11-07 Thread Apache Jenkins Server
BUILD-FAILURE: Job 'james/ApacheJames/master [master] [1176]':
Check console output at "https://ci-builds.apache.org/job/james/job/ApacheJames/job/master/1176/";>james/ApacheJames/master
 [master] [1176]"

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

[jira] [Closed] (JAMES-3953) Provide a file based blobstore

2023-11-07 Thread Benoit Tellier (Jira)


 [ 
https://issues.apache.org/jira/browse/JAMES-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benoit Tellier closed JAMES-3953.
-
Resolution: Fixed

> Provide a file based blobstore
> --
>
> Key: JAMES-3953
> URL: https://issues.apache.org/jira/browse/JAMES-3953
> Project: James Server
>  Issue Type: New Feature
>  Components: Blob
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.9.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> h3. Why?
> While working on on-premise instalations, the S3 topic is often a blocker: 
> clients are not equiped with this kind of technologies.
> Aquiring S3 compatible object stores is not that of an easy /cheap task as it 
> fundamentally redifines what storage is, and clashes hardly with the 
> philosophy they applies.
> So far I handled these projects by deploying MinIO (because it is easy to 
> deploy). But on top of shared remote storage performance is mediocre (60 
> Append of ~500 KB in parallel). Technologies like MinIO are though with 
> attached storage in mind and thus are not adapted to this kind of setup.
> I can take concrete examples:
>  - Medium size governement agencies in developing countries. They just have 
> ISCI SAN bay, and do not have founds to adopt other technologies.
>  - Large size health organisation. Handling health data in France is subject 
> to numerous security restrictions (HDS certification) thus they have 
> constraints on the datacenter that prevent them from accessing more advanced 
> features.
> For these customers, I believe they would be better served with a file based 
> implementation of the blob store.
> h3. What?
> Provide a file based implementation of the blob store. 
> Buckets will be emulated via a folder.
> Because of it's immutable nature, concurrent file access should not be an 
> issue.
> We let the su=ystem administrator the choice of how the file system is set up 
> and distributed, backed up and which mount options are to be set up.
> This will be a new *BlobStore* within `/server/blob/blob-file`.
> Propose this blob Store as experimental first.
> While a reactive implementation could be attempted with IO Uring (non 
> portable to non Linux system) a first implementation could be as simple as 
> using a *boundedElastic* thread for the reads.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Closed] (JAMES-3954) Implement RFC-9394 IMAP PARTIAL Extension for Paged SEARCH and FETCH

2023-11-07 Thread Benoit Tellier (Jira)


 [ 
https://issues.apache.org/jira/browse/JAMES-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benoit Tellier closed JAMES-3954.
-
Resolution: Fixed

> Implement RFC-9394 IMAP PARTIAL Extension for Paged SEARCH and FETCH
> 
>
> Key: JAMES-3954
> URL: https://issues.apache.org/jira/browse/JAMES-3954
> Project: James Server
>  Issue Type: New Feature
>Reporter: Benoit Tellier
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This extension, if supported, enable clients to efficiently page requests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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] [1175]'

2023-11-07 Thread Apache Jenkins Server
BUILD-STABLE: Job 'james/ApacheJames/master [master] [1175]':
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