from:"JIRA"



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

Benoit Tellier closed JAMES-3793.
-
Resolution: Fixed

> OOM when loading a very large object from S3?
> -
>
> Key: JAMES-3793
> URL: https://issues.apache.org/jira/browse/JAMES-3793
> Project: James Server
>  Issue Type: Bug
>Reporter: Benoit Tellier
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> h2. What?
> We encountered recurring OutOfMemory exception on one of our production 
> deployment.
> Memory dump analysis was unconclusive and this tends to disqualify an 
> explanation based on a memory leak (300MB of objects only on the heap a few 
> minutes after the OOM).
> A careful log analysis lead to find what seems to be the "original OOM":
> {code:java}
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOf(Unknown Source)
> at software.amazon.awssdk.core.BytesWrapper.asByteArray(BytesWrapper.java:64)
> at 
> org.apache.james.blob.objectstorage.aws.S3BlobStoreDAO$$Lambda$4237/0x0008019f5ad8.apply(Unknown
>  Source)
> at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:106)
> at 
> reactor.core.publisher.MonoPublishOn$PublishOnSubscriber.run(MonoPublishOn.java:181)
> at reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68)
> at reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28)
> at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
> at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
>  Source)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
> Source)
> at java.base/java.lang.Thread.run(Unknown Source)
> {code}
>  
> Following this OOM the application is in a zombie state, unresponsive, 
> throwing OOMs without stacktraces, with Cassandra queries that never 
> finishes, unable to obtain a rabbitMQ connection and have issues within the 
> S3 driver... This sound like reactive programming limitations, that prevents 
> the java platform to handle the OOM like it should (crash the app, take a 
> dump, etc...)
> We did audit quickly our dateset and found several emails/attachment 
> exceeding the 100MB, with a partial and quick audit (we might very well have 
> some larger data!).
> Thus the current explanation is that somehow we successfully saved in S3 a 
> very big mail and now have OOMs when one tries to read it (as S3 blob store 
> DAO does defensive copies).
> h2. Possible actions
> This is an ongoing events, thus our understanding of it can evolve yet as it 
> raises interesting fixes that are hard to understand without the related 
> context, I decided to share it here anyway. I will report upcoming 
> developments here.
> Our first action is to confirm the current diagnostic:
>   - Further audit our datasets to find large items
>   - Deploy a patched version of James that rejects and log S3 objects larger 
> than 50MB
> Yet our current understanding leads to interesting questions...
> *Is it a good idea to load big objects from S3 into our memory?*
> As a preliminary answer, upon email reads we are using `byte[]` for 
> simplicity (no resource management, full view of the data). Changing this is 
> not the scope of this ticket at this is likely a major rework with many 
> unthought impacts. (I dont want to open that Pandora box...)
> SMTP, IMAP, JMAP, and the mailet container all have configuration preventing 
> sending/saving/receiving/uploading too big of a mail/attachment/blob, so we 
> likely have the convincing defense line at the protocol level. Yet this can 
> be defeated by either bad configuration (in our case JMAP was not checking 
> the size of sent email) history (rules were not the same in the past so 
> we ingested too big of a mail in the past), 'malicious action' (if all it 
> takes to crash james is to replace a 1 MB mail by a 1 GB mail). It thus 
> sounds interesting to me to have additional protection at the data access 
> layer, and be able to (optionally) configure S3 to not load objects of say 
> more than 50 MBs. This can be added within the blob.properties file.
> Something like:
> {code:java}
> # Maximum size of blobs allowed to be loaded as byte array. Allow to prevent 
> loading too large objects into memory (can cause OutOfMemoryException).
> # Optional, defaults to no limit being enforced. This is a size in bytes. 
> Supported units are B, K, M, G, T default

[jira] [Closed] (JAMES-3867) Make IMAP modular



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

Benoit Tellier closed JAMES-3867.
-
Resolution: Fixed

> Make IMAP modular
> -
>
> Key: JAMES-3867
> URL: https://issues.apache.org/jira/browse/JAMES-3867
> Project: James Server
>  Issue Type: Improvement
>  Components: guice, IMAPServer
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As an IMAP administrator I want to customize IMAP processing easily. This 
> includes removing/adding/changing IMAP processors/encoders/decoders.
> This allows the following use cases:
>  - Add support for (potentially custom) IMAP extensions without recompiling 
> James
>  - Removing support for buggy commands easily, if any
>  - Enforcing "read only behaviour"
>  - Customizing some commands. For instance one of my customers got a tricky 
> non standard IMAP authenticate command to handle.
> The admin would specify a list of ImapPackage (which is itself a bundle of 
> processors/encoders/decoders) from the imapserver.xml configuration file. By 
> default, if unspecified the default IMAP package would be used.
> Both ImapPackage/processors/encoders/decoders loading would leverage the 
> extensions-jars mechanism.
> h3. Definition of done
> Write an exemple of such modularization writing a PING / PONG command and 
> load it into a James server.
> {code:java}
> A001 PING whatever
>  * PONG whatever
> A001 OK PING command completed.
> {code}



--
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-3863) JMAP OPTIONS endpoints should allow caching



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

Benoit Tellier closed JAMES-3863.
-
Fix Version/s: 3.8.0
   Resolution: Fixed

> JMAP OPTIONS endpoints should allow caching
> ---
>
> Key: JAMES-3863
> URL: https://issues.apache.org/jira/browse/JAMES-3863
> Project: James Server
>  Issue Type: Improvement
>Reporter: Tran Hong Quan
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> JMAP OPTIONS endpoints should return the `Access-Control-Max-Age` response 
> header.
> By doing that client can cache the CORS information and avoid duplicated 
> calls to OPTIONS endpoints therefore better JMAP performance.



--
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-3866) ActiveMQ: memory leak in health check



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

Benoit Tellier closed JAMES-3866.
-
Resolution: Fixed

> ActiveMQ: memory leak in health check
> -
>
> Key: JAMES-3866
> URL: https://issues.apache.org/jira/browse/JAMES-3866
> Project: James Server
>  Issue Type: Bug
>  Components: Queue, webadmin
>Affects Versions: 3.7.1, 3.7.3
>Reporter: ouvtam
>Priority: Major
> Fix For: 3.8.0
>
>
> For documentation purposes this issue was created to let other James 3 (3.7.1 
> and above) users know about a memory leakage regarding ActiveMQ healthchecks.
> In short, James 3.7.1/3.7.2 is affected if:
>  * ActiveMQ is used as message broker / JMS queue
>  * Healthchecks are performed (see conf/healthcheck.properties)
> Workaround:
>  * disabling recurrent healthcheck reports (webadmin + HTTP)
> See discussion and fix (master):
> [https://github.com/apache/james-project/commit/390be9e9e3d048d2e177aa2fdf6b6732035a7c16|https://github.com/apache/james-project/commit/390be9e9e3d048d2e177aa2fdf6b6732035a7c16]



--
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-3868) Cannot handle IMAP PLAIN login with password longer than 255 char

2022-12-29 Thread Benoit Tellier (Jira)



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

Benoit Tellier closed JAMES-3868.
-
Fix Version/s: 3.8.0
   Resolution: Fixed

> Cannot handle IMAP PLAIN login with password longer than 255 char
> -
>
> Key: JAMES-3868
> URL: https://issues.apache.org/jira/browse/JAMES-3868
> Project: James Server
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Niko Usai
>Priority: Critical
> Fix For: 3.8.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There is a bug, in my opinion, in how `AuthenticateProcessor` handles PLAIN 
> login omitting authorization identity.
> The fact is when authorization identity is blank the password field is parsed 
> with Username.of() that has the 255 char limitation, and it expects to raise 
> an exception when looking for the 3rd missing argument, where the password 
> should be, which has not this limitation.
> These leads to an "IllegalArgumentException" of the Username class creating 
> an invalid AuthenticationAttempt.
> {code:java}
> String userpass = new 
> String(Base64.getDecoder().decode(initialClientResponse));
> StringTokenizer authTokenizer = new StringTokenizer(userpass, "\0");
> String token1 = authTokenizer.nextToken();  // Authorization Identity
> token2 = authTokenizer.nextToken(); // Authentication Identity
> try {
> return delegation(Username.of(token1), Username.of(token2), 
> authTokenizer.nextToken());
> } catch (java.util.NoSuchElementException ignored) {
> // If we got here, this is what happened.  RFC 2595
> // says that "the client may leave the authorization {code}
>  
>  



--
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-3869) JSPF mailet should skip private networks in addition to 127.0.0.1 and use correct HELO

2022-12-29 Thread Benoit Tellier (Jira)



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

Benoit Tellier closed JAMES-3869.
-
Fix Version/s: 3.8.0
   Resolution: Fixed

> JSPF mailet should skip private networks in addition to 127.0.0.1 and use 
> correct HELO
> --
>
> Key: JAMES-3869
> URL: https://issues.apache.org/jira/browse/JAMES-3869
> Project: James Server
>  Issue Type: Improvement
>Reporter: ouvtam
>Priority: Minor
> Fix For: 3.8.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> h3. Private Networks
> The JSPF mailet skips SPF checks for remote address 127.0.0.1.
> In addition, the mailet should also skip SPF check for following private 
> class networks:
>  * 127.0.0.0/8
>  * 10.0.0.0/8
>  * 172.16.0.0 – 172.31.255.255
>  * 192.168.0.0/16
> Make it configurable to add more flexibility to exclude other networks.
> h3. HELO Check
> Currently the SPF HELO check uses the remote address instead of the HELO 
> provided by the SMTP session. The SPF HELO check gets important for null 
> senders (e.g. bounces) when no sender address is available.



--
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-3871) No eventBus associated to EventDispatcher$DispatchingFailureGroup

2022-12-29 Thread Benoit Tellier (Jira)



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

Benoit Tellier closed JAMES-3871.
-
Resolution: Fixed

> No eventBus associated to EventDispatcher$DispatchingFailureGroup
> -
>
> Key: JAMES-3871
> URL: https://issues.apache.org/jira/browse/JAMES-3871
> Project: James Server
>  Issue Type: Bug
>Reporter: Tung TRAN
>Priority: Trivial
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> *Error:*
> {code:java}
> logger org.apache.james.webadmin.service.EventDeadLettersRedeliverService
> message No eventBus associated. event: EventId
> {id=db0dcdc2-0f2d-4736-8da6-1057e3d9179e}
> for group: org.apache.james.events.EventDispatcher$DispatchingFailureGroup
> {code}
>  
> *Reason:*
> The `EventDispatcher$DispatchingFailureGroup` has not been registered for 
> event bus correspondence.
> *How to fix:*
>  - Create a EventBusName POJO into event-bus-api
>  - Create a custom Group for DispatchingFailureGroup in event-bus-api, with 
> the EventBusName in it. (With serialization, deserialization)
>  - Use EventBusName into existing naming strategy (replaces String prefix)
>  - In EventDeadLettersRedeliverService handle DispatchingFailureGroup 
> differently: use the EventBusName to find the right event bus.



