IETF Logo Mail Archive

[JMAP] Re: \Deleted & EXPUNGE semantics between IMAP and JMAP

Mauro De Gennaro <mauro@stalw.art> Wed, 19 August 2026 08:30 UTC

Return-Path: <mauro@stalw.art>
X-Original-To: jmap@mail2.ietf.org
Delivered-To: jmap@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E165A12C1997E for <jmap@mail2.ietf.org>; Wed, 19 Aug 2026 01:30:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787128248; bh=BOaflvU4+K2Y/ekHq1ImHg55N7dj1mvsuyLX1Luo5LI=; h=From:Subject:Date:References:To:In-Reply-To; b=vByAuajm/jOpRb1BVX54ddfcsm7NULiDQb4bkt2ymzbIOetJL08lbbMClO9xTu+BC jgM2KU5GgPnGa0YQqRTTwaERgs39GktMke2XH3csrX1zSjfZ3cJG6Dyui3pLHfRsKr ZFuWtweDfxZTB/maV/TGEY8gsygjqqz92PLapiko=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=stalw.art header.b="xKGvWHtz"; dkim=pass (2048-bit key) header.d=stalw.art header.b="Q312qoM8"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iHUEJVoOQOu for <jmap@mail2.ietf.org>; Wed, 19 Aug 2026 01:30:47 -0700 (PDT)
Received: from mail.stalw.art (mail.stalw.art [135.181.195.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A5CEF12C19975 for <jmap@ietf.org>; Wed, 19 Aug 2026 01:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; s=v1-ed25519-20260717; d=stalw.art; c=relaxed/relaxed; r=y; h=Message-Id:To:Date:Subject:From; t=1787128240; bh=BOaflvU4+K2Y/ekHq1ImHg5 5N7dj1mvsuyLX1Luo5LI=; b=xKGvWHtz6PM+GKsi9WLE0d3vml0/UaFO4z9SEwkBV6vtG+1tNa TDtXLHjLT6R4N2SwqLl3JpgG31AB4gKc3GAA==;
DKIM-Signature: v=1; a=rsa-sha256; s=v1-rsa-20260717; d=stalw.art; c=relaxed/relaxed; r=y; h=Message-Id:To:Date:Subject:From; t=1787128240; bh=BOaflvU4+K2Y/ekHq1ImHg5 5N7dj1mvsuyLX1Luo5LI=; b=Q312qoM8v2JaICIEDpZbouVCUYg6y9owdJ1/EK9gCFLQgrW5h/ wX18EIKnF8awwsBua2a/NVzkGnxmMe2X0wSfvkotWqHuTC1qE8o5PTunYUDOs4aPjbapOO6+6BP uQ0jno1T2m3AFSEZVfaIdme4+bSXnHI+7gCRBfowJ3r0Wzdebz3JBMJcx28W7iYvDquPqVi654S IIixVg9IJr22BRk7kkgR3o4+uabMk6kFAz2GbgnyH/jKLPudRsxi+w0NQUb/Hat3bWrZkQAVdYb qR5hzFMeyumvV1WlSE+K3oH+F3/RQdJhFZQ+ProTrQG9DhAWlF3Clmwjg/gY0qE1esA==;
Message-Instance: m=1; h=sha256:jbswQEUC8GHccPCJXhKUOEQFRCvy/aybAQAjWTQu WMc=:BOaflvU4+K2Y/ekHq1ImHg55N7dj1mvsuyLX1Luo5LI=;
DKIM2-Signature: i=1; m=1; t=1787128240; d=stalw.art; mf=PG1hdXJvQHN0YWx3 LmFydD4=; rt=PGptYXBAaWV0Zi5vcmc+; s=v2-ed25519-20260704:ed25519-sha256: +gjW4r9yTVYfocEUF4/8VVrhXSUEMVlTa4lgzQcRtZbtdknH4mggG+9sXL3wkaeNzML+YNOP oqkHK6KbR8pvBA==;
From: Mauro De Gennaro <mauro@stalw.art>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Date: Wed, 19 Aug 2026 10:30:29 +0200
References: <30db2f7d-4978-4e2b-8123-768b7e0aeda0@mail.infomaniak.com> <3b7b9aa1-b51f-4aa9-ae32-a69e55f3803c@app.dogfood.fastmail.com>
To: JMAP IETF <jmap@ietf.org>
In-Reply-To: <3b7b9aa1-b51f-4aa9-ae32-a69e55f3803c@app.dogfood.fastmail.com>
Message-Id: <D66F7D79-ADF7-4159-9166-0A0BFAB9B2E7@stalw.art>
X-Mailer: Apple Mail (2.3864.600.51.1.1)
Message-ID-Hash: RM33UROWWBCA5VVEPT4JH6QTCWP6R3V2
X-Message-ID-Hash: RM33UROWWBCA5VVEPT4JH6QTCWP6R3V2
X-MailFrom: mauro@stalw.art
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jmap.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [JMAP] Re: \Deleted & EXPUNGE semantics between IMAP and JMAP
List-Id: JSON Meta Access Protocol <jmap.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/cOIrGstiDj0wcVZRgkzuE-4SQjE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Owner: <mailto:jmap-owner@ietf.org>
List-Post: <mailto:jmap@ietf.org>
List-Subscribe: <mailto:jmap-join@ietf.org>
List-Unsubscribe: <mailto:jmap-leave@ietf.org>

>> I looked at how existing servers handle this:
>> - Stalwart seems to defer everything to EXPUNGE
> 
> That sounds buggy to me — you'd see it as deleted in IMAP but still present over JMAP?

Stalwart does not conform to the MUST NOT in RFC 8621 Section 4.1.1, for three reasons:

1) The JMAP change log is shared with the IMAP QRESYNC/CONDSTORE change log. A message that is deleted (and expunged) appears both in the IMAP VANISHED response and in Email/changes under "destroyed."
2) A message with a \Deleted flag that doesn't exist in JMAP breaks the JMAPACCESS extension, since OBJECTID does not support EMAILID NIL (this won't be an issue with OBJECTID+, though).
3) An IMAP client toggling the \Deleted flag on and off multiple times would require the server to generate multiple unique JMAP email IDs, plus add delete/insert entries to the JMAP /changes log, which in my opinion is wasteful.

Instead, Stalwart exposes the $deleted flag to JMAP clients. I'd argue that a well-behaved IMAP client will set the \Deleted flag and shortly after EXPUNGE those messages, so the window during which this $deleted flag is visible to JMAP clients is very brief.


Best,
Mauro

v2.46.0 | Report a Bug | By Email | System Status