[
https://issues.apache.org/jira/browse/JAMES-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110773#comment-17110773
]
Benoit Tellier commented on JAMES-2997:
---------------------------------------
https://github.com/linagora/james-project/pull/3383 is merged and fix a bug:
MIME message converter was throwing when name was both specified in attachment
metadata and ContentType header.
The expected behaviour is that attachment metadata name overrides the one of
the ContentType header.
> hasAttachment SHOULD be metadata read level
> -------------------------------------------
>
> Key: JAMES-2997
> URL: https://issues.apache.org/jira/browse/JAMES-2997
> Project: James Server
> Issue Type: Improvement
> Reporter: René Cordier
> Priority: Major
> Fix For: 3.6.0
>
>
> The description is well detailed in this mail :
> https://www.mail-archive.com/[email protected]/msg63511.html
> We are working on JMAP, and EMail::hasAttachments metadata is listed as
> a fast property.
> However to retrieve it today, we need to do a full message read in order
> to load attachment (as JMAP hasAttachment do not take inlined
> attachments into account and mailbox property do).
> Also, while inspecting the code, MessageResult::getLoadedAttachments is
> never used with attachment bytes. This means that given an email with a
> 10 MB attachment, upon GetMessages call with full profile, we are going
> to read the full eml (10 MB) then load attachment bytes (10 MB) while
> the attachment could have not been loaded in the first place. In our
> little example we read 20MB while only 10 MB could have been necessary.
> This attachment over-reading results in both performance and cost issue
> on the object storage - what is the topic me, René and Duc are currently
> working on.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