--
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-3871) No eventBus associated to EventDispatcher$DispatchingFailureGroup

2022-12-28 Thread Tung TRAN (Jira)

Tung TRAN created JAMES-3871:


 Summary: No eventBus associated to 
EventDispatcher$DispatchingFailureGroup
 Key: JAMES-3871
 URL: https://issues.apache.org/jira/browse/JAMES-3871
 Project: James Server
  Issue Type: Bug
Reporter: Tung TRAN


*Error:*
{code:java}
logger org.apache.james.webadmin.service.EventDeadLettersRedeliverService
message No eventBus associated. event: EventId
{id=db0dcdc2-0f2d-4736-8da6-1057e3d9179e}
for group: org.apache.james.events.EventDispatcher$DispatchingFailureGroup
{code}
 

*Reason:*

The `EventDispatcher$DispatchingFailureGroup` has not been registered for event 
bus correspondence.

*How to fix:*
 - Create a EventBusName POJO into event-bus-api
 - Create a custom Group for DispatchingFailureGroup in event-bus-api, with the 
EventBusName in it. (With serialization, deserialization)
 - Use EventBusName into existing naming strategy (replaces String prefix)
 - In EventDeadLettersRedeliverService handle DispatchingFailureGroup 
differently: use the EventBusName to find the right event bus.



--
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-3870) Each IMAP response line is a distinct TCP packet

2022-12-28 Thread Benoit Tellier (Jira)

Benoit Tellier created JAMES-3870:
-

 Summary: Each IMAP response line is a distinct TCP packet
 Key: JAMES-3870
 URL: https://issues.apache.org/jira/browse/JAMES-3870
 Project: James Server
  Issue Type: Improvement
  Components: IMAPServer
Reporter: Benoit Tellier
 Fix For: 3.8.0
 Attachments: master-list-responses-with-flush.png, 
pr-list-responses-without-flush.png

Today each Imap response line is transmitted in a distinct TCP packet.

This causes a lot of network overhead as 
 => TCP headers are added for each response line. To give an idea a LIST 
response line is 35 bytes long but result in a 101 bytes TCP frame so a 188% 
overcost
 => TCP ack are conducted for each line independently. An ACK is 66 bytes,

This is especially problematic for LIST, FETCH commands that actually result in 
many (100, 1000, maybe millions) response lines.

See attach screenshot: master-list-responses-with-flush.png demonstrating this.

We should try to limit the calls to "flush" with Netty, and force the flush 
only once per IMAP command (at the end of processing). Netty is free to 
transmit some data earlier if it's buffer states requires it. 

The entire mailbox list take 1 packet to transmit (1420 btes total for 41 
mailboxes so ~35 bytes per mailbox) and a single ACK (66 bytes).

See attach screenshot: pr-list-responses-without-flush.png demonstrating this.



--
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] [Updated] (JAMES-3870) Each IMAP response line is a distinct TCP packet

2022-12-28 Thread Benoit Tellier (Jira)



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

Benoit Tellier updated JAMES-3870:
--
Attachment: pr-list-responses-without-flush.png
master-list-responses-with-flush.png

> Each IMAP response line is a distinct TCP packet
> 
>
> Key: JAMES-3870
> URL: https://issues.apache.org/jira/browse/JAMES-3870
> Project: James Server
>  Issue Type: Improvement
>  Components: IMAPServer
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
> Attachments: master-list-responses-with-flush.png, 
> pr-list-responses-without-flush.png
>
>
> Today each Imap response line is transmitted in a distinct TCP packet.
> This causes a lot of network overhead as 
>  => TCP headers are added for each response line. To give an idea a LIST 
> response line is 35 bytes long but result in a 101 bytes TCP frame so a 188% 
> overcost
>  => TCP ack are conducted for each line independently. An ACK is 66 bytes,
> This is especially problematic for LIST, FETCH commands that actually result 
> in many (100, 1000, maybe millions) response lines.
> See attach screenshot: master-list-responses-with-flush.png demonstrating 
> this.
> We should try to limit the calls to "flush" with Netty, and force the flush 
> only once per IMAP command (at the end of processing). Netty is free to 
> transmit some data earlier if it's buffer states requires it. 
> The entire mailbox list take 1 packet to transmit (1420 btes total for 41 
> mailboxes so ~35 bytes per mailbox) and a single ACK (66 bytes).
> See attach screenshot: pr-list-responses-without-flush.png demonstrating this.



--
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] [Updated] (JAMES-3869) JSPF mailet should skip private networks in addition to 127.0.0.1 and use correct HELO

2022-12-17 Thread ouvtam (Jira)



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

ouvtam updated JAMES-3869:
--
Attachment: image.gif

> JSPF mailet should skip private networks in addition to 127.0.0.1 and use 
> correct HELO
> --
>
> Key: JAMES-3869
> URL: https://issues.apache.org/jira/browse/JAMES-3869
> Project: James Server
>  Issue Type: Improvement
>Reporter: ouvtam
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h3. Private Networks
> The JSPF mailet skips SPF checks for remote address 127.0.0.1.
> In addition, the mailet should also skip SPF check for following private 
> class networks:
>  * 127.0.0.0/8
>  * 10.0.0.0/8
>  * 172.16.0.0 – 172.31.255.255
>  * 192.168.0.0/16
> Make it configurable to add more flexibility to exclude other networks.
> h3. HELO Check
> Currently the SPF HELO check uses the remote address instead of the HELO 
> provided by the SMTP session. The SPF HELO check gets important for null 
> senders (e.g. bounces) when no sender address is available.



--
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] [Updated] (JAMES-3869) JSPF mailet should skip private networks in addition to 127.0.0.1 and use correct HELO

2022-12-17 Thread ouvtam (Jira)



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

ouvtam updated JAMES-3869:
--
Attachment: (was: image.gif)

> JSPF mailet should skip private networks in addition to 127.0.0.1 and use 
> correct HELO
> --
>
> Key: JAMES-3869
> URL: https://issues.apache.org/jira/browse/JAMES-3869
> Project: James Server
>  Issue Type: Improvement
>Reporter: ouvtam
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h3. Private Networks
> The JSPF mailet skips SPF checks for remote address 127.0.0.1.
> In addition, the mailet should also skip SPF check for following private 
> class networks:
>  * 127.0.0.0/8
>  * 10.0.0.0/8
>  * 172.16.0.0 – 172.31.255.255
>  * 192.168.0.0/16
> Make it configurable to add more flexibility to exclude other networks.
> h3. HELO Check
> Currently the SPF HELO check uses the remote address instead of the HELO 
> provided by the SMTP session. The SPF HELO check gets important for null 
> senders (e.g. bounces) when no sender address is available.



--
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] [Updated] (JAMES-3869) JSPF mailet should skip private networks in addition to 127.0.0.1 and use correct HELO

2022-12-16 Thread ouvtam (Jira)



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

ouvtam updated JAMES-3869:
--
Description: 
h3. Private Networks

The JSPF mailet skips SPF checks for remote address 127.0.0.1.

In addition, the mailet should also skip SPF check for following private class 
networks:
 * 127.0.0.0/8
 * 10.0.0.0/8
 * 172.16.0.0 – 172.31.255.255
 * 192.168.0.0/16

Make it configurable to add more flexibility to exclude other networks.
h3. HELO Check

Currently the SPF HELO check uses the remote address instead of the HELO 
provided by the SMTP session. The SPF HELO check gets important for null 
senders (e.g. bounces) when no sender address is available.

  was:
The JSPF mailet skips SPF checks for remote address 127.0.0.1.

In addition, the mailet should also skip SPF check for following private class 
networks:
 * 127.0.0.0/8
 * 10.0.0.0/8
 * 172.16.0.0 – 172.31.255.255
 * 192.168.0.0/16

Make it configurable to add more flexibility to exclude other networks.

Summary: JSPF mailet should skip private networks in addition to 
127.0.0.1 and use correct HELO  (was: JSPF mailet should skip private networks 
in addition to 127.0.0.1)

> JSPF mailet should skip private networks in addition to 127.0.0.1 and use 
> correct HELO
> --
>
> Key: JAMES-3869
> URL: https://issues.apache.org/jira/browse/JAMES-3869
> Project: James Server
>  Issue Type: Improvement
>Reporter: ouvtam
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h3. Private Networks
> The JSPF mailet skips SPF checks for remote address 127.0.0.1.
> In addition, the mailet should also skip SPF check for following private 
> class networks:
>  * 127.0.0.0/8
>  * 10.0.0.0/8
>  * 172.16.0.0 – 172.31.255.255
>  * 192.168.0.0/16
> Make it configurable to add more flexibility to exclude other networks.
> h3. HELO Check
> Currently the SPF HELO check uses the remote address instead of the HELO 
> provided by the SMTP session. The SPF HELO check gets important for null 
> senders (e.g. bounces) when no sender address is available.



--
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-3869) JSPF mailet should skip private networks in addition to 127.0.0.1

2022-12-16 Thread ouvtam (Jira)

ouvtam created JAMES-3869:
-

 Summary: JSPF mailet should skip private networks in addition to 
127.0.0.1
 Key: JAMES-3869
 URL: https://issues.apache.org/jira/browse/JAMES-3869
 Project: James Server
  Issue Type: Improvement
Reporter: ouvtam


The JSPF mailet skips SPF checks for remote address 127.0.0.1.

In addition, the mailet should also skip SPF check for following private class 
networks:
 * 127.0.0.0/8
 * 10.0.0.0/8
 * 172.16.0.0 – 172.31.255.255
 * 192.168.0.0/16

Make it configurable to add more flexibility to exclude other networks.



--
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-3868) Cannot handle IMAP PLAIN login with password longer than 255 char

2022-12-12 Thread Niko Usai (Jira)

Niko Usai created JAMES-3868:


 Summary: Cannot handle IMAP PLAIN login with password longer than 
255 char
 Key: JAMES-3868
 URL: https://issues.apache.org/jira/browse/JAMES-3868
 Project: James Server
  Issue Type: Bug
Affects Versions: 3.6.0
Reporter: Niko Usai


There is a bug, in my opinion, in how `AuthenticateProcessor` handles PLAIN 
login omitting authorization identity.
The fact is when authorization identity is blank the password field is parsed 
with Username.of() that has the 255 char limitation, and it expects to raise an 
exception when looking for the 3rd missing argument, where the password should 
be, which has not this limitation.
These leads to an "IllegalArgumentException" of the Username class creating an 
invalid AuthenticationAttempt.


