The DNS regression (#25)
6.2.16 rewrote name resolution onto the asynchronous DnsQueryEx so that a lookup could be bounded and cancelled instead of holding a pooled thread. In doing so it gave the custom-DNS-server entry a destination port of 53.
A DNS_ADDR carries a full SOCKADDR, so setting the port looks like the obviously correct thing to do. It is not. The DNS client supplies the port itself; with port 53 every query returns status 87 and no records, and with port 0 it works. The classic DnsQuery this replaced took a PIP4_ARRAY — a bare list of addresses with no port field at all — which is why the mistake was easy to make and impossible to see.
The effect was not limited to the feature that reported it. Every lookup that went through a configured custom DNS server failed — MX records for outbound delivery, DNSBL, SPF, SURBL — for as long as one was configured. It announced itself loudest through SpamAssassin, as HM5507 The IP address for SpamAssassin could not be resolved, which is how #25 was reported. Installations with no custom DNS server were never affected: the server list is only built when one is set.
Fixed, with the reasoning written into the source so it is not "corrected" back, and pinned by a regression test built as a negative control: it points DNSServer at TEST-NET-1 (192.0.2.1), which answers nothing, and requires the lookup to TIME OUT. A timeout is the proof that a packet actually left the machine - the broken build returned status 87 in the same millisecond, without sending anything - and the test fails naming that status if it ever comes back.
The directory as an account source
Until now an account could be linked to Active Directory but nothing could create one from it. Settings.PreviewDirectorySync and Settings.ApplyDirectorySync now read an LDAP directory and, on request, create and update the mailboxes it says should exist. There is a Control Panel page for it, and an optional unattended schedule.
The preview is the point. Planning and applying are one piece of code — the planner decides and writes nothing, the applier writes and decides nothing — so a preview cannot describe an action the apply would not take. The Apply button stays disabled until a preview of the same options has been run, and is re-checked after the confirmation dialog.
What it refuses to do is as important as what it does:
- A domain takes part only if its Active Directory domain name is set. That makes provisioning opt-in per domain, so a search base pointed one level too high cannot provision into unrelated hosted domains. It also guarantees every created account carries a non-empty AD domain — which matters, because LogonUser with an empty domain validates against the local machine's own Windows accounts.
- Nothing is ever deleted. The most it does is clear Active, and only when asked. Not on a truncated enumeration, not on an empty one, and not for a domain in which nothing was seen — in each of those an account that still exists is indistinguishable from one that was removed.
- An account that is not directory-linked, or is linked to a different AD domain, is reported rather than taken over. Either would move who decides that mailbox's password.
The enumeration pages, because Active Directory caps a search at MaxPageSize and answers a larger directory with the first page and a success status. The service bind honours BindMethod, so Negotiate works where no LDAPS certificate exists — the unjoined-DMZ case the feature exists for. A multi-valued attribute is reduced deterministically, because LDAP guarantees no ordering and taking whichever value arrived first let a re-run pick a different address for the same person.
Verified end to end against a live Windows Server 2025 domain controller.
Sieve imap4flags now reaches the message
setflag, addflag, removeflag and the :flags tag were parsed, accepted by require, evaluated — and then discarded at delivery. A script that marked its own automated mail \Seen was accepted, ran, reported success, and changed nothing.
The flags are now applied to the stored message, and imap4flags has moved into the ManageSieve capability line. Only the five system flags can be stored (\Seen \Answered \Flagged \Deleted \Draft); a keyword is reported in the application log rather than dropped in silence.
Also fixed
- GetUniqueMessageID could hand out the same UID twice, which makes a client show one message in place of another.
- A colon in an account address was accepted and could never work: the local part becomes a directory name in the message store, and Windows cannot create a directory containing one. Such an account saved, appeared in every list, accepted mail at RCPT TO, and failed when the message was filed.
- A session could outlive its io_context, and shutdown waited in the wrong place.
- A status card could announce failing backups on a healthy server, because an interval read from the INI was doubled as an integer and could overflow negative.
- A certificate handle leaked on every visit to the certificates page whenever a key file threw.
Administration
The settings that had no interface now have one, and the pages that showed what was configured now also show what is happening — including where a configuration looks enabled and is inert. The [Settings] INI values move into the database so they can be administered remotely, with the file still winning where both carry a value, so nothing changes for an installation that edits the INI by hand.
Upgrading
The database schema moves from 6005 to 6011. DBUpdater applies it; take a backup first, as always. Settings are preserved.
Known issues
#26 — partial FETCH BODY[]<offset.length> reported against 6.2.18 — does not reproduce here, and this release adds tests that walk a whole message in chunks over both FETCH and UID FETCH and compare the reassembly byte for byte, including the short final chunk. That is not the same as saying the reporter is wrong: the report is against a build this release is well ahead of, so "already fixed" and "never broken here" cannot be told apart without more detail. An IMAP protocol log showing the exact command sequence would settle it.
Validated by the full regression suite against this binary.
