Incorrect RFC822.TEXT response

Issues
1

Issue Description

Hello,

I noticed Stalwart returns headers + email body on FETCH RFC822.TEXT IMAP request. However, according to IMAP (RFC 3501) specification it must return body only.

Could this be fixed shortly please.

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

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.

on

2

Looking at the source, this appears to be a genuine bug. In crates/imap/src/op/fetch.rs, the handler for Attribute::Rfc822Text builds the response using raw_message.get_full_range(), i.e. the entire raw message (headers + body):

Attribute::Rfc822Text => {
    items.push(DataItem::Rfc822Text {
        contents: raw_message.get_full_range(),
    });
}

By contrast, RFC822.HEADER correctly slices only up to offset_body. Per RFC 3501, RFC822.TEXT is defined as equivalent to BODY[TEXT], i.e. the message body only, so it should be using a slice starting at offset_body rather than the full range. This looks like a real defect in the fetch implementation rather than intended behavior, and confirms what you’re seeing.

I can’t push a fix myself, but this report is well grounded in the code and a human maintainer will follow up on it.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

This has been fixed some weeks ago in the v1.0.0 branch. The fix can’t be backported to 0.16.x but we expect v1 version to be released at the end of October or early November.