**Confidential until the fixed release is published.** ## Summary With DKIM signing on for a domain it hosts, the server signs a message as the domain its `From` header names. It did so for **every** message on the message's first delivery pass, wherever the message came from. `SMTPDeliverer::PreprocessMessage_` calls `DKIMSigner::Sign` for every queued message while `GetNoOfRetries() == 0`, before the split between local and external delivery. `DKIMSigner::SignAsAuthorDomain_` takes the signing domain from the `From` header. It signs wherever that domain is hosted with DKIM enabled, or is an alias of such a domain with alias signing on, and the message carries no signature of the domain yet. Nothing asked whether the sender had signed in. So a sender anywhere, with no account, could send the server a message with `From: ceo@hosted.example`. The envelope sender is at a domain of the sender's own, and the message goes to any local address; external-to-local mail is accepted without authentication by default, as it must be. The server signed that message `d=hosted.example` before local delivery, and the signature stayed with every copy made from it: - **Copies made from the signed file:** an account's forward (`SMTPForwarding::PerformForwarding`), a rule's forward or copy, a Sieve `redirect`, and the mirror copy are made with `PersistentMessage::CopyToQueue`. `DKIM::HasSignatureForDomain_` then skipped re-signing the copy, so it left the server carrying the signature. - **Aliases and distribution lists:** they expand at `RCPT TO`, so a member outside is a recipient of the accepted message itself, and the signed original was relayed outward. - **Managed lists (from 6.3.4):** a managed list signed every copy as the list's domain, and DMARC aligns that with a `From` in the list domain's organisation. - **Other paths:** a journal rule's copy and the encrypted copy for a partner domain (both from 6.3.4), a message released from the quarantine, and a message downloaded from an external account went the same way. At the receiver, the copy carries a valid DKIM signature aligned with its `From` domain. It therefore passes DKIM and DMARC for the hosted domain, whatever that domain's DMARC policy: a forgery from outside, authenticated with the hosted domain's own key. The behaviour was not the project's invention. Upstream hMailServer's change #512 (commit `4baaae1722`, 17 April 2026, "DKIM-sign all email sent from domain") moved signing from external delivery, where it was keyed on the envelope sender, to this first-pass call keyed on the `From` header. The project's first tag, `v6.0.0`, carries it. Affected: 6.0.0 through 6.3.6 wherever DKIM signing is on for a hosted domain, on Windows and on the Linux builds (from 6.3.0). Found in the project's own security review, 6 October 2026. CVSS 3.1 7.5 (`AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N`). CWE-348. ## Who can reach it, and what they gain **Who.** Anyone who can send mail to the server: an **unauthenticated sender** on the internet. They need no account and no credential, and no user has to act. The message goes to an address at the server whose mail is carried on to an address outside, such as an account that forwards, an alias, a distribution list or a rule that forwards. The holder of the forwarding account, list or rule is not the attacker and need not do anything after setting it up. **What is gained.** - **A DMARC-passing forgery.** The message has any `From` at a hosted domain the server signs for, and any `Subject` and body. It reaches the outside recipients of the forward, alias or list with a valid DKIM signature of that domain, so a conforming receiver passes DKIM and DMARC even under `p=reject`. The receiver credits the message with the domain's reputation, and the signature names the hosted domain as its author: the postmaster, an executive, billing. - **A reusable signature.** A DKIM signature is not tied to its recipient. Whoever holds a signed copy can re-send it to anyone while the domain's key is unchanged (a DKIM replay): a list member, the owner of a forwarding target, or the original sender when a refusal of the forwarded copy returns its header to them. The impact is to the integrity and authenticity of mail the server signs. Nothing is read, and availability is not affected. ## Affected versions and configurations - **Versions: 6.0.0 through 6.3.6.** The two pieces of code are the same in every tag from `v6.0.0` through `v6.3.6` (the `v6.0.0-B1`, `-B3` and `-B4` pre-release tags included): - `SMTPDeliverer::PreprocessMessage_` signs on the first pass (`SMTP/SMTPDeliverer.cpp` lines 212-217 at `v6.0.0`, 616-625 at `v6.3.6`, where the guard also became `!GetFirstPassDone()`). - `DKIMSigner` takes the signing domain from the `From` header (`Common/AntiSpam/DKIM/DKIMSigner.cpp` `Sign` at line 36 at `v6.0.0`, `SignAsAuthorDomain_` lines 147-253 at `v6.3.6`). No tag's `DKIMSigner.cpp` through `v6.3.6` consults where the message came from. - **Where it came from.** The code is upstream hMailServer's: change #512 (`4baaae1722`, Martin Knafve, 17 April 2026), with #522 (`a7b5a47fb1`, RvdH, 30 April 2026) adding alias signing. - Before #512, upstream signed in `ExternalDelivery` by the envelope sender's domain. Upstream's 5.6.x releases are therefore not shown to be affected this way. - Every upstream 5.7 build published on GitHub contains #512 and, read at its tag, signs the same way in `PreprocessMessage_` and `DKIMSigner::Sign`, with no origin check: the releases 5.7.0 (tag `hMailServer-5.7.0-b3013`, published 28 September 2026) and 5.7.1 (`hMailServer-5.7.1-b3116`, 29 September 2026), and the prereleases `hMailServer-5.7.0-b2788`, `-b2843` and `hMailServer-5.7.2-b3124`. - **The paths that carry the signed message out, by version:** - every version: an account's forward, a rule's forward or copy, an alias or a distribution list with a member outside, and the mirror address (a message downloaded from an external account is signed on its first pass in the same way, and leaves by these paths); - from 6.2.3: a Sieve `redirect`; - from 6.2.22-pre3: a message released from the quarantine; - from 6.3.4: a managed list's copies (signed as the list's domain, `ListManager::QueueCopy`, line 1464 at `v6.3.4`), a journal rule's copy, and the encrypted copy for a partner domain. - **Platforms.** Windows, and the Linux builds from 6.3.0 (the first Linux packages). - **The configuration that makes it reachable:** - **DKIM signing on for a hosted domain.** It is off for a new domain until the administrator enables it and sets a selector and a private key (`Domain.DKIMSignEnabled`; `DKIMSignAliasesEnabled` extends it to the domain's aliases). The forged `From` must be at such a domain. - **For the forgery to leave the server: an address whose mail is carried to an address outside.** This can be an account's forward, a rule's forward or copy, a Sieve `redirect`, an alias, a distribution list or managed list member, the mirror address or a journal rule. Without one, the signed forgery stays in local mailboxes. - **The default IP ranges.** The `Internet` range takes external-to-local mail without authentication but requires it for local-to-local and local-to-external, so the sender uses an envelope sender of their own; nothing checks the `From` header against it. - **What reduces it.** The server's own DMARC check (`DMARCEnabled`, on by default) scores a message that fails the `From` domain's published DMARC policy of `quarantine` or `reject` with `DMARCFailureScore` (5). That equals the default mark threshold (5) and is far below the default delete threshold (20). - A forgery of a domain that publishes such a policy is therefore marked as spam, but by default it is still delivered, signed and carried on. Only an account's forward set to skip mail marked as spam withholds that one forward; aliases, lists and rules still carry it. - A domain that publishes `p=none`, or no DMARC record, gets no score at all. - **Not affected.** Mail an authenticated user submits at its own domain, or as an address its account may send as, is meant to be signed, and still is; a submission whose `From` names an address at another hosted domain that the account may not send as is under "A signed-in account's submission" below. A message that arrives with a valid signature of its own `From` domain is signed by that domain already. ## Workaround Until the fixed release, any one of these closes or narrows it: - **Refuse the forgery on arrival by DMARC.** This works for a hosted domain the server signs for and whose DMARC policy is `quarantine` or `reject`, which the domain owner can publish. - Keep the server's DMARC check on (`DMARCEnabled`). - Set its failure score (`DMARCFailureScore`) at or above the spam delete threshold (`SpamDeleteThreshold`, 20 by default). A message from outside that fails the domain's DMARC is then refused at the end of `DATA`, before it is queued or signed. - This also enforces every other domain's published `quarantine`/`reject` policy, because the score is server-wide. - It does not cover an IP range without spam protection, or a sender the domain policy list marks white. - With the quarantine on, such a message is held instead of refused. Do not release it: a released message is signed. - **Refuse it in an event script.** An `OnAcceptMessage` handler can set `Result.Value = 2` when `client.Authenticated` is false and the `From` header's domain is one the server signs for. - The handler must exempt the IP ranges that legitimately send as a hosted domain without signing in, such as `127.0.0.1`. - It does not see downloads from external accounts, which do not arrive over SMTP. - It also refuses outside services that legitimately send in a hosted domain's name to local recipients. - **Remove the paths outward:** forwards to outside addresses, rules that forward or copy outward, Sieve `redirect`s, aliases and distribution or managed list members outside, and an outside mirror address or journal recipient. - From 6.3.4, a remote domain policy for `*` with **Mail may be forwarded to this domain** cleared stops accounts' forwards and Sieve `redirect`s, but not rules, aliases, lists or the mirror. It also stops forwards and redirects to the server's own domains, unless a more specific policy for them allows forwarding. - **Turn DKIM signing off for the hosted domains** (`DKIMSignEnabled`). The domain's own outgoing mail then relies on SPF alignment for DMARC. Of these, only this one also covers a signed-in account's submission signed as another hosted domain. - **Rotate the key.** Where forged mail may already have been signed, rotate the domain's DKIM key (`docs/DkimKeyRotation.md`), since a signature already given stays valid until the key changes. ## Fix (6.3.7) On `master` since 9 October 2026 (!14): `fcad66110`, with `a707714c7`, and `4a61303e9` for a signed-in account's submission (below). It ships in 6.3.7. - **The server records where a message came from.** - `Message::GetFromOutside` marks a message from outside. `SMTPConnection::RecordOrigin_` sets it for a session that neither signed in nor was the message's submission server. A session is the submission server when it sends a hosted envelope sender from an IP range that does not require signing in for it, which by default is only `My computer`. - `ExternalFetchClientBase::SaveMessage_` sets it for an external account's download, and `MailImporter` for an imported file. - It is never read from a header. - It is carried by every copy: a forward, a Sieve redirect, a rule's forward or copy, the mirror, a managed list's copy, a journal copy and the partner domain's encrypted copy. - It is kept on the queue row through a restart, as an `outside` token in `messageauthdomains`, with no schema change (`PersistentMessage::OriginColumn`/`ReadOriginColumn`). - **The signer signs as the `From`'s domain only a message it is entitled to.** `DKIMSigner::SignsAsAuthorDomain` allows three kinds: - a signed-in user's submission and every copy of it, as another hosted domain only when the account may send as the address its `From` names (below); - a message the server makes; - a message an IP range lets in as one of the server's own domains without signing in. A message from outside leaves with the signature it came with and, with `ArcSealingEnabled` on, an ARC set the relaying domain seals. - **Managed lists.** A managed list does not sign its copies of a posting from outside as the list's domain when any address of the list domain's organisation is in any of the posting's `From` fields (`ListManager::SignsCopiesAsListDomain`). DMARC would align that signature. - **The quarantine.** - The quarantine records whether a held message came from outside in the stored copy's file name (`<GUID>.outside.eml` or `.inside.eml`), and a release reads it from there. It is not read from the message, whose `Received` field a domain's rule may have rewritten before holding it. - A copy held before the upgrade counts as from outside unless: - it has no `Received` field; - its top `Received` field is this server's own for a session that signed in; - or it came from the send API. - **Known limits:** - Messages already in the queue at the upgrade carry no mark and are signed as before. - A copy held before the upgrade is judged by its header, so one from a range trusted without login is released unsigned. - A non-default IP range that lets a sender use a hosted envelope sender without signing in is trusted as a submitter, by design. - A session that did not sign in and whose envelope sender is not one of the server's domains, the null sender `<>` included, is now marked from outside whatever its IP range, so a hosted-domain `From` it carries is no longer signed. That covers a range trusted to relay external-to-external without login, and a program on the server itself (`My computer`) that sends with an empty or a foreign envelope sender. - Signatures already given stay valid until the key is rotated. - The fix is about signatures alone. A copy of mail from outside could also pass DMARC through an envelope sender, or a host name, aligned with the forged `From`; 6.3.7 fixes that separately, in work items #90 and #91. - **A signed-in account's submission (4a61303e9).** The signer also signed a message submitted over authenticated SMTP as whatever hosted domain its `From` named, in every version that signs: authenticated SMTP does not hold the `From` *header* to the account's addresses (`SmtpAuthenticatedSenderCheck`, off by default, holds only `MAIL FROM`), though the webmail's send and COM's `Message.Save` do hold `From` and `Sender`. An account of one hosted domain could so have mail written as an address at another signed with that domain's key. That matters where `SmtpAuthenticatedSenderCheck` holds signed-in senders to their own envelope addresses: the signature was then the remaining way for such mail to pass the other domain's DMARC policy. 6.3.7 signs such a submission as its own domain as before, and as another hosted domain only when the account may send as that address - its own, an alias pointing at it, a mailbox that granted it the post right, an address it proved, a masked address of its own (`DKIMSigner::SubmitterMaySignAs`). Otherwise the message is accepted and sent unsigned as that domain, and so is every copy of it: `SMTPConnection::RecordOrigin_` marks it as it marks mail from outside. `SigningOriginTester` and `AntiSpam/DKIM/ArcSealing.cs` cover it. `docs/SendAs.md` gains a section on which messages the server signs as a domain, and `docs/MailingLists.md` and `docs/DkimKeyRotation.md` say it where they speak of signing. The fix is covered by `SigningOriginTester` (`ClassTester` on Windows, `business-object-tests` on Linux; its mutants fail as they should). The regression fixtures ran against the service, and passed, in the pipeline that landed the fix on `master` (pipeline 2928270199, !14, 9 October 2026), its Windows gate among its jobs: - `AntiSpam/DKIM/ArcSealing.cs`: a signed-in submission signed; an account's forward, an account rule's forward and a Sieve `redirect` of outside mail not signed but sealed; a distribution list signing only a signed-in member's posting. - `AntiSpam/Quarantine.cs`: a released message from outside not signed. An upgrade stops further signing of forgeries; it cannot recall what was signed before, and only a key rotation ends the old signatures' validity.