Someone please save me a lot of time trying to chase the code- when a user’s Delta app (Android or Desktop) sends a read receipt, how is it technically delivered? Which port on the chatmail relay is receiving the RR message? Need the nuts & bolts answer to help debug.
The problem: my friend and I have been chatting forever and RRs have been working just fine. About 4-ish days ago his end stopped sending RRs (or it’s trying and failing).
He can see RRs on his messages to me (double checks), all apps
We receive each others actual chat messages fine
It’s happening across clients (android, linux, macos)
No errors/logs on the relay I can find (I’m the sysop)
His port 25 outbound is blocked (or was when we tested)
Every once in awhile I’ll get a RR double check on one message (random)
We both all the latest apps (2.49.1) and two relays, with my relay being the primary/sending relay. I’m sorta kinda somewhat convinced it’s due to port 25 being blocked on his end (maybe sporadically?), “maybe his ISP is thinking he’s sending spam” was a thought. But only RRs? Hrm.
Just sort of scratching my head - the old turn it off and back on again didn’t help anything. No app upgrades recently, same old relay server… hrm.
Sadly no, not as simple as that (I wish). And it’s sporadic - looking at yesterday:
at 2:22pm, a msg I sent has no RR on my end, boooo (this is the norm now)
he sends a bunch of msgs and says he sees 2x RR checkmarks
at 2:31pm, a msg I sent has a RR! woo!
at 2:32pm, another msg I sent has RR! woo!
at 2:33pm, a msg I sent does not have any RR. boooooo
(no RRs since then, many msgs back and forth)
This is what I mean by random - minutes apart, different results. Head scratching.
Edit: bit more info uncovered, I have a broadcast channel for relay news and recently sent messages for the Debian upgrade/reboot cycle. My metadata shows other people have read the news but he hasn’t (but I’m sure he has). So I think this means the relay is working OK.
Could it be related to us being connected to a second relay for backup and app sending is getting confused? (even though it’s not set as the preferred sender). There’s no way to easily disable a relay without deleting it (which then loses userpass because it can’t be copied out).
I wonder if the messages you send to him at friend@X.io somehow sometimes get their read reciepts from the other e-mail address on another relay, say friend@Y.org. Logically that should not happen as both ends should send to the last-known address.
I think your brain is onto something - we just did a quick set of tests when he had a free minute.
our existing chat using 2 relays continues to experience problems. we’re chatting, 4 of my messages show RR, then all the sudden 2 messages don’t. back and forth, it “sometimes works”. But he is seeing/reading my messages regardless of double checkmarks
we both created new test profiles only on my relay, the RRs are instant and appear to be working without any problems at all (desktop app only for this one). we’re going to leave this side chat open for testing
The next logical test would be disable one of the relays and test, but our only option is to delete that relay completely (and we don’t actually know if this is the problem) then create a new account when done. Given the new test accounts working fine, I don’t think his port 25 block is related (I think).
For any readers, this basic grep is good enough to cull out the positive messages to hunt for bad looking stuff:
grep MDN *.log | grep -Ev "(Successfully sent MDN|Sending MDNs|is an MDN)"
On my end, the data is clear (a random error once every few weeks). But on his end, yeah we have a problem Houston - hundreds of log lines like this:
2026-05-22-08-04-29.log:2026-05-27T00:30:24.299Z core/event WARNING "" 1 "src/mimeparser.rs:2417: Ignoring MDN sent to self, this is a bug on the sender device."
2026-05-22-08-04-29.log:2026-05-27T00:30:24.300Z core/event WARNING "" 1 "src/mimeparser.rs:2417: Ignoring MDN sent to self, this is a bug on the sender device."
2026-05-22-08-04-29.log:2026-05-27T00:30:24.321Z core/event WARNING "" 1 "src/mimeparser.rs:2417: Ignoring MDN sent to self, this is a bug on the sender device."
The logs on his end are from the macOS Deltachat Desktop client. That surely doesn’t look good… other than those (90% of the log) we see 2 other random errors:
INFO "" 1 "src/mimeparser.rs:2457: Ignoring MDN, found no message with Message-ID
This is back in March, and I had a few of these “back then” too. Ignoring, not important but this one other that only rarely shows up:
INFO "" 1 "src/smtp.rs:482: Ratelimiter does not allow sending MDNs now."
…but that was last logged a month ago. It’s the first set of log lines about sending MDN to self, they’re repeated by the hundreds in his logs.
Gotcha thanks, sent him a link to the Apple store with the latest version. He only installed the desktop somewhat recently this year, do macOS things like this not upgrade automatically? I would have thought it would have automatically upgraded if installed from the App store… but I’m a Linux nerd. I’ll talk to him about it, see if he can see some things on his side why it wasn’t upgraded. Appreciated for the head’s up.
Happy to report that’s all it was - his macOS was stuck on 2.35 and not auto-updating (system is configured correctly to do it, he sent screenshots - no clue). Smashing the AppStore button manually upgraded, and a day full of chats yesterday was all roses - double checkmarks everywhere. Thanks for your help.
(the sporadic behaviour can be explained because his Android is running the latest F-Droid release, so it was working correctly while the older desktop app was misbehaving)