{code:java}
String userpass = new String(Base64.getDecoder().decode(initialClientResponse));
StringTokenizer authTokenizer = new StringTokenizer(userpass, "\0");
String token1 = authTokenizer.nextToken();  // Authorization Identity
token2 = authTokenizer.nextToken(); // Authentication Identity
try {
return delegation(Username.of(token1), Username.of(token2), 
authTokenizer.nextToken());
} catch (java.util.NoSuchElementException ignored) {
// If we got here, this is what happened.  RFC 2595
// says that "the client may leave the authorization {code}
 

 



--
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-3867) Make IMAP modular

Benoit Tellier created JAMES-3867:
-

 Summary: Make IMAP modular
 Key: JAMES-3867
 URL: https://issues.apache.org/jira/browse/JAMES-3867
 Project: James Server
  Issue Type: Improvement
  Components: guice, IMAPServer
Reporter: Benoit Tellier
 Fix For: 3.8.0


As an IMAP administrator I want to customize IMAP processing easily. This 
includes removing/adding/changing IMAP processors/encoders/decoders.

This allows the following use cases:

 - Add support for (potentially custom) IMAP extensions without recompiling 
James
 - Removing support for buggy commands easily, if any
 - Enforcing "read only behaviour"
 - Customizing some commands. For instance one of my customers got a tricky non 
standard IMAP authenticate command to handle.

The admin would specify a list of ImapPackage (which is itself a bundle of 
processors/encoders/decoders) from the imapserver.xml configuration file. By 
default, if unspecified the default IMAP package would be used.

Both ImapPackage/processors/encoders/decoders loading would leverage the 
extensions-jars mechanism.

h3. Definition of done

Write an exemple of such modularization writing a PING / PONG command and load 
it into a James server.

{code:java}
A001 PING whatever
 * PONG whatever
A001 OK PING command completed.
{code}





--
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-3860) Rely on Files.createTempFile



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

Benoit Tellier closed JAMES-3860.
-
Resolution: Fixed

> Rely on Files.createTempFile
> 
>
> Key: JAMES-3860
> URL: https://issues.apache.org/jira/browse/JAMES-3860
> Project: James Server
>  Issue Type: Improvement
>  Components: James Core
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0, 3.7.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This is the right way to do it in Java. Usage of File.createTempFile is not 
> idiomatic.



--
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-3862) Log4J/SLF4J Binding is broken in james-server-spring-app



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

Benoit Tellier closed JAMES-3862.
-
Resolution: Fixed

> Log4J/SLF4J Binding is broken in james-server-spring-app
> 
>
> Key: JAMES-3862
> URL: https://issues.apache.org/jira/browse/JAMES-3862
> Project: James Server
>  Issue Type: Bug
>Affects Versions: 3.8.0
>Reporter: Bernd Bartke
>Priority: Major
> Fix For: 3.7.3
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Log4J/SLF4J Binding is broken in james-server-spring-app, starting with 3.7.2.
> Server startup of 3.7.2:
> {noformat}
> C:\bin\james-server-spring-app-3.7.2\bin>run.bat
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
> SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x 
> or earlier.
> SLF4J: Ignoring binding found at 
> [jar:file:/C:/bin/james-server-spring-app-3.7.2/lib/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an 
> explanation.
> 15  James  WARN   [main] openjpa.Runtime - An error occurred while 
> registering a ClassTransformer with PersistenceUnitInfo: name 'James', root 
> URL [file:/C:/bin/james-server-spring-app-3.7.2/conf]. The error has been 
> consumed. To see it, set your openjpa.Runtime log level to TRACE. Load-time 
> class transformation will not be available.
> 9281  James  INFO   [main] openjpa.Runtime - Starting OpenJPA 3.2.0
> {noformat}
> Issue was introduced with commit 3460270c3a928da6ee650194a9d4f1a08e53947e by 
> TRAN at 2022-09-20:
> slf4j.version has been changed from 1.7.36 to 2.0.1
> (!) SLF4J 2 requires updated SLF4J to Log4j Adapters:
> SLF4J 2 ServiceLoader mechanism to find its logging backend
> https://www.slf4j.org/faq.html#changesInVersion200
> https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/
> {quote}
> Due to a break in compatibility in the SLF4J binding, as of release 2.19.0 
> two SLF4J to Log4j Adapters are provided.
> ...
> 2. {{log4j-slf4j2-impl}} should be used with SLF4J 2.0.x releases or newer.
> {quote}
> To fix the issue, the 3 pom.xml referencing artifactId {{log4j-slf4j-impl}} 
> should reference artifactId {{log4j-slf4j2-impl}} instead (- 
> {{log4j2.version}} is already set to {{2.19.0}}, ):
> {noformat}
> $ grep -r --include="pom.xml" "log4j-slf4j-impl" *
> pom.xml:log4j-slf4j-impl
> server/apps/spring-app/pom.xml:
> log4j-slf4j-impl
> server/container/spring/pom.xml:
> log4j-slf4j-impl
> {noformat}



--
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-3859) Wrong starting sequence



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

Benoit Tellier closed JAMES-3859.
-
Resolution: Fixed

> Wrong starting sequence
> ---
>
> Key: JAMES-3859
> URL: https://issues.apache.org/jira/browse/JAMES-3859
> Project: James Server
>  Issue Type: Bug
>  Components: guice
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> h3. What happened?
> At a customer, processing emails via LMTP started while the user repository 
> was not (yet) configured.
> As a result, the resulting processing was faulty (until the right 
> configuration was applied).
> The starting sequence I observed:
> {code:java}
> 09:47:04.784 [INFO ] o.a.j.m.i.JamesMailSpooler - init...
> 09:47:04.784 [INFO ] o.a.j.m.i.JamesMailSpooler - Concurrency level is 20
> 09:47:04.789 [INFO ] o.a.j.m.i.JamesMailSpooler - Spooler started
> 09:47:04.796 [INFO ] o.a.j.m.m.MailboxListenersLoaderImpl - Loading user 
> registered mailbox listeners
> 09:47:04.797 [INFO ] o.a.j.m.m.MailboxListenersLoaderImpl - Loading user 
> registered mailbox listener 
> ClassName{name=org.apache.james.mailbox.cassandra.MailboxOperationLoggingListener}
> 09:47:04.835 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service bound to: 0.0.0.0:0
> 09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service handler hello name is: interview1-HP-ProBook-440-G6
> 09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service handler connection timeout is: 300
> 09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service connection backlog is: 200
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service bound to: 0.0.0.0:0
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service handler hello name is: interview1-HP-ProBook-440-G6
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service handler connection timeout is: 300
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service connection backlog is: 200
> 09:47:04.846 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - TLS 
> enabled with auth NONE using truststore null
> 09:47:04.932 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init IMAP 
> Service done
> 09:47:05.019 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init IMAP 
> Service done
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service bound to: 0.0.0.0:0
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service handler hello name is: interview1-HP-ProBook-440-G6
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service handler connection timeout is: 1200
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service connection backlog is: 200
> 09:47:05.031 [INFO ] o.a.j.l.n.LMTPServer - No maximum message size is 
> enforced for this server.
> 09:47:05.196 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init LMTP 
> Service done
> 09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service bound to: 0.0.0.0:0
> 09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service handler hello name is: interview1-HP-ProBook-440-G6
> 09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service handler connection timeout is: 1200
> 09:47:05.210 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service connection backlog is: 200
> 09:47:05.293 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init POP3 
> Service done
> 09:47:05.307 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP 
> Service bound to: 0.0.0.0:0
> 09:47:05.307 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:05.30

[jira] [Closed] (JAMES-3864) Unify vhost management with queues and RabbitMQ

2022-12-06 Thread Jira



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

René Cordier closed JAMES-3864.
---
Resolution: Fixed

The PR has been merged to fix this issue.

 

What has been considered at the end is that the vhost should be declared in the 
uri. The vhost parameter in rabbitmq.properties is still present, but only used 
in special cases where there is bad formatted URIs making parsing not feasible 
(like with characters like '_')

> Unify vhost management with queues and RabbitMQ
> ---
>
> Key: JAMES-3864
> URL: https://issues.apache.org/jira/browse/JAMES-3864
> Project: James Server
>  Issue Type: Improvement
>Reporter: René Cordier
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Actually in James we have our queues that get assigned to the correct vhost 
> on rabbitmq but in two different ways:
> - via the uri parameter in rabbitmq.properties, like: 
> {noformat}
> amqp://{user}:{password}@{rabbit_host}:{rabbit_port}/{vhost}
> {noformat}
> - via the parameter `vhost` in rabbitmq.properties (like for the mail queues)
> It's not really logical and confusing for users in general. We should:
> - agree on one unified way to get the vhost for all queues (uri parsing or 
> vhost parameter)
> - refactor the code following the consensus on the solution



--
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-3866) ActiveMQ: memory leak in health check

2022-12-03 Thread ouvtam (Jira)

ouvtam created JAMES-3866:
-

 Summary: ActiveMQ: memory leak in health check
 Key: JAMES-3866
 URL: https://issues.apache.org/jira/browse/JAMES-3866
 Project: James Server
  Issue Type: Bug
  Components: Queue, webadmin
Affects Versions: 3.7.1, 3.7.3
Reporter: ouvtam
 Fix For: 3.8.0


For documentation purposes this issue was created to let other James 3 (3.7.1 
and above) users know about a memory leakage regarding ActiveMQ healthchecks.

In short, James 3.7.1/3.7.2 is affected if:
 * ActiveMQ is used as message broker / JMS queue
 * Healthchecks are performed (see conf/healthcheck.properties)

Workaround:
 * disabling recurrent healthcheck reports (webadmin + HTTP)

See discussion and fix (master):

[https://github.com/apache/james-project/commit/390be9e9e3d048d2e177aa2fdf6b6732035a7c16|https://github.com/apache/james-project/commit/390be9e9e3d048d2e177aa2fdf6b6732035a7c16]



--
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-3865) How to export Gmail to PST in Easy Steps?

2022-12-02 Thread Benoit Tellier (Jira)



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

Benoit Tellier closed JAMES-3865.
-
Resolution: Invalid

