Delivery receipts, and the art of getting a straight answer out of a mail server
Someone asked why delivery receipts were not arriving. Simple question. The answer took a week.
The code said they worked. The checkbox was bound, the flag reached the server, the right parameters went out on the wire, and the SMTP logs confirmed every step of it. Google was asked directly whether it supports delivery notifications and said no, which explained nothing, because the notification was supposed to come from the sending server anyway. Thunderbird was doing much the same thing and getting answers. We were doing much the same thing and getting silence. RFC 3461 was consulted at length and was, as ever, technically helpful.
What nobody was looking at was a checkbox on the domain configuration: Use php mail(). mail() cannot pass the SMTP parameters a receipt needs, so on every domain with it ticked the request was thrown away without a word. @lvarnava spotted it by comparing the domain where receipts worked against the ones where they did not, which is more than the code, the logs, the RFC and Google managed between them.
The tick box in the compose window had been doing nothing whatsoever on those domains, and nothing anywhere said so. It does now, directly under the setting responsible.
Receipts also forgot about delays
Chasing that turned up a second, genuine problem. We asked servers to notify on success and on failure, but never on delay. Plenty of servers refuse to send success notifications at all, since spammers abuse them, while honouring delay perfectly happily. So a message that got queued or retried reported nothing back to you. Thunderbird has asked for all three for years, which is why it looked more reliable against identical servers.
Receipts now also carry an envelope id, so one that turns up two days later can be matched to the message that caused it.
The placeholder that was never there
&:placeholder has one colon. It needs two. A selector with one colon matches nothing at all, so the rule meant to colour login placeholder text had never applied, on any theme, in any release.
Fixing the colon alone would have put white text on the four themes with light login boxes, so it now takes the colour each theme already defines for that box. Xv, Linen and Squares then turned out to have a second problem underneath: a light wallpaper behind a half-transparent black box composites to mid grey, and their own labels were sitting at 3.86:1. Below readable. Nobody had mentioned it.
Also
PDF attachments have their preview back. The check asked a browser API deprecated in 2021 that now answers only while the built-in PDF viewer is enabled, so the ground moved rather than the code. Messages per page has a limit that limits, instead of the larger of two numbers quietly winning. Seven dead files from the RainLoop and SnappyMail days have left the repository root.
The security policy deserves its own line. It named 3.x as the supported version and asked for encrypted email while giving neither an address nor a key, so there was in practice no way to report a vulnerability privately at all. Private reporting is switched on now and the policy points at it.
Thank you
@lvarnava worked out what was really going on, and produced Thunderbird logs for comparison when asked, which is the only reason the delay problem was found at all. Also a large part of the Russian translation, with @BrainDeLook.
And Weblate, which now gets its credit in the README where it belongs, next to a chart of how each language is doing. If yours is looking thin, that link is how you fix it.