JMAP submitted mail discarded as duplicate when sent to self

[tamisoft]

Issue Description

I have sent an email to myself using Email/set and EmailSubmission/set calls over jmap but the mail never arrived. My assumption is that the server generated the message ID on JMAP call, and for the smtp submission it didn't change it. So the sent folder stored mail has the same message id as the one coming from the submission path.

Expected Behavior

mail should arrive, the sent items message id should be different from the sent one.

Actual Behavior

"Skipping duplicate message" due to matching messageids

Reproduction Steps

1. send a mail to the same address as the from, jmap call: {"using":["urn:ietf:params:jmap:core","urn:ietf:params:jmap:mail","urn:ietf:params:jmap:submission"],"methodCalls":[["Email/set",{"accountId":"q","update":{"3eq2aahzeh":{"keywords/$draft":false,"keywords/$seen":true,"mailboxIds":{"e":true}}}},"0"],["EmailSubmission/set",{"accountId":"q","create":{"1":{"emailId":"3eq2aahzeh","identityId":"r"}}},"1"]]}
2. observe stalwart logs

Relevant Log Output

Sun, 12 Apr 2026 10:15:29 INFO Delivery attempt ended queueId = 301356820220394956, queueName = "local", from = "user@domain.tld", to = ["user@domain.tld"], size = 1142, total = 1, elapsed = 160ms
Sun, 12 Apr 2026 10:15:29 INFO Delivery completed queueId = 301356820220394956, queueName = "local", from = "user@domain.tld", to = ["user@domain.tld"], size = 1142, total = 1, elapsed = 0ms
Sun, 12 Apr 2026 10:15:29 INFO DSN success notification queueId = 301356820220394956, queueName = "local", from = "user@domain.tld", to = ["user@domain.tld"], size = 1142, total = 1, to = "user@domain.tld", hostname = "localhost", code = 250, details = "OK"
Sun, 12 Apr 2026 10:15:29 INFO Skipping duplicate message queueId = 301356820220394956, queueName = "local", from = "user@domain.tld", to = ["user@domain.tld"], size = 1142, total = 1, accountId = 16, messageId = "18a58ab1ea273adc.c2b6a6188b037a0a.aaecc4e1cc9171@[REDACTED]"
Sun, 12 Apr 2026 10:15:29 INFO New delivery attempt for domain queueId = 301356820220394956, queueName = "local", from = "user@domain.tld", to = ["user@domain.tld"], size = 1142, total = 1, domain = "domain.tld"
Sun, 12 Apr 2026 10:15:29 INFO Delivery attempt started queueId = 301356820220394956, queueName = "local", from = "user@domain.tld", to = ["user@domain.tld"], size = 1142, total = 1
Sun, 12 Apr 2026 10:15:29 INFO Queued message submission for delivery queueId = 301356820220394956, from = "user@domain.tld", to = ["user@domain.tld"], size = 1142, nextRetry = 2026-04-12T07:15:29Z, nextDsn = 2026-04-13T07:15:29Z, expires = 2026-04-15T07:15:29Z
Sun, 12 Apr 2026 10:15:29 INFO ARC verification passed strict = false, result = No DKIM signature (dkim.none), elapsed = 0ms
Sun, 12 Apr 2026 10:15:29 INFO DKIM verification failed strict = false, result = [], elapsed = 0ms
Sun, 12 Apr 2026 10:15:29 INFO SMTP RCPT TO command to = "user@domain.tld"
Sun, 12 Apr 2026 10:15:29 INFO SMTP MAIL FROM command from = "user@domain.tld"
Sun, 12 Apr 2026 10:15:24 INFO Message appended via JMAP listenerId = "http", localPort = 8080, remoteIp = 127.0.0.1, remotePort = 54834, accountId = 16, documentId = 255111, mailboxId = [3], blobId = "916f70c93ac866c02ae0268d68765d7b169828a35586728227dbbde024adaf34", changeId = 378750, messageId = "18a58ab1ea273adc.c2b6a6188b037a0a.aaecc4e1cc9171@[REDACTED]", size = 320, elapsed = 26ms

Stalwart Version

v0.15.x

Installation Method

Binary (Linux)

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

No response

I acknowledge that:

• I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
• I have searched the Stalwart repository (both open and closed Discussions and Issues) and confirm this is not a duplicate.
• I have set the logging level to trace and included relevant log output if applicable.
• I agree to follow the project's Code of Conduct.

[tamisoft]

A solution has been created in jmap webmail : root-fr/jmap-webmail#60
So depending on what the RFC says about this, it might not be a stalwart issue, because there seems to be the above way around it. If this is a protocol ambiguity, then it should be addressed somewhere before jmap becomes the next imap.

[tamisoft]

It looks like that workaround didn't fix this problem.

[mdecimus]

Have you tried with v0.16?

[tamisoft]

Can't test yet, migration fails spectacularly #3004 (reply in thread) :)
I will wait a bit, upgrading doesn't seem to be smooth sailing. Will keep trying but probably only on a replica server.