feat: jmap support - part 2 by SebastianKrupinski · Pull Request #12800 · nextcloud/mail

SebastianKrupinski · 2026-04-23T23:17:18Z

Summary

Adds a protocol abstraction so Mail can talk to both IMAP and JMAP servers through a
common set of interfaces, and reworks the existing IMAP code to implement them.

Resolves: Read-only JMAP Support #12610
Resolves: JMAP Write Operations #12611
Requires: feat: jmap support - part 1 #12711
Implements ProtocolFactory — selects the right connector for an account's protocol
Implements IMailboxConnector (+ ImapMailboxConnector, JmapMailboxConnector)
Implements IMessageConnector (+ ImapMessageConnector, JmapMessageConnector)

Scope

This PR covers mailbox operations and message operations ONLY.
Sending operations are in feat: jmap support - part 2b #12871.
DB changes (remote id / sync state columns) required for feat: jmap support - part 1 #12711

Automated tests

composer psalm clean
composer test:unit green
composer test:integration green
composer cs:check clean

Testing

Every operation that talks to an external server must be tested twice — once against an IMAP account/server and once against a JMAP account/server.

Copy a block below into a comment and tick the boxes for the server you tested against.
Each operation has one checkbox per protocol.

Mailbox operations

List / sync folders
- IMAP
- JMAP
Create in root folder
- IMAP
- JMAP
Create in another folder
- IMAP
- JMAP
Rename in root folder
- IMAP
- JMAP
Rename in another folder
- IMAP
- JMAP
Delete in root folder
- IMAP
- JMAP
Delete in another folder
- IMAP
- JMAP
Subscribe / unsubscribe
- IMAP
- JMAP
Empty / clear mailbox
- IMAP
- JMAP

Message operations

List / sync messages
- IMAP
- JMAP
Fetch message
- IMAP
- JMAP
Download raw message (show source / .eml)
- IMAP
- JMAP
Download attachments
- IMAP
- JMAP
Search messages
- IMAP
- JMAP
Move message
- IMAP
- JMAP
Move thread
- IMAP
- JMAP
Delete message
- IMAP
- JMAP
Delete thread
- IMAP
- JMAP
Flag message (read/unread, etc.)
- IMAP
- JMAP
Tag message (set/unset)
- IMAP
- JMAP
Quota (usage reported)
- IMAP
- JMAP

Console operations

SebastianKrupinski

.

SebastianKrupinski · 2026-08-06T18:11:09Z

Made it till JmapMailboxConnector

Thank you, for getting that far

SebastianKrupinski · 2026-08-19T17:24:04Z

@kesselb

I have addressed / changed all requested via comments... will clean up CI once code is approved.

kesselb · 2026-08-19T22:17:53Z

I moved the psalm-types to the class level docblock, otherwise the import from other classes wont work.

SebastianKrupinski · 2026-08-19T22:19:54Z

I moved the psalm-types to the class level docblock, otherwise the import from other classes wont work.

Saw that thank you. I address the last comment you made

kesselb · 2026-08-19T23:52:47Z

