I believe I’ve found a conformity problem on Email/get and parse.
See detail in the PR (auto-closed and that’s fine, but for explanations/code visibility)
Expected Behavior
JMAP server should be conform to the RFC
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
FoundationDB
Blob Storage
S3-compatible
Search Engine
MySQL
Directory Backend
Internal
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
Thanks for the detailed report and for linking the PR with the reproduction/code walkthrough. Looking at the relevant code, Email/get and Email/parse only populate bodyValues for parts where part.body matches ArchivedMetadataPartType::Text or ArchivedMetadataPartType::Html:
if ((contents.is_html_part(part_id as u16)
&& (fetch_all_body_values || fetch_html_body_values))
|| (contents.is_text_part(part_id as u16)
&& (fetch_all_body_values || fetch_text_body_values)))
&& matches!(
part.body,
ArchivedMetadataPartType::Text | ArchivedMetadataPartType::Html
)
(crates/jmap/src/email/get.rs, mirrored in crates/jmap/src/email/parse.rs). This confirms your observation: the matches! guard restricts inclusion to those two concrete MIME part types rather than any text/* subtype (e.g. text/calendar, text/csv, etc. that is_text_part may otherwise flag as text). This does look like a real conformance gap against RFC 8621’s requirement that fetchAllBodyValues include any text/* part.
This is a bug report on server behavior rather than a documented configuration question, so I won’t speculate further on intended fix, a human maintainer will follow up on the report and PR.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.