[jira] [Commented] (JAMES-3958) Failure to DKIM sign mails with some invalid headers
[ 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]'
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
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
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]'
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
[ 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
[ 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]'
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