-		} finally {
-			$client->logout();
+		// update local store
+		$this->dbMessageMapper->updateBulk($account, false, ...$mutatedMessages);


One would assume MessageMapper::updateBulk() would update entities in one go, but that's apparently not the case ;)

I'd agree it would be nice to have more batch methods (like moveMessages), but I'd see that as its own feature, and would really appreciate keeping this PR focused on the necessary changes. So far I don't see why JMAP needs a moveMessages method.

The updateBulk() call here is dead code because it never writes mailbox_id/uid, so it can't do what these two call sites need it to do.

IMAP has two paths calling deleteByUid:

lib/Cache/Cache.php deleteMsgs

MessageCacheUpdaterListener, in response to a MessageDeletedEvent

moveMessages and moveMessage no longer emit MessageDeletedEvent. That's a regression and should be resolved.

I'd prefer to keep moveMessages out. If the method has to stay, it must emit MessageDeletedEvent.

So far I don't see why JMAP needs a moveMessages method.

JMAP operates in bulk by design a single request moves N messages, there's no per-message round trip. Restricting this PR to single-message moves would mean adding a batch capability that the protocol already gives us for free, only to bolt it back on in a follow-up. All the connector interfaces here already operate on Message ...$messages for the other operations (flag, tag, delete); moveMessages being singular would be the outlier, not the norm. Also I don't understand the lets fix it later approach that we never end up doing... since the mail manager had to be re-write to be protocol agnostic... why not do it correctly from the start, why handicap the new protocol with the bad logic from the old one.

The updateBulk() call here is dead code because it never writes mailbox_id/uid,

Ugh... another thing that makes no sense... why are we matching the rows by mailbox_id and uid when there is a perfectly fine record id...

Okay, I've changed the code to push the changes row by row. This should get refactored into a real bulk update-by-id later, since updateBulk() as written can't do it — it never writes mailbox_id/uid at all.

That's a regression and should be resolved.

Fixed

SebastianKrupinski · 2026-08-26T13:57:00Z

@kesselb

I have addressed / changed all requested in your most recent comments

ChristophWurst · 2026-08-31T14:06:33Z

@DerDreschner since you tested this positively, could you please review and approve? Thanks

ChristophWurst

As far as I can see you removed the explicit try-finally handling of IMAP connections as resource.
There is no replacement mechanism to manage them.

Doesn't this mean that we might end up with a pile of open connections by the end of a cron execution but possibly also during initial sync when we need to hop between caching and non-caching clients?

As a reminder, there is a common per-IP connection limit on mail servers. IIRC it was five connections per IP for Dovecot. That would bite us rather quickly.

SebastianKrupinski · 2026-08-31T20:36:03Z

As far as I can see you removed the explicit try-finally handling of IMAP connections as resource. There is no replacement mechanism to manage them.

Doesn't this mean that we might end up with a pile of open connections by the end of a cron execution but possibly also during initial sync when we need to hop between caching and non-caching clients?

The last commit addresses the open connections

As a reminder, there is a common per-IP connection limit on mail servers. IIRC it was five connections per IP for Dovecot. That would bite us rather quickly.

As for this connection reuse/caching is on my list of after this is merged follow ups,

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

Pure rename with no behavior or signature change, unrelated to the JMAP protocol work (flagged in review as noise). Restores the name main already uses. Assisted-by: ClaudeCode:claude-opus-4-8 Signed-off-by: Christoph Wurst <1374172+ChristophWurst@users.noreply.github.com>

The rename touched the OCS route id (mail.messages.getSource -> ...getRawMessage) with no behavior change and no stated reason, unrelated to the JMAP protocol work. Restore the original name to drop this from the JMAP diff; the OCS route id and controller/service method name are back to what main already has. Assisted-by: ClaudeCode:claude-opus-4-8 Signed-off-by: Christoph Wurst <1374172+ChristophWurst@users.noreply.github.com>

SebastianKrupinski self-assigned this Apr 23, 2026

SebastianKrupinski added this to 💌 📅 👥 Groupware team Apr 23, 2026

SebastianKrupinski added the 2. developing label Apr 23, 2026

github-project-automation Bot moved this to 🏗️ In progress in 💌 📅 👥 Groupware team Apr 23, 2026

SebastianKrupinski force-pushed the feat/jmap-2 branch from f3ed4a9 to c56f384 Compare April 24, 2026 19:14

SebastianKrupinski changed the base branch from main to feat/jmap-1 April 24, 2026 19:16

SebastianKrupinski changed the base branch from feat/jmap-1 to main April 24, 2026 19:16

SebastianKrupinski force-pushed the feat/jmap-2 branch 23 times, most recently from 3b35d0b to ee47083 Compare May 4, 2026 13:28

SebastianKrupinski commented Aug 6, 2026

View reviewed changes

kesselb reviewed Aug 11, 2026

View reviewed changes

SebastianKrupinski mentioned this pull request Aug 18, 2026

feat: add endpoint to set message flags via the OCS API #13505

Open

kesselb reviewed Aug 19, 2026

View reviewed changes

ChristophWurst reviewed Aug 31, 2026

View reviewed changes

This was referenced Sep 1, 2026

refactor(imap): revert getSource -> getRawMessage rename #13610

Merged

refactor(imap): revert getMessagesByMessageId -> getByMessageId rename #13612

Merged

SebastianKrupinski and others added 16 commits September 15, 2026 08:31

feat: jmap support - part 2

384ad28

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

14e6c33

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

e1f7b3e

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

c0c1d76

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

3cdd595

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

0c10d47

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

7c4b467

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

dd858db

fixup! feat: jmap support - part 2

34cf490

fixup! feat: jmap support - part 2

ffefccc

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

b7c4e45

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

165ba35

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

979df99

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

fixup! feat: jmap support - part 2

fe0b73c

Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>

Conversation

SebastianKrupinski commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Scope

Automated tests

Testing

Mailbox operations

Message operations

Console operations

Uh oh!

SebastianKrupinski left a comment

Choose a reason for hiding this comment

Uh oh!

SebastianKrupinski commented Aug 6, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SebastianKrupinski commented Aug 19, 2026

Uh oh!

kesselb commented Aug 19, 2026

Uh oh!

SebastianKrupinski commented Aug 19, 2026

Uh oh!

Uh oh!

Uh oh!

kesselb Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

SebastianKrupinski Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

SebastianKrupinski commented Aug 26, 2026

Uh oh!

ChristophWurst commented Aug 31, 2026

Uh oh!

ChristophWurst left a comment

Choose a reason for hiding this comment

Uh oh!

SebastianKrupinski commented Aug 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

SebastianKrupinski commented Apr 23, 2026 •

edited

Loading