Vandelay: fetching from OVH Hosted Exchange issue

Issues
1

Issue Description

vandelay import imap skips every message on OVH — Exchange’s RFC822.SIZE ≠ fetched BODY, vandelay strictly skips the mismatch (coordinator.rs:923). Confirmed: 160/160 skipped

Expected Behavior

pulling in emails via Hosted Exchange imap import

Actual Behavior

Notable pattern: BODY consistently ~⅓ of RFC822.SIZE (6298 vs 19189) — yet our own imaplib BODY.PEEK fetch gets the full message (proven: import succeeded). So the data is intact/fetchable; vandelay discards it.

Reproduction Steps

  1. A Microsoft Exchange mailbox with real messages (here: OVH Hosted Exchange SE, ex5.mail.ovh.net:993 IMAPS, basic auth).
  2. vandelay 1.0.4.
  3. Run — fails even at minimal concurrency:
    VANDELAY_PASSWORD=… vandelay import imap
    –url imaps://ex5.mail.ovh.net:993 --auth-basic
    –imap-connections 1 --threads 1 --fetch-batch 1
    out.sqlite
  4. Observe: every UID logs
    folder “INBOX” uid 13: BODY 6298 bytes vs RFC822.SIZE 19189, skipping
  5. vandelay inspect out.sqlite → email 0, blobs 0 (silent total loss; exit looks OK).
  6. Contrast (proves data is intact): fetch the same UIDs with plain imaplib BODY.PEEK → returns the full RFC822 message; vandelay import maildir on those imports 100%.

Relevant Log Output

folder “INBOX” uid 13: BODY 6298 bytes vs RFC822.SIZE 19189, skipping
folder “INBOX” uid 20: BODY 8803 bytes vs RFC822.SIZE 23371, skipping
folder “INBOX” uid 21: BODY 6707 bytes vs RFC822.SIZE 18705, skipping
folder “Deleted Items” uid 1023: BODY 7776 bytes vs RFC822.SIZE 30926, skipping
folder “Deleted Items” uid 1024: BODY 7703 bytes vs RFC822.SIZE 25513, skipping
folder “Deleted Items” uid 1025: BODY 7620 bytes vs RFC822.SIZE 25156, skipping

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

FoundationDB

Blob Storage

S3-compatible

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

Let me look into the Vandelay IMAP import code to understand this size-check behavior.

Vandelay is a separate tool (not part of the Stalwart server or CLI repos tracked here), so its source code – including coordinator.rs line 923 – is not available for inspection in this context. That said, the bug you’ve found is clear and well-documented in your report:

The issue is that Vandelay fetches RFC822.SIZE alongside BODY[] in a single FETCH command, then compares the two as a sanity check. OVH Hosted Exchange returns a compressed/partial BODY[] response that is consistently about 1/3 of the declared RFC822.SIZE, causing Vandelay to discard every message as corrupt – even though the data is fully intact and fetchable via a separate BODY.PEEK[] request.

Your workaround (fetch via BODY.PEEK[] then import as Maildir) confirms the data itself is fine. The fix would need to be in Vandelay itself, either:

  • Making the RFC822.SIZE vs BODY[] size check a warning rather than a hard skip, or
  • Using a separate BODY.PEEK[] fetch (as you demonstrated works), or
  • Adding a --no-size-check / lenient flag for non-RFC-compliant servers.

Since Vandelay’s source is not in the repositories available here, and this appears to be a bug in Vandelay’s strict size validation against a non-compliant Exchange IMAP server, a human maintainer will need to address this in the Vandelay codebase directly.

Your workaround of fetching via imaplib BODY.PEEK[] and importing via vandelay import maildir is the correct path forward until this is fixed upstream.

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