[
https://issues.apache.org/jira/browse/JAMES-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
omerfarukicen updated JAMES-4172:
---------------------------------
Description:
In \{{EmailBodyPartBlob}} (DownloadRoutes.scala), the \{{size}} and
\{{content}}
methods use different calculation paths for non-SingleBody parts
(such as message/rfc822):
- *size*: Uses \{{SizeUtils.sizeOf(entity)}} which relies on
\{{SingleBody.size()}} — this returns the *decoded* size
(since BasicBodyFactory decodes content-transfer-encoding during parsing)
- *content*: Uses \{{DefaultMessageWriter.writeBody()}} which *re-encodes*
the content (e.g. base64), producing more bytes than the decoded size
Steps ReProducce:
1. Send an email containing an embedded message/rfc822 part
(e.g. a KEP signed email with AttachedMimeMessage)
2. The inner message should contain multiple base64-encoded attachments
3. Use Email/parse on the message/rfc822 blob — attachments are listed correctly
4. Download the same blob via /download endpoint using curl
5. The downloaded .eml file is truncated — missing attachments and
closing MIME boundaries
was:
[https://github.com/apache/james-project/tree/postgresql]
Apache James Distributed -> Postgresql branch
Related Epic: JAMES-3226 (Postgres message store)
When a Dispatch(ek-1) message contains multiple parts, all parts are currently
stored in ObjectStorage and also persisted in the {{attachment}} table.
However, since we are using JMAP, these parts are already represented as
“virtual parts,” making the extra ObjectStorage write redundant.
In the JPA project, this behavior is configurable and can be disabled.
But in the PostgreSQL project, it is currently mandatory.
To align the PostgreSQL behavior with JPA and to avoid unnecessary storage
operations, we should make attachment storage {*}optional{*}.
Introduce a configuration option (e.g., {{{}attachmentStorageEnabled{}}}) to
enable or disable attachment persistence for PostgreSQL.
When disabled, attachments should not be stored in ObjectStorage or the
{{attachment}} table.
{{if (mapperFactory.isAttachmentStorageEnabled()) {
return new MessageStorer.WithAttachment...}}
> JMAP blob download for message/rfc822 parts returns truncated content due to
> Content-Length mismatch
> ----------------------------------------------------------------------------------------------------
>
> Key: JAMES-4172
> URL: https://issues.apache.org/jira/browse/JAMES-4172
> Project: James Server
> Issue Type: Improvement
> Components: Blob, jpa
> Affects Versions: 3.9.0
> Reporter: omerfarukicen
> Priority: Critical
> Fix For: 3.9.0
>
>
> In \{{EmailBodyPartBlob}} (DownloadRoutes.scala), the \{{size}} and
> \{{content}}
> methods use different calculation paths for non-SingleBody parts
> (such as message/rfc822):
> - *size*: Uses \{{SizeUtils.sizeOf(entity)}} which relies on
> \{{SingleBody.size()}} — this returns the *decoded* size
> (since BasicBodyFactory decodes content-transfer-encoding during parsing)
> - *content*: Uses \{{DefaultMessageWriter.writeBody()}} which *re-encodes*
> the content (e.g. base64), producing more bytes than the decoded size
> Steps ReProducce:
> 1. Send an email containing an embedded message/rfc822 part
> (e.g. a KEP signed email with AttachedMimeMessage)
> 2. The inner message should contain multiple base64-encoded attachments
> 3. Use Email/parse on the message/rfc822 blob — attachments are listed
> correctly
> 4. Download the same blob via /download endpoint using curl
> 5. The downloaded .eml file is truncated — missing attachments and
> closing MIME boundaries
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