> How to export Gmail to PST in Easy Steps?
> -
>
> Key: JAMES-3865
> URL: https://issues.apache.org/jira/browse/JAMES-3865
> Project: James Server
>  Issue Type: Task
>Reporter: Nena
>Priority: Major
>
> *Introduction:* Email backup is a top-security concern for users because 
> their data is their main component. Once you take the backup of mailbox 
> emails, you can overcome the data loss. Users can [export Gmail to 
> PST|https://yotasoftware.com/blogs/convert-gmail-email-to-pst/] for Outlook 
> using various methods.
> In this blog, we will be going to discuss the methods to back up Gmail 
> account data in Outlook PST format and store local copies of email messages, 
> calendar events, and other items into your local PC.
> h2. Why Users want to Export Gmail to PST?
> There are a number of reasons why you might need to backup your Gmail emails 
> to PST. Perhaps you're leaving your current job and want to take your emails 
> with you. Or maybe you're worried about losing important data if your account 
> is ever hacked. Whatever the reason, there are a few different ways you can 
> go about backing up your Gmail emails to PST.
> The first and most obvious method is to simply export your emails from Gmail 
> to PST. This can be done using various email clients like Microsoft Outlook 
> or Mozilla Thunderbird. However, this method only backs up your emails and 
> doesn't include any of your other data, like your contacts or calendar.
> Another method is to use a third-party backup service, like [Yota Gmail 
> Backup Tool|https://yotasoftware.com/gmail-backup/]. This tool will backup 
> your entire Gmail account, including your emails, contacts, and calendar.
> h2. Professional tool to Convert Gmail Emails to PST Format
> Looking for a way to backup your Gmail data? Look no further than Yota Gmail 
> Backup Wizard! It is a quick and easy way to backup your Gmail data so you 
> never have to worry about losing important emails or data again.
> With this [Email Backup Wizard|https://yotasoftware.com/email-backup/], you 
> can choose to backup your entire Gmail account or just selected folders. You 
> can also schedule regular backups so you can set it and forget it. And if you 
> ever need to restore your data, you can do so with just a few clicks.
> So why wait? Start backing up your Gmail data today with Yota Gmail Backup 
> Software!
> *You May Also Read:*
> [Gmail Attachment 
> Extractor|https://yotasoftware.com/blogs/extract-all-attachments-from-gmail/]
> [Convert Gmail to 
> PDF|https://yotasoftware.com/blogs/print-multiple-gmail-emails-in-pdf/]
> [Import Gmail to Office 
> 365|https://yotasoftware.com/blogs/import-gmail-to-office-365/]
> [Migrate Gmail to 
> Thunderbird|https://yotasoftware.com/blogs/add-gmail-account-to-thunderbird-with-attachments/]
> [Import Gmail to Yahoo 
> |https://yotasoftware.com/blogs/transfer-gmail-to-yahoo-mail/]
>  
>  



--
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] [Updated] (JAMES-3865) How to export Gmail to PST in Easy Steps?

2022-12-02 Thread Nena (Jira)

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

Nena updated JAMES-3865:

Description:
*Introduction:* Email backup is a top-security concern for users because their
data is their main component. Once you take the backup of mailbox emails, you
can overcome the data loss. Users can [export Gmail to
PST|https://yotasoftware.com/blogs/convert-gmail-email-to-pst/] for Outlook
using various methods.

In this blog, we will be going to discuss the methods to back up Gmail account
data in Outlook PST format and store local copies of email messages, calendar
events, and other items into your local PC.
h2. Why Users want to Export Gmail to PST?

There are a number of reasons why you might need to backup your Gmail emails to
PST. Perhaps you're leaving your current job and want to take your emails with
you. Or maybe you're worried about losing important data if your account is
ever hacked. Whatever the reason, there are a few different ways you can go
about backing up your Gmail emails to PST.

The first and most obvious method is to simply export your emails from Gmail to
PST. This can be done using various email clients like Microsoft Outlook or
Mozilla Thunderbird. However, this method only backs up your emails and doesn't
include any of your other data, like your contacts or calendar.

Another method is to use a third-party backup service, like [Yota Gmail Backup
Tool|https://yotasoftware.com/gmail-backup/]. This tool will backup your entire
Gmail account, including your emails, contacts, and calendar.
h2. Professional tool to Convert Gmail Emails to PST Format

Looking for a way to backup your Gmail data? Look no further than Yota Gmail
Backup Wizard! It is a quick and easy way to backup your Gmail data so you
never have to worry about losing important emails or data again.

With this [Email Backup Wizard|https://yotasoftware.com/email-backup/], you can
choose to backup your entire Gmail account or just selected folders. You can
also schedule regular backups so you can set it and forget it. And if you ever
need to restore your data, you can do so with just a few clicks.

So why wait? Start backing up your Gmail data today with Yota Gmail Backup
Software!

*You May Also Read:*

[Gmail Attachment
Extractor|https://yotasoftware.com/blogs/extract-all-attachments-from-gmail/]

[Convert Gmail to
PDF|https://yotasoftware.com/blogs/print-multiple-gmail-emails-in-pdf/]

[Import Gmail to Office
365|https://yotasoftware.com/blogs/import-gmail-to-office-365/]

[Migrate Gmail to
Thunderbird|https://yotasoftware.com/blogs/add-gmail-account-to-thunderbird-with-attachments/]

[Import Gmail to Yahoo
|https://yotasoftware.com/blogs/transfer-gmail-to-yahoo-mail/]

was:
*Introduction:* Email backup is a top-security concern for users because their
data is their main component. Once you take the backup of mailbox emails, you
can overcome the data loss. Users can [export Gmail to
PST|https://yotasoftware.com/blogs/convert-gmail-email-to-pst/] for Outlook
using various methods.

So why wait? Start backing up your Gmail data today with Yota Gmail Backup
Software!

> How to export Gmail to PST in E

[jira] [Created] (JAMES-3865) How to export Gmail to PST in Easy Steps?

2022-12-02 Thread Nena (Jira)

Nena created JAMES-3865:
---

 Summary: How to export Gmail to PST in Easy Steps?
 Key: JAMES-3865
 URL: https://issues.apache.org/jira/browse/JAMES-3865
 Project: James Server
  Issue Type: Task
Reporter: Nena


*Introduction:* Email backup is a top-security concern for users because their 
data is their main component. Once you take the backup of mailbox emails, you 
can overcome the data loss. Users can [export Gmail to 
PST|https://yotasoftware.com/blogs/convert-gmail-email-to-pst/] for Outlook 
using various methods.

In this blog, we will be going to discuss the methods to back up Gmail account 
data in Outlook PST format and store local copies of email messages, calendar 
events, and other items into your local PC.
h2. Why Users want to Export Gmail to PST?

There are a number of reasons why you might need to backup your Gmail emails to 
PST. Perhaps you're leaving your current job and want to take your emails with 
you. Or maybe you're worried about losing important data if your account is 
ever hacked. Whatever the reason, there are a few different ways you can go 
about backing up your Gmail emails to PST.

The first and most obvious method is to simply export your emails from Gmail to 
PST. This can be done using various email clients like Microsoft Outlook or 
Mozilla Thunderbird. However, this method only backs up your emails and doesn't 
include any of your other data, like your contacts or calendar.

Another method is to use a third-party backup service, like [Yota Gmail Backup 
Tool|https://yotasoftware.com/gmail-backup/]. This tool will backup your entire 
Gmail account, including your emails, contacts, and calendar.
h2. Professional tool to Convert Gmail Emails to PST Format

Looking for a way to backup your Gmail data? Look no further than Yota Gmail 
Backup Wizard! It is a quick and easy way to backup your Gmail data so you 
never have to worry about losing important emails or data again.

With this [Email Backup Wizard|https://yotasoftware.com/email-backup/], you can 
choose to backup your entire Gmail account or just selected folders. You can 
also schedule regular backups so you can set it and forget it. And if you ever 
need to restore your data, you can do so with just a few clicks.

So why wait? Start backing up your Gmail data today with Yota Gmail Backup 
Software!



--
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-3841) ActiveMQ: Collect statistics and publish metrics

2022-11-30 Thread Jira



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

René Cordier closed JAMES-3841.
---
Fix Version/s: 3.8.0
   Resolution: Fixed

[https://github.com/apache/james-project/pull/1290] is fixing this and has been 
merged

> ActiveMQ: Collect statistics and publish metrics
> 
>
> Key: JAMES-3841
> URL: https://issues.apache.org/jira/browse/JAMES-3841
> Project: James Server
>  Issue Type: Improvement
>  Components: Queue
>Reporter: ouvtam
>Priority: Minor
> Fix For: 3.8.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> Currently, only some James metrics are available for ActiveMQ which are 
> exposed in WebAdmin. Namely, enqueuedMail and dequeuedMail for each 
> registered queue (i.e. spool and outgoing). Some ActiveMQ broker stats 
> (memoryUsage, memoryLimit, storeUsage, storeLimit, maxEnqueueTime, etc.) are 
> currently not available.
> According to [https://activemq.apache.org/statisticsplugin.html] ActiveMQ 
> Metrics can be obtained through subscription or by polling regularly. At the 
> moment the statistics plugin is only used to get the size of a queue.
> I propose to poll ActiveMQ statistics via ActiveMQHealthCheck and publish 
> those as metrics. Currently, the health check creates a session and checks if 
> no exception occurred.
> What do you think?
>  



--
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] [Updated] (JAMES-3864) Unify vhost management with queues and RabbitMQ

2022-11-30 Thread Jira



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

René Cordier updated JAMES-3864:

Description: 
Actually in James we have our queues that get assigned to the correct vhost on 
rabbitmq but in two different ways:
- via the uri parameter in rabbitmq.properties, like: 
{noformat}
"amqp://{user}:{password}@{rabbit_host}:{rabbit_port}/{vhost}"
{noformat}
- via the parameter `vhost` in rabbitmq.properties (like for the mail queues)

It's not really logical and confusing for users in general. We should:

- agree on one unified way to get the vhost for all queues (uri parsing or 
vhost parameter)
- refactor the code following the consensus on the solution

  was:
Actually in James we have our queues that get assigned to the correct vhost on 
rabbitmq but in two different ways:
- via the uri parameter in rabbitmq.properties (like 
`amqp://{user}:{password}@{rabbit_host}:{rabbit_port}/{vhost}`)
- via the parameter `vhost` in rabbitmq.properties (like for the mail queues)

It's not really logical and confusing for users in general. We should:

- agree on one unified way to get the vhost for all queues (uri parsing or 
vhost parameter)
- refactor the code following the consensus on the solution


> Unify vhost management with queues and RabbitMQ
> ---
>
> Key: JAMES-3864
> URL: https://issues.apache.org/jira/browse/JAMES-3864
> Project: James Server
>  Issue Type: Improvement
>Reporter: René Cordier
>Priority: Minor
>
> Actually in James we have our queues that get assigned to the correct vhost 
> on rabbitmq but in two different ways:
> - via the uri parameter in rabbitmq.properties, like: 
> {noformat}
> "amqp://{user}:{password}@{rabbit_host}:{rabbit_port}/{vhost}"
> {noformat}
> - via the parameter `vhost` in rabbitmq.properties (like for the mail queues)
> It's not really logical and confusing for users in general. We should:
> - agree on one unified way to get the vhost for all queues (uri parsing or 
> vhost parameter)
> - refactor the code following the consensus on the solution



--
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] [Updated] (JAMES-3864) Unify vhost management with queues and RabbitMQ

2022-11-30 Thread Jira



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

René Cordier updated JAMES-3864:

Description: 
Actually in James we have our queues that get assigned to the correct vhost on 
rabbitmq but in two different ways:
- via the uri parameter in rabbitmq.properties, like: 
{noformat}
amqp://{user}:{password}@{rabbit_host}:{rabbit_port}/{vhost}
{noformat}
- via the parameter `vhost` in rabbitmq.properties (like for the mail queues)

It's not really logical and confusing for users in general. We should:

- agree on one unified way to get the vhost for all queues (uri parsing or 
vhost parameter)
- refactor the code following the consensus on the solution

  was:
Actually in James we have our queues that get assigned to the correct vhost on 
rabbitmq but in two different ways:
- via the uri parameter in rabbitmq.properties, like: 
{noformat}
"amqp://{user}:{password}@{rabbit_host}:{rabbit_port}/{vhost}"
{noformat}
- via the parameter `vhost` in rabbitmq.properties (like for the mail queues)

It's not really logical and confusing for users in general. We should:

- agree on one unified way to get the vhost for all queues (uri parsing or 
vhost parameter)
- refactor the code following the consensus on the solution


> Unify vhost management with queues and RabbitMQ
> ---
>
> Key: JAMES-3864
> URL: https://issues.apache.org/jira/browse/JAMES-3864
> Project: James Server
>  Issue Type: Improvement
>Reporter: René Cordier
>Priority: Minor
>
> Actually in James we have our queues that get assigned to the correct vhost 
> on rabbitmq but in two different ways:
> - via the uri parameter in rabbitmq.properties, like: 
> {noformat}
> amqp://{user}:{password}@{rabbit_host}:{rabbit_port}/{vhost}
> {noformat}
> - via the parameter `vhost` in rabbitmq.properties (like for the mail queues)
> It's not really logical and confusing for users in general. We should:
> - agree on one unified way to get the vhost for all queues (uri parsing or 
> vhost parameter)
> - refactor the code following the consensus on the solution



--
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-3864) Unify vhost management with queues and RabbitMQ

2022-11-30 Thread Jira

René Cordier created JAMES-3864:
---

 Summary: Unify vhost management with queues and RabbitMQ
 Key: JAMES-3864
 URL: https://issues.apache.org/jira/browse/JAMES-3864
 Project: James Server
  Issue Type: Improvement
Reporter: René Cordier


Actually in James we have our queues that get assigned to the correct vhost on 
rabbitmq but in two different ways:
- via the uri parameter in rabbitmq.properties (like 
`amqp://{user}:{password}@{rabbit_host}:{rabbit_port}/{vhost}`)
- via the parameter `vhost` in rabbitmq.properties (like for the mail queues)

It's not really logical and confusing for users in general. We should:

- agree on one unified way to get the vhost for all queues (uri parsing or 
vhost parameter)
- refactor the code following the consensus on the solution



--
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-3863) JMAP OPTIONS endpoints should allow caching

2022-11-28 Thread Tran Hong Quan (Jira)

Tran Hong Quan created JAMES-3863:
-

 Summary: JMAP OPTIONS endpoints should allow caching
 Key: JAMES-3863
 URL: https://issues.apache.org/jira/browse/JAMES-3863
 Project: James Server
  Issue Type: Improvement
Reporter: Tran Hong Quan


JMAP OPTIONS endpoints should return the `Access-Control-Max-Age` response 
header.

By doing that client can cache the CORS information and avoid duplicated calls 
to OPTIONS endpoints therefore better JMAP performance.



--
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] [Commented] (JAMES-3841) ActiveMQ: Collect statistics and publish metrics

2022-11-27 Thread ouvtam (Jira)



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

ouvtam commented on JAMES-3841:
---

Here some exemplary log metrics:
 * broker metrics
 * per-queue metrics (NEW)
 * timer metric how long it took the fetch the metrics -> *._time (NEW)

{code:java}
23:06:06.266 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.consumerCount, value=40
 23:06:06.266 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.dequeueCount, value=0
 23:06:06.266 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.dispatchCount, value=10508
 23:06:06.266 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.enqueueCount, value=1487
 23:06:06.266 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.expiredCount, value=0
 23:06:06.267 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.inflightCount, value=10508
 23:06:06.268 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.lastUpdate, value=1669590365575
 23:06:06.268 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.maxEnqueueTime, value=143.0
 23:06:06.268 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.memoryLimit, value=1073741824
 23:06:06.268 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.memoryPercentUsage, value=0
 23:06:06.269 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.memoryUsage, value=0
 23:06:06.269 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.messagesCached, value=0
 23:06:06.269 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.minEnqueueTime, value=1.0
 23:06:06.269 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.producerCount, value=3
 23:06:06.269 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.size, value=0
 23:06:06.269 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.storeLimit, value=16339816520
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.storePercentUsage, value=0
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.storeUsage, value=135762
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.tempLimit, value=16339804160
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.tempPercentUsage, value=0
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Broker.tempUsage, value=0
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.averageEnqueueTime, value=0.0
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.consumerCount, value=1
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.dequeueCount, value=0
 23:06:06.270 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.dispatchCount, value=0
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.enqueueCount, value=0
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.expiredCount, value=0
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.inflightCount, value=0
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.lastUpdate, value=1669590365533
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.maxEnqueueTime, value=0.0
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.memoryLimit, value=1073741824
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.messagesCached, value=0
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.minEnqueueTime, value=0.0
 23:06:06.271 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.producerCount, value=1
 23:06:06.272 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.outgoing.size, value=0
 23:06:06.272 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.spool.averageEnqueueTime, value=0.0
 23:06:06.272 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.spool.consumerCount, value=1
 23:06:06.272 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.spool.dequeueCount, value=0
 23:06:06.272 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.spool.dispatchCount, value=0
 23:06:06.273 [DEBUG] o.a.j.metrics - type=GAUGE, 
name=ActiveMQ.Statistics.Destination.spool.enqueueCount, value=0
 23:06:06.273 [DEBUG] o.a.j.metrics - type=GA

[jira] [Closed] (JAMES-3844) Issue with docker-compose files and opensearch configuration

2022-11-27 Thread Benoit Tellier (Jira)



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

Benoit Tellier closed JAMES-3844.
-
Resolution: Fixed

> Issue with docker-compose files and opensearch configuration
> 
>
> Key: JAMES-3844
> URL: https://issues.apache.org/jira/browse/JAMES-3844
> Project: James Server
>  Issue Type: Bug
>  Components: configuration
>Affects Versions: master
> Environment: ubuntu 22.04, docker-compose 1.29.2 docker 20.10.21
>Reporter: Hitesh C
>Priority: Major
>  Labels: easyfix, newbie
>   Original Estimate: 72h
>  Time Spent: 10m
>  Remaining Estimate: 71h 50m
>
> There are issues with configuration docker-compose files in the following path
>  * server/apps/cassandra-app/docker-compose.yml
>  * server/apps/distributed-app/docker-compose.yml
>  *  server/apps/distributed-pop3-app/docker-compose.yml
>  *  third-party/clamav/docker-compose.yml
> They refer to elasticsearch in james dependencies, whereas elasticsearch has 
> been updated to opensearch elsewhere.
>  
> Upon updating the depends_on parameter, the setup doesn't start.
> Upon fixing this, the elasticsearch client in james server isnt able to 
> connect to opensearch instance



--
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-3861) EmailDelivery push is used too much

2022-11-27 Thread Benoit Tellier (Jira)



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

Benoit Tellier closed JAMES-3861.
-
Fix Version/s: 3.8.0
   Resolution: Fixed

> EmailDelivery push is used too much
> ---
>
> Key: JAMES-3861
> URL: https://issues.apache.org/jira/browse/JAMES-3861
> Project: James Server
>  Issue Type: Improvement
>  Components: JMAP
>Reporter: Tran Hong Quan
>Assignee: Antoine Duprat
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> As of today, we push an EmailDelivery for each "added" event.
> Yet, added event is used for copies, move, saving draft, sending email... In 
> addition to received new emails.
> We should revisit the APIs of `MessageManager::append` in order to allow 
> passing a bit more context. This context would need to be carried other in 
> the event system.
> # Definition of Done
> JMAP integration test showing that EmailDelivery` state change is reserved to 
> receiving email...
> # API proposal
> Add a `isDelivery` field to the append command, defaulting to false.
> Add a isDelivery field to the `Added` event, defaulting to false.
> Ensure LocalDelivery sets the isDelivery to true.



--
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-3845) HP Solution Center Download Windows

2022-11-27 Thread Benoit Tellier (Jira)



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

Benoit Tellier closed JAMES-3845.
-
Resolution: Fixed

> HP Solution Center Download Windows
> ---
>
> Key: JAMES-3845
> URL: https://issues.apache.org/jira/browse/JAMES-3845
> Project: James Server
>  Issue Type: Bug
>Reporter: Alpha jenner
>Priority: Major
>




--
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] [Commented] (JAMES-3862) Log4J/SLF4J Binding is broken in james-server-spring-app

2022-11-24 Thread Bernd Bartke (Jira)



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

Bernd Bartke commented on JAMES-3862:
-

Hi Benoit,

pull request created:
https://github.com/apache/james-project/pull/1333

It has been a bit tricky to get log4j-core-2.19.0.jar to 
target/appassembler/lib/
Now maven-dependency-plugin is copying the runtime dependency to lib dir.

> Log4J/SLF4J Binding is broken in james-server-spring-app
> 
>
> Key: JAMES-3862
> URL: https://issues.apache.org/jira/browse/JAMES-3862
> Project: James Server
>  Issue Type: Bug
>Affects Versions: 3.8.0
>Reporter: Bernd Bartke
>Priority: Major
> Fix For: 3.7.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Log4J/SLF4J Binding is broken in james-server-spring-app, starting with 3.7.2.
> Server startup of 3.7.2:
> {noformat}
> C:\bin\james-server-spring-app-3.7.2\bin>run.bat
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
> SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x 
> or earlier.
> SLF4J: Ignoring binding found at 
> [jar:file:/C:/bin/james-server-spring-app-3.7.2/lib/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an 
> explanation.
> 15  James  WARN   [main] openjpa.Runtime - An error occurred while 
> registering a ClassTransformer with PersistenceUnitInfo: name 'James', root 
> URL [file:/C:/bin/james-server-spring-app-3.7.2/conf]. The error has been 
> consumed. To see it, set your openjpa.Runtime log level to TRACE. Load-time 
> class transformation will not be available.
> 9281  James  INFO   [main] openjpa.Runtime - Starting OpenJPA 3.2.0
> {noformat}
> Issue was introduced with commit 3460270c3a928da6ee650194a9d4f1a08e53947e by 
> TRAN at 2022-09-20:
> slf4j.version has been changed from 1.7.36 to 2.0.1
> (!) SLF4J 2 requires updated SLF4J to Log4j Adapters:
> SLF4J 2 ServiceLoader mechanism to find its logging backend
> https://www.slf4j.org/faq.html#changesInVersion200
> https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/
> {quote}
> Due to a break in compatibility in the SLF4J binding, as of release 2.19.0 
> two SLF4J to Log4j Adapters are provided.
> ...
> 2. {{log4j-slf4j2-impl}} should be used with SLF4J 2.0.x releases or newer.
> {quote}
> To fix the issue, the 3 pom.xml referencing artifactId {{log4j-slf4j-impl}} 
> should reference artifactId {{log4j-slf4j2-impl}} instead (- 
> {{log4j2.version}} is already set to {{2.19.0}}, ):
> {noformat}
> $ grep -r --include="pom.xml" "log4j-slf4j-impl" *
> pom.xml:log4j-slf4j-impl
> server/apps/spring-app/pom.xml:
> log4j-slf4j-impl
> server/container/spring/pom.xml:
> log4j-slf4j-impl
> {noformat}



--
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] [Commented] (JAMES-3862) Log4J/SLF4J Binding is broken in james-server-spring-app

2022-11-24 Thread Benoit Tellier (Jira)



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

Benoit Tellier commented on JAMES-3862:
---

Hello,

Do you think you can open a pull request on this topic?

> Log4J/SLF4J Binding is broken in james-server-spring-app
> 
>
> Key: JAMES-3862
> URL: https://issues.apache.org/jira/browse/JAMES-3862
> Project: James Server
>  Issue Type: Bug
>Affects Versions: 3.8.0
>Reporter: Bernd Bartke
>Priority: Major
> Fix For: 3.7.3
>
>
> Log4J/SLF4J Binding is broken in james-server-spring-app, starting with 3.7.2.
> Server startup of 3.7.2:
> {noformat}
> C:\bin\james-server-spring-app-3.7.2\bin>run.bat
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
> SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x 
> or earlier.
> SLF4J: Ignoring binding found at 
> [jar:file:/C:/bin/james-server-spring-app-3.7.2/lib/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an 
> explanation.
> 15  James  WARN   [main] openjpa.Runtime - An error occurred while 
> registering a ClassTransformer with PersistenceUnitInfo: name 'James', root 
> URL [file:/C:/bin/james-server-spring-app-3.7.2/conf]. The error has been 
> consumed. To see it, set your openjpa.Runtime log level to TRACE. Load-time 
> class transformation will not be available.
> 9281  James  INFO   [main] openjpa.Runtime - Starting OpenJPA 3.2.0
> {noformat}
> Issue was introduced with commit 3460270c3a928da6ee650194a9d4f1a08e53947e by 
> TRAN at 2022-09-20:
> slf4j.version has been changed from 1.7.36 to 2.0.1
> (!) SLF4J 2 requires updated SLF4J to Log4j Adapters:
> SLF4J 2 ServiceLoader mechanism to find its logging backend
> https://www.slf4j.org/faq.html#changesInVersion200
> https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/
> {quote}
> Due to a break in compatibility in the SLF4J binding, as of release 2.19.0 
> two SLF4J to Log4j Adapters are provided.
> ...
> 2. {{log4j-slf4j2-impl}} should be used with SLF4J 2.0.x releases or newer.
> {quote}
> To fix the issue, the 3 pom.xml referencing artifactId {{log4j-slf4j-impl}} 
> should reference artifactId {{log4j-slf4j2-impl}} instead (- 
> {{log4j2.version}} is already set to {{2.19.0}}, ):
> {noformat}
> $ grep -r --include="pom.xml" "log4j-slf4j-impl" *
> pom.xml:log4j-slf4j-impl
> server/apps/spring-app/pom.xml:
> log4j-slf4j-impl
> server/container/spring/pom.xml:
> log4j-slf4j-impl
> {noformat}



--
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] [Updated] (JAMES-3862) Log4J/SLF4J Binding is broken in james-server-spring-app

2022-11-24 Thread Bernd Bartke (Jira)



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

Bernd Bartke updated JAMES-3862:

Description: 
Log4J/SLF4J Binding is broken in james-server-spring-app, starting with 3.7.2.

Server startup of 3.7.2:
{noformat}
C:\bin\james-server-spring-app-3.7.2\bin>run.bat
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or 
earlier.
SLF4J: Ignoring binding found at 
[jar:file:/C:/bin/james-server-spring-app-3.7.2/lib/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an explanation.
15  James  WARN   [main] openjpa.Runtime - An error occurred while registering 
a ClassTransformer with PersistenceUnitInfo: name 'James', root URL 
[file:/C:/bin/james-server-spring-app-3.7.2/conf]. The error has been consumed. 
To see it, set your openjpa.Runtime log level to TRACE. Load-time class 
transformation will not be available.
9281  James  INFO   [main] openjpa.Runtime - Starting OpenJPA 3.2.0
{noformat}

Issue was introduced with commit 3460270c3a928da6ee650194a9d4f1a08e53947e by 
TRAN at 2022-09-20:
slf4j.version has been changed from 1.7.36 to 2.0.1

(!) SLF4J 2 requires updated SLF4J to Log4j Adapters:

SLF4J 2 ServiceLoader mechanism to find its logging backend
https://www.slf4j.org/faq.html#changesInVersion200

https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/

{quote}
Due to a break in compatibility in the SLF4J binding, as of release 2.19.0 two 
SLF4J to Log4j Adapters are provided.
...
2. {{log4j-slf4j2-impl}} should be used with SLF4J 2.0.x releases or newer.
{quote}

To fix the issue, the 3 pom.xml referencing artifactId {{log4j-slf4j-impl}} 
should reference artifactId {{log4j-slf4j2-impl}} instead (- {{log4j2.version}} 
is already set to {{2.19.0}}, ):

{noformat}
$ grep -r --include="pom.xml" "log4j-slf4j-impl" *
pom.xml:log4j-slf4j-impl
server/apps/spring-app/pom.xml:
log4j-slf4j-impl
server/container/spring/pom.xml:
log4j-slf4j-impl
{noformat}


  was:
Log4J/SLF4J Binding is broken in james-server-spring-app, starting with 3.7.2.

Server startup of 3.7.2:
{noformat}
C:\bin\james-server-spring-app-3.7.2\bin>run.bat
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or 
earlier.
SLF4J: Ignoring binding found at 
[jar:file:/C:/bin/james-server-spring-app-3.7.2/lib/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an explanation.
15  James  WARN   [main] openjpa.Runtime - An error occurred while registering 
a ClassTransformer with PersistenceUnitInfo: name 'James', root URL 
[file:/C:/bin/james-server-spring-app-3.7.2/conf]. The error has been consumed. 
To see it, set your openjpa.Runtime log level to TRACE. Load-time class 
transformation will not be available.
9281  James  INFO   [main] openjpa.Runtime - Starting OpenJPA 3.2.0
{noformat}

Issue was introduced with commit 3460270c3a928da6ee650194a9d4f1a08e53947e by 
TRAN at 2022-09-20:
slf4j.version has been changed from 1.7.36 to 2.0.1

(!) SLF4J 2 requires updated SLF4J to Log4j Adapters:

SLF4J 2 ServiceLoader mechanism to find its logging backend
https://www.slf4j.org/faq.html#changesInVersion200

https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/

{quote}
{{log4j-slf4j2-impl}} should be used with SLF4J 2.0.x releases or newer.
{quote}

To fix the issue, the 3 pom.xml referencing artifactId {{log4j-slf4j-impl}} 
should reference artifactId {{log4j-slf4j2-impl}} instead - {{log4j2.version}} 
is alread set to {{2.19.0}}:

{noformat}
$ grep -r --include="pom.xml" "log4j-slf4j-impl" *
pom.xml:log4j-slf4j-impl
server/apps/spring-app/pom.xml:
log4j-slf4j-impl
server/container/spring/pom.xml:
log4j-slf4j-impl
{noformat}



> Log4J/SLF4J Binding is broken in james-server-spring-app
> 
>
> Key: JAMES-3862
> URL: https://issues.apache.org/jira/browse/JAMES-3862
> Project: James Server
>  Issue Type: Bug
>Affects Versions: 3.8.0
>Reporter: Bernd Bartke
>Priority: Major
> Fix For: 3.7.3
>
>
> Log4J/SLF4J Binding is broken in james-server-spring-app, starting with 3.7.2.
> Server startup of 3.7.2:
> {noformat}
> C:\bin\james-server-spring-app-3.7.2\bin

[jira] [Created] (JAMES-3862) Log4J/SLF4J Binding is broken in james-server-spring-app

2022-11-24 Thread Bernd Bartke (Jira)

Bernd Bartke created JAMES-3862:
---

 Summary: Log4J/SLF4J Binding is broken in james-server-spring-app
 Key: JAMES-3862
 URL: https://issues.apache.org/jira/browse/JAMES-3862
 Project: James Server
  Issue Type: Bug
Affects Versions: 3.8.0
Reporter: Bernd Bartke
 Fix For: 3.7.3


Log4J/SLF4J Binding is broken in james-server-spring-app, starting with 3.7.2.

Server startup of 3.7.2:
{noformat}
C:\bin\james-server-spring-app-3.7.2\bin>run.bat
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or 
earlier.
SLF4J: Ignoring binding found at 
[jar:file:/C:/bin/james-server-spring-app-3.7.2/lib/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an explanation.
15  James  WARN   [main] openjpa.Runtime - An error occurred while registering 
a ClassTransformer with PersistenceUnitInfo: name 'James', root URL 
[file:/C:/bin/james-server-spring-app-3.7.2/conf]. The error has been consumed. 
To see it, set your openjpa.Runtime log level to TRACE. Load-time class 
transformation will not be available.
9281  James  INFO   [main] openjpa.Runtime - Starting OpenJPA 3.2.0
{noformat}

Issue was introduced with commit 3460270c3a928da6ee650194a9d4f1a08e53947e by 
TRAN at 2022-09-20:
slf4j.version has been changed from 1.7.36 to 2.0.1

(!) SLF4J 2 requires updated SLF4J to Log4j Adapters:

SLF4J 2 ServiceLoader mechanism to find its logging backend
https://www.slf4j.org/faq.html#changesInVersion200

https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/

{quote}
{{log4j-slf4j2-impl}} should be used with SLF4J 2.0.x releases or newer.
{quote}

To fix the issue, the 3 pom.xml referencing artifactId {{log4j-slf4j-impl}} 
should reference artifactId {{log4j-slf4j2-impl}} instead - {{log4j2.version}} 
is alread set to {{2.19.0}}:

{noformat}
$ grep -r --include="pom.xml" "log4j-slf4j-impl" *
pom.xml:log4j-slf4j-impl
server/apps/spring-app/pom.xml:
log4j-slf4j-impl
server/container/spring/pom.xml:
log4j-slf4j-impl
{noformat}




--
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-3853) Support IMAP XLIST



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

Benoit Tellier closed JAMES-3853.
-
Resolution: Fixed

> Support IMAP XLIST
> --
>
> Key: JAMES-3853
> URL: https://issues.apache.org/jira/browse/JAMES-3853
> Project: James Server
>  Issue Type: Improvement
>  Components: IMAPServer
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h3. Why?
> My special case mailboxes do not get recognised by IMAP clients (they miss 
> the "role" information).
> See https://github.com/linagora/james-project/issues/3960 
> h3. How?
> Provide a default typer for the already implemented XList extension,
> Write a test,
> And see if this works...
> h3. Longer term options
> https://www.rfc-editor.org/rfc/rfc6154 deprecated XList but is slightly 
> harder to implement...



--
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-3854) Support RFC-8438 IMAP STATUS=SIZE



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

Benoit Tellier closed JAMES-3854.
-
Resolution: Fixed

> Support RFC-8438 IMAP STATUS=SIZE
> -
>
> Key: JAMES-3854
> URL: https://issues.apache.org/jira/browse/JAMES-3854
> Project: James Server
>  Issue Type: Sub-task
>  Components: IMAPServer
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://datatracker.ietf.org/doc/html/rfc8438.html 
> Requirement to qualify as an IMAP REV 2 server...



--
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-3855) Supports IMAP UNAUTHENTICATE (RFC-8437)



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

Benoit Tellier closed JAMES-3855.
-
Resolution: Fixed

> Supports IMAP UNAUTHENTICATE (RFC-8437)
> ---
>
> Key: JAMES-3855
> URL: https://issues.apache.org/jira/browse/JAMES-3855
> Project: James Server
>  Issue Type: Improvement
>  Components: IMAPServer
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>
> https://www.rfc-editor.org/rfc/rfc8437.html
> Usefull for administrative tasks.



--
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-3857) Implement RFC-7889 IMAP APPENDLIMIT



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

Benoit Tellier closed JAMES-3857.
-
Resolution: Fixed

> Implement RFC-7889 IMAP APPENDLIMIT
> ---
>
> Key: JAMES-3857
> URL: https://issues.apache.org/jira/browse/JAMES-3857
> Project: James Server
>  Issue Type: Improvement
>  Components: IMAPServer
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://www.rfc-editor.org/rfc/rfc7889.html
> Allows advertising the size limit for APPEND command.
>  -> Add the APPENDLIMIT capability
>  -> Add the APPENDLIMIT status item



--
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-3852) Subscriptions for non personal mailboxes



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

Benoit Tellier closed JAMES-3852.
-
Resolution: Fixed

> Subscriptions for non personal mailboxes
> 
>
> Key: JAMES-3852
> URL: https://issues.apache.org/jira/browse/JAMES-3852
> Project: James Server
>  Issue Type: Bug
>  Components: JMAP, mailbox
>Reporter: Benoit Tellier
>Assignee: Antoine Duprat
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> h3. The problem
> Subscriptions storage is based on the mailbox name thus do not allow to 
> distinguish two mailboxes with the same name belonging to other users, thus 
> leading to buggy behaviors in the face of delegation.
> This behavior can be encoutered:
>  - In JMAP with James' mailbox sharing
>  - In JMAP we built an extension called team mailboxes (essentially 
> functional mailboxes) that runs in this pitfall.
> h3. Solution
> Rework subscription storage to rely on MailboxPath.
> Data migration can be avoided by storing the mailbox path as a string, and 
> supporting fallbacks for non-mailbox path mailboxes.



--
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-3850) [JMAP] Configure `urn:ietf:params:jmap:mail` `maxSizeAttachmentsPerEmail` property



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

Benoit Tellier closed JAMES-3850.
-
Resolution: Fixed

> [JMAP] Configure `urn:ietf:params:jmap:mail` `maxSizeAttachmentsPerEmail` 
> property
> --
>
> Key: JAMES-3850
> URL: https://issues.apache.org/jira/browse/JAMES-3850
> Project: James Server
>  Issue Type: New Feature
>  Components: JMAP
>Affects Versions: master
>Reporter: Benoit Tellier
>Assignee: Antoine Duprat
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Today, this is hardcoded to 20MB
> Needless to say, we should be flexible on this...



--
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-3858) Implement RFC-8474 IMAP OBJECTID extension



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

Benoit Tellier closed JAMES-3858.
-
Resolution: Fixed

> Implement RFC-8474 IMAP OBJECTID extension
> --
>
> Key: JAMES-3858
> URL: https://issues.apache.org/jira/browse/JAMES-3858
> Project: James Server
>  Issue Type: Improvement
>  Components: IMAPServer
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://www.rfc-editor.org/rfc/rfc8474.html
> Leverages JMAP style identifier to help prevent clients to needlessly 
> resynchronize (eg move from another client)



--
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-3861) EmailDelivery push is used too much

2022-11-21 Thread Tran Hong Quan (Jira)

Tran Hong Quan created JAMES-3861:
-

 Summary: EmailDelivery push is used too much
 Key: JAMES-3861
 URL: https://issues.apache.org/jira/browse/JAMES-3861
 Project: James Server
  Issue Type: Improvement
  Components: JMAP
Reporter: Tran Hong Quan
Assignee: Antoine Duprat


As of today, we push an EmailDelivery for each "added" event.

Yet, added event is used for copies, move, saving draft, sending email... In 
addition to received new emails.

We should revisit the APIs of `MessageManager::append` in order to allow 
passing a bit more context. This context would need to be carried other in the 
event system.

# Definition of Done

JMAP integration test showing that EmailDelivery` state change is reserved to 
receiving email...

# API proposal

Add a `isDelivery` field to the append command, defaulting to false.

Add a isDelivery field to the `Added` event, defaulting to false.

Ensure LocalDelivery sets the isDelivery to true.



--
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-3860) Rely on Files.createTempFile

2022-11-20 Thread Benoit Tellier (Jira)

Benoit Tellier created JAMES-3860:
-

 Summary: Rely on Files.createTempFile
 Key: JAMES-3860
 URL: https://issues.apache.org/jira/browse/JAMES-3860
 Project: James Server
  Issue Type: Improvement
  Components: James Core
Reporter: Benoit Tellier
 Fix For: 3.7.3, 3.8.0


This is the right way to do it in Java. Usage of File.createTempFile is not 
idiomatic.



--
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] [Commented] (JAMES-3859) Wrong starting sequence



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

Benoit Tellier commented on JAMES-3859:
---

Found another solution:

 - We need to take into account `@Provides` into the ordering semantic
 - Provision listeners are annoying as they are called prior the provision, 
hence the order of startables is messed up. I attempted to re-sort them on the 
fly.

I added some tests for injects ordering.

> Wrong starting sequence
> ---
>
> Key: JAMES-3859
> URL: https://issues.apache.org/jira/browse/JAMES-3859
> Project: James Server
>  Issue Type: Bug
>  Components: guice
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>
> h3. What happened?
> At a customer, processing emails via LMTP started while the user repository 
> was not (yet) configured.
> As a result, the resulting processing was faulty (until the right 
> configuration was applied).
> The starting sequence I observed:
> {code:java}
> 09:47:04.784 [INFO ] o.a.j.m.i.JamesMailSpooler - init...
> 09:47:04.784 [INFO ] o.a.j.m.i.JamesMailSpooler - Concurrency level is 20
> 09:47:04.789 [INFO ] o.a.j.m.i.JamesMailSpooler - Spooler started
> 09:47:04.796 [INFO ] o.a.j.m.m.MailboxListenersLoaderImpl - Loading user 
> registered mailbox listeners
> 09:47:04.797 [INFO ] o.a.j.m.m.MailboxListenersLoaderImpl - Loading user 
> registered mailbox listener 
> ClassName{name=org.apache.james.mailbox.cassandra.MailboxOperationLoggingListener}
> 09:47:04.835 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service bound to: 0.0.0.0:0
> 09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service handler hello name is: interview1-HP-ProBook-440-G6
> 09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service handler connection timeout is: 300
> 09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service connection backlog is: 200
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service bound to: 0.0.0.0:0
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service handler hello name is: interview1-HP-ProBook-440-G6
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service handler connection timeout is: 300
> 09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP 
> Service connection backlog is: 200
> 09:47:04.846 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - TLS 
> enabled with auth NONE using truststore null
> 09:47:04.932 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init IMAP 
> Service done
> 09:47:05.019 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init IMAP 
> Service done
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service bound to: 0.0.0.0:0
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service handler hello name is: interview1-HP-ProBook-440-G6
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service handler connection timeout is: 1200
> 09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP 
> Service connection backlog is: 200
> 09:47:05.031 [INFO ] o.a.j.l.n.LMTPServer - No maximum message size is 
> enforced for this server.
> 09:47:05.196 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init LMTP 
> Service done
> 09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service bound to: 0.0.0.0:0
> 09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service is running on: interview1-HP-ProBook-440-G6
> 09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service handler hello name is: interview1-HP-ProBook-440-G6
> 09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service handler connection timeout is: 1200
> 09:47:05.210 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 
> Service connection backlog is: 200
> 09:47:05.293 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init POP3 
> Service done
> 09:47:

[jira] [Created] (JAMES-3859) Wrong starting sequence

Benoit Tellier created JAMES-3859:
-

 Summary: Wrong starting sequence
 Key: JAMES-3859
 URL: https://issues.apache.org/jira/browse/JAMES-3859
 Project: James Server
  Issue Type: Bug
  Components: guice
Affects Versions: master
Reporter: Benoit Tellier
 Fix For: 3.8.0


h3. What happened?

At a customer, processing emails via LMTP started while the user repository was 
not (yet) configured.

As a result, the resulting processing was faulty (until the right configuration 
was applied).

The starting sequence I observed:

{code:java}
09:47:04.784 [INFO ] o.a.j.m.i.JamesMailSpooler - init...
09:47:04.784 [INFO ] o.a.j.m.i.JamesMailSpooler - Concurrency level is 20
09:47:04.789 [INFO ] o.a.j.m.i.JamesMailSpooler - Spooler started
09:47:04.796 [INFO ] o.a.j.m.m.MailboxListenersLoaderImpl - Loading user 
registered mailbox listeners
09:47:04.797 [INFO ] o.a.j.m.m.MailboxListenersLoaderImpl - Loading user 
registered mailbox listener 
ClassName{name=org.apache.james.mailbox.cassandra.MailboxOperationLoggingListener}
09:47:04.835 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
bound to: 0.0.0.0:0
09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
is running on: interview1-HP-ProBook-440-G6
09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
handler hello name is: interview1-HP-ProBook-440-G6
09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
handler connection timeout is: 300
09:47:04.836 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
connection backlog is: 200
09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
bound to: 0.0.0.0:0
09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
is running on: interview1-HP-ProBook-440-G6
09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
handler hello name is: interview1-HP-ProBook-440-G6
09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
handler connection timeout is: 300
09:47:04.845 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - IMAP Service 
connection backlog is: 200
09:47:04.846 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - TLS enabled 
with auth NONE using truststore null
09:47:04.932 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init IMAP 
Service done
09:47:05.019 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init IMAP 
Service done
09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP Service 
bound to: 0.0.0.0:0
09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP Service 
is running on: interview1-HP-ProBook-440-G6
09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP Service 
handler hello name is: interview1-HP-ProBook-440-G6
09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP Service 
handler connection timeout is: 1200
09:47:05.031 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - LMTP Service 
connection backlog is: 200
09:47:05.031 [INFO ] o.a.j.l.n.LMTPServer - No maximum message size is enforced 
for this server.
09:47:05.196 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init LMTP 
Service done
09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 Service 
bound to: 0.0.0.0:0
09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 Service 
is running on: interview1-HP-ProBook-440-G6
09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 Service 
handler hello name is: interview1-HP-ProBook-440-G6
09:47:05.209 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 Service 
handler connection timeout is: 1200
09:47:05.210 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - POP3 Service 
connection backlog is: 200
09:47:05.293 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - Init POP3 
Service done
09:47:05.307 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP Service 
bound to: 0.0.0.0:0
09:47:05.307 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP Service 
is running on: interview1-HP-ProBook-440-G6
09:47:05.307 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP Service 
handler hello name is: interview1-HP-ProBook-440-G6
09:47:05.308 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP Service 
handler connection timeout is: 360
09:47:05.308 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP Service 
connection backlog is: 200
09:47:05.313 [INFO ] o.a.j.s.n.SMTPServer - No maximum message size is enforced 
for this server.
09:47:05.314 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP Service 
bound to: 0.0.0.0:0
09:47:05.314 [INFO ] o.a.j.p.l.n.AbstractConfigurableAsyncServer - SMTP Service 
is running on: interview1-HP-ProBook-440-G6
09:47:05.314

[jira] [Closed] (JAMES-3856) Implement RFC-9208 IMAP QUOTA Extension



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

Benoit Tellier closed JAMES-3856.
-
Resolution: Fixed

> Implement RFC-9208 IMAP QUOTA Extension
> ---
>
> Key: JAMES-3856
> URL: https://issues.apache.org/jira/browse/JAMES-3856
> Project: James Server
>  Issue Type: Improvement
>  Components: IMAPServer
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> https://www.rfc-editor.org/rfc/rfc9208
> This updates the currently implemented quota extension (RFC-2087):
> {code:java}
>  10. Changes Since RFC 2087
> This document is a revision of [RFC2087], and it aims to clarify the meaning 
> of different terms that were used in that RFC. It also provides more 
> examples, gives guidance on allowed server behavior, defines an IANA registry 
> for quota resource types, and provides initial registrations for 4 of them.
> When compared with [RFC2087], this document defines two more commonly used 
> resource types, adds an optional OVERQUOTA response code, and defines two 
> extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The DELETED STATUS 
> data item must be implemented if the "QUOTA=RES-MESSAGE" capability is 
> advertised. The DELETED-STORAGE STATUS data item must be implemented if the 
> "QUOTA=RES-STORAGE" capability is advertised. For extensibility, quota usage 
> and quota limits are now 63-bit unsigned integers.
> {code}
> Please note that supporting IMAP STATUS DELETED is also a requirement for 
> IMAP4REV2 (RFC-9051).



--
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-3858) Implement RFC-8474 IMAP OBJECTID extension

Benoit Tellier created JAMES-3858:
-

 Summary: Implement RFC-8474 IMAP OBJECTID extension
 Key: JAMES-3858
 URL: https://issues.apache.org/jira/browse/JAMES-3858
 Project: James Server
  Issue Type: Improvement
  Components: IMAPServer
Reporter: Benoit Tellier
 Fix For: 3.8.0


https://www.rfc-editor.org/rfc/rfc8474.html

Leverages JMAP style identifier to help prevent clients to needlessly 
resynchronize (eg move from another client)



--
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-3857) Implement RFC-7889 IMAP APPENDLIMIT

2022-11-15 Thread Benoit Tellier (Jira)

Benoit Tellier created JAMES-3857:
-

 Summary: Implement RFC-7889 IMAP APPENDLIMIT
 Key: JAMES-3857
 URL: https://issues.apache.org/jira/browse/JAMES-3857
 Project: James Server
  Issue Type: Improvement
  Components: IMAPServer
Reporter: Benoit Tellier
 Fix For: 3.8.0


https://www.rfc-editor.org/rfc/rfc7889.html

Allows advertising the size limit for APPEND command.

 -> Add the APPENDLIMIT capability
 -> Add the APPENDLIMIT status item



--
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-3856) Implement RFC-9208 IMAP QUOTA Extension

2022-11-15 Thread Benoit Tellier (Jira)

Benoit Tellier created JAMES-3856:
-

 Summary: Implement RFC-9208 IMAP QUOTA Extension
 Key: JAMES-3856
 URL: https://issues.apache.org/jira/browse/JAMES-3856
 Project: James Server
  Issue Type: Improvement
  Components: IMAPServer
Reporter: Benoit Tellier
 Fix For: 3.8.0


https://www.rfc-editor.org/rfc/rfc9208

This updates the currently implemented quota extension (RFC-2087):


{code:java}
 10. Changes Since RFC 2087

This document is a revision of [RFC2087], and it aims to clarify the meaning of 
different terms that were used in that RFC. It also provides more examples, 
gives guidance on allowed server behavior, defines an IANA registry for quota 
resource types, and provides initial registrations for 4 of them.
When compared with [RFC2087], this document defines two more commonly used 
resource types, adds an optional OVERQUOTA response code, and defines two extra 
STATUS data items ("DELETED" and "DELETED-STORAGE"). The DELETED STATUS data 
item must be implemented if the "QUOTA=RES-MESSAGE" capability is advertised. 
The DELETED-STORAGE STATUS data item must be implemented if the 
"QUOTA=RES-STORAGE" capability is advertised. For extensibility, quota usage 
and quota limits are now 63-bit unsigned integers.
{code}

Please note that supporting IMAP STATUS DELETED is also a requirement for 
IMAP4REV2 (RFC-9051).




--
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-3855) Supports IMAP UNAUTHENTICATE (RFC-8437)

2022-11-15 Thread Benoit Tellier (Jira)

Benoit Tellier created JAMES-3855:
-

 Summary: Supports IMAP UNAUTHENTICATE (RFC-8437)
 Key: JAMES-3855
 URL: https://issues.apache.org/jira/browse/JAMES-3855
 Project: James Server
  Issue Type: Improvement
  Components: IMAPServer
Reporter: Benoit Tellier
 Fix For: 3.8.0


https://www.rfc-editor.org/rfc/rfc8437.html

Usefull for administrative tasks.



--
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-3851) TLS host name verification should handle trailing dot

2022-11-15 Thread Karsten Otto (Jira)



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

Karsten Otto closed JAMES-3851.
---
Resolution: Fixed

> TLS host name verification should handle trailing dot
> -
>
> Key: JAMES-3851
> URL: https://issues.apache.org/jira/browse/JAMES-3851
> Project: James Server
>  Issue Type: Bug
>  Components: Remote Delivery
>Affects Versions: master
>Reporter: Karsten Otto
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I noticed that sometimes RemoteDelivery opens a connection using a fully 
> qualified hostname that ends with a trailing dot, like "mail.example.org." I 
> believe James may get that from MX resolving, since afaik DNS servers may do 
> this to indicate an absolute FQDN vs. a relative one. This is not an issue 
> when establishing a connection, but will break TLS hostname verification, 
> since the CN and SubjectAltNames in server certificates never use trailing 
> dots.
> Consequently, RemoteDelivery should strip a trailing dot from the hostname 
> before connecting.



--
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] [Updated] (JAMES-3854) Support RFC-8438IMAP STATUS=SIZE



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

Benoit Tellier updated JAMES-3854:
--
Parent: JAMES-3754
Issue Type: Sub-task  (was: Improvement)

> Support RFC-8438IMAP STATUS=SIZE
> 
>
> Key: JAMES-3854
> URL: https://issues.apache.org/jira/browse/JAMES-3854
> Project: James Server
>  Issue Type: Sub-task
>  Components: IMAPServer
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>
> https://datatracker.ietf.org/doc/html/rfc8438.html 
> Requirement to qualify as an IMAP REV 2 server...



--
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] [Updated] (JAMES-3854) Support RFC-8438 IMAP STATUS=SIZE



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

Benoit Tellier updated JAMES-3854:
--
Summary: Support RFC-8438 IMAP STATUS=SIZE  (was: Support RFC-8438IMAP 
STATUS=SIZE)

> Support RFC-8438 IMAP STATUS=SIZE
> -
>
> Key: JAMES-3854
> URL: https://issues.apache.org/jira/browse/JAMES-3854
> Project: James Server
>  Issue Type: Sub-task
>  Components: IMAPServer
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: 3.8.0
>
>
> https://datatracker.ietf.org/doc/html/rfc8438.html 
> Requirement to qualify as an IMAP REV 2 server...



--
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-3854) Support RFC-8438IMAP STATUS=SIZE

Benoit Tellier created JAMES-3854:
-

 Summary: Support RFC-8438IMAP STATUS=SIZE
 Key: JAMES-3854
 URL: https://issues.apache.org/jira/browse/JAMES-3854
 Project: James Server
  Issue Type: Improvement
  Components: IMAPServer
Affects Versions: master
Reporter: Benoit Tellier
 Fix For: 3.8.0


https://datatracker.ietf.org/doc/html/rfc8438.html 

Requirement to qualify as an IMAP REV 2 server...



--
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-3853) Support IMAP XLIST

Benoit Tellier created JAMES-3853:
-

 Summary: Support IMAP XLIST
 Key: JAMES-3853
 URL: https://issues.apache.org/jira/browse/JAMES-3853
 Project: James Server
  Issue Type: Improvement
  Components: IMAPServer
Reporter: Benoit Tellier
 Fix For: 3.8.0


h3. Why?

My special case mailboxes do not get recognised by IMAP clients (they miss the 
"role" information).

See https://github.com/linagora/james-project/issues/3960 

h3. How?

Provide a default typer for the already implemented XList extension,
Write a test,
And see if this works...

h3. Longer term options

https://www.rfc-editor.org/rfc/rfc6154 deprecated XList but is slightly harder 
to implement...



--
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-3852) Subscriptions for non personal mailboxes