Skip to content

History / APIs Reference

Revisions

  • The wiki catches up with the tree after 6.3.3, and one thing the code says that no page said. Section 4e of the changes page is what is on master and in no release at all - checked line by line against the code at 916dec6a1 rather than against the commit messages, which is how three of the draft's claims came to be corrected: the Control Deck speaks twenty languages and the webmail twenty-three, so it is twenty of the webmail's languages rather than "the same twenty"; the server settings page has twenty-nine tabs, not thirty-one; and the Control Panel redesign added thirteen texts to each of the seventeen catalogues, not twenty-six. Everything else in it was verified where it could be: the 592 zone names counted out of the built-in table in ICalendar.cpp, the 501 texts counted in a Deck catalogue and the 631 in a webmail one, the eighteen dialogs counted as the classes deriving from FluentDialogWindow, the two calendar tables read out of Upgrade6040to6041, the schema step read out of DBUpdater's registration and REQUIRED_DB_VERSION, and the four new routes read out of the router rather than out of the OpenAPI prose. The gate numbers are the one thing left blank: the full Windows suite was still running on this exact tree, so the section carries a marked placeholder and section 1's master row says so, because a number invented here is a number somebody quotes. Schema 6041 is in section 2 as a row of its own, marked as in the tree and in no release, and the two places that said "6040" now say what is where. The Control Panel pages describe the program as it is now. The redesign of 15 September is in the tree and unreleased, and every paragraph about it says so, because a reader on 6.3.3 opens a window with the old chrome: the command bar with its search, status pill, theme toggle and administrator menu, the sidebar that collapses to a rail below a thousand pixels, the ten scaffold components, and eighteen dialogs sized to their content rather than to a pixel width typed into a constructor. What did not move is what a reader has learned - the navigation map, the page titles, the tab headers, the setting captions, the automation ids - and the pages say that too, which is why Control Panel Pages was not rewritten around it. Three counts were behind and are corrected from the code: 393 settings in the Ctrl+K index rather than 389, 343 captions with an Alt key rather than 340, and 3,403 texts in each catalogue rather than 3,376. Two of the four settings that moved the index shipped in 6.3.2 and the reference had missed them, so the per-page table's auto-ban and web-services rows are re-counted as well. The settings pages carry the rule adopted on 15 September: a new setting goes in the database, in hm_settings with a Control Panel editor, and no new key is added to hMailServer.ini's [Settings] section. Both pages say the part that matters more than the rule - that nothing already there has moved. The 238 keys are still read from the file, in 6.3.3 and in the tree, and the Settings Reference is still their reference; the migration that flips which store is the truth is a roadmap row, not an event. The file keeps the directories, the database connection and the administrator password and second factor, and anything that genuinely has to be readable before the database opens is an argued-for exception. The API reference gains what the server publishes and the page did not. Comparing the route table with the OpenAPI document the server emits found seventy-four paths of a hundred and forty-five unnamed, so the administration families are now all there: the six anti-spam collections and the blocked attachments as resources, an account's application passwords, folders, folder permissions and message object, all of which shipped in 6.3.3 and were nowhere on the wiki - and then the four that are in the tree and unreleased, groups with their members, the message copy, the rule-criterion probe and the calendar expansion, each with the body it takes and what it answers. The roughly forty /api/v1/me routes the webmail uses are still families rather than rows, and the page now says so in its own words and points at the OpenAPI document as the authority rather than leaving a reader to think the table is complete. Stopping Spam was left alone deliberately. The brief said SPF was being replaced this week; at this commit it is not. The evaluator is still the original one with the ten-term limit and the void-lookup cap, nothing under AntiSpam or SMTP/SPF has changed since v6.3.3, and the page describes it correctly - so the honest edit was none. The finding is on Backup and Restore, and it is the reason this pass was worth running against the code. The built-in backup's XML index is built by each business object's XMLStore. An account's record carries its password, its TOTP secret, its fetch accounts, its application passwords, its rules and its folders. Nothing anywhere writes hm_contacts, hm_accountprefs, hm_scheduled, hm_files, hm_smimekeys, hm_calendars or hm_calendarobjects - no XMLStore reads them - and Message::XMLStore writes Flags but not messagekeywords. So the address book, every webmail preference a user chose, their labels, their second and third stars, their follow-up flags, their scheduled and snoozed mail, their file links, their S/MIME keys and (in the tree) their calendars are in no archive this server writes. Worse than absent: every one of those tables cascades from hm_accounts, and a restore calls Domains::DeleteAll before it puts the backup's domains back, so a restore deletes them. The page now says it, in the short version and in a section of its own, with what to do instead - back the database up with the database server's own tool, and restore from that when recovering a whole server. No page said any of this before. Monitoring and Health was re-checked rather than rewritten: not one metric family, bucket bound, probe condition, reason string or default has moved since it was verified at 6.2.28, and the only change to MetricsServer.cpp is the Linux accept-loop stop. It gains a section on reading the server from a shell - hmctl status, log list, log tail and backup, with the routes behind them - marked as in the tree and unreleased, since a reader on 6.3.3 has neither client. Smaller corrections found while checking: the capabilities page's web-services entry predated CardDAV entirely and now carries both DAV protocols, their paths, their HTTPS-only rule and what CalDAV does not do; the installing page has a paragraph on winget and Chocolatey that says plainly they do not work yet, because a first submission is reviewed by a person; What hMailServer Is and Is Not still called 6.3.3 unreleased and said the webmail speaks twenty languages; the Control Panel reference still called 6.3.0 the current release; and the fuzzing page's "iCalendar reached through attachment handling" is now also reached by an authenticated CalDAV PUT, which is a shorter path to a parser that expands attacker-chosen numbers - the COUNT=100000000 defect fixed by hand this week is the argument for the target.

    @chrisholloway5 chrisholloway5 committed Sep 15, 2026
  • The API reference after the Linux suite waves (PR #251, merged 14 September 2026): thirteen route rows for the families the waves added - the directories and the ini section of the settings, the logon-failure list, domain aliases, a domain read whole and renamed, an IP range updated in place, the server messages, Sieve evaluation, fetch accounts, scripting and the backup settings - and the status row gains the build object (script_engine, argon2id, post_quantum_key_exchange), each labelled unreleased until 6.3.3.

    @chrisholloway5 chrisholloway5 committed Sep 14, 2026
  • 6.3.0 is published, so the pages that were waiting for it say so: Linux is released rather than "in the tree", the write surface has a release number, and the version that never existed is gone The Linux page opened with a banner saying the port was in the tree and not yet released, and that the first release to carry packages would be "the next one". That release is 6.3.0 and it went out on 10 September 2026, so the banner now points at it and the install commands name the packages that are actually on the release page rather than a version number nobody can download. Five places named 6.2.29. There is no such version and there never will be - the release after 6.2.28 is 6.3.0, and README.md already says why - so the two package filenames, the two "since 6.2.29" notes about relative directory values and the Installation paths diagnostic's label all move to 6.3.0. The API reference's route tables gained the write surface a day before the release but nothing in them said which release it belonged to, while the rows around them carried 6.2.27 and 6.2.28. A reader could reasonably have read the settings, rules and certificate routes as shipping in 6.2.27, which is half true and the misleading half: those routes could only be read then. Section 4 now says which routes arrived in 6.3.0 and why the method column is the one to read, and the scope note names the units the write surface was split into. The landing page's At a glance table was stale in five of its rows: the release and its build number, the platform (Windows only, when the whole point of 6.3 is that it is not), the administration surfaces, the suite's size and the wiki's own page count. The route count was stale in a way worth recording: it said 65, which matched neither the number of rows in the reference table nor the number of distinct paths at the commit it was written from, so it is now 82 routes over 68 paths, both countable from the page it points at. The Control Panel reference said "the latest, v6.2.28", and one thing under ControlPanel did move in 6.3.0: the sign-in box's user name is a literal again (#156), which is why a fresh installation in Chinese could not sign in. The page says so, with the twenty-one files that differ between the tags. The footer stamped 6.2.28 on all fifty-one pages.

    @chrisholloway5 chrisholloway5 committed Sep 10, 2026
  • The Control Deck writes: the API Reference's page section says what the ten views do, how the page signs in for a session instead of keeping the administrator password, and why a 401 no longer opens the browser's own credential box over it The REST page's session section is named for both browser sessions now, the portal's and the Deck's.

    @chrisholloway5 chrisholloway5 committed Sep 9, 2026
  • The REST API writes: the route tables on the REST and API Reference pages carry the settings groups, the rules, the routes, the aliases, the account update, the certificates and listeners and the restart in place, with what each refuses and who may call it The Installing on Linux page's suite row and the Regression Test Environment page's "On Linux" section say what the write surface changed for the Linux run: 278 of 319 pass where 233 did, and what still skips is a COM-only call or the suite's fake DNS zone rather than a route that does not exist.

    @chrisholloway5 chrisholloway5 committed Sep 9, 2026
  • The wiki rewritten in depth: 141 diagrams drawn from the code, every reference page made exhaustive, and twenty-one defaults corrected that no page had ever stated The wiki was accurate after this morning's sweep and thin. This is the depth pass the owner asked for: every page read against the code again, every reference page completed, and a diagram wherever a diagram says it better than a paragraph. 141 Mermaid diagrams across 49 pages, each drawn from the handler rather than from memory: the SMTP submission sequence with the checks in the order ProtocolMAIL_ and ProtocolRCPT_ actually run them, the IMAP session state machine from the per-command authentication guards, the DMARC evaluation, the delivery pipeline and its retry arithmetic, the ACME renewal state machine, the spam decision from connection to delivery, the schema chain, the component and threading models of the whole server, the CI workflows and what each one gates, the release draft-sign-publish flow, and a map of the journeys through the wiki itself on the landing page. The reference pages are now exhaustive rather than representative: every route with its method, authentication, request and response shape and its error codes; every [Settings] key with its default, its effect and whether it needs a restart; every port with the key that opens it; every rule criterion and action; every Sieve extension the server advertises; every metric the listener exposes. Twenty-one facts were wrong or absent, and each is corrected against the code rather than adjusted. The ones that will save somebody an afternoon: IMAP SASL PLAIN and SCRAM are not advertised on a default install, which looks exactly like a client bug; SMTP AUTH PLAIN is off by default too; DMARC checking is on while SPF and DKIM as scored tests are off, and the DMARC test evaluates both itself regardless; the seeded DNSBL and SURBL servers are inactive; a new mailbox contains INBOX and nothing else, which is the real cause of the classic missing Sent folder; MTA-STS hosting and autoconfiguration default on while both web-service ports default to 0, so the shipped default is features on with nothing listening; and TLS-RPT and DMARC report sending are inert until their From address is set, with each completed day discarded unsent. Eleven screenshots are named as wanted, with what each should show. The existing images are from a 6.2.10-era build and the pages say so where it matters.

    @chrisholloway5 chrisholloway5 committed Sep 8, 2026
  • Every page read against the tree on 8 September 2026: the release and schema stamps (6.2.27, schema 6031, 2,124 tests), the routes, keys and pages that were missing, the listener paragraphs that were false, and the unreleased work labelled as such An audit of all 51 pages against master produced about 360 findings on 43 of them, applied here. The largest: the APIs reference lacked 47 routes and described the listeners as single-threaded HTTP/1.0 (they run on the Boost.Asio HTTP/1.1 server); the settings reference lacked the fourteen Update* keys and IMAPCompressionEnabled and counted 195 keys instead of 236; every "current release" stamp said 6.2.24; Changes Since 6.2.10 ended three releases and one schema step early; Architecture said the optional listeners were deliberately not Boost.Asio and built their own SSL contexts (neither is true); the upgrading pages still warned of a silent-upgrade hang fixed in 6.2.23; the Control Panel pages knew nothing of the seventeen languages, the Updates card or the stalled-mail page; and two pages did not render (a header inside a code block, CR and TAB bytes in file names). Anything in the tree but not in v6.2.27 - the live update, the self-service portal and /api/v1/me, the HttpServer listeners, IMAP COMPRESS=DEFLATE, the seventeen-language Control Panel, the Control Deck views - is documented and marked "in the tree after 6.2.27, not yet released". The Control Panel screenshots are still from a 6.2.10 build and the pages now say so.

    @chrisholloway5 chrisholloway5 committed Sep 8, 2026
  • Regenerated from the fact files after the merges of 6 September (IMAP external accounts, the ACME fix, the code-scanning findings)

    @chrisholloway5 chrisholloway5 committed Sep 6, 2026
  • Settings, API and Control Panel reference: metric history (schema 6028), Alt-key mnemonics, the envelope Sieve extension

    @chrisholloway5 chrisholloway5 committed Sep 5, 2026
  • The hMailServer 6.2.24 wiki: the corrected manual, the runbooks, and the references generated from the code

    @chrisholloway5 chrisholloway5 committed Sep 4, 2026