---
title: "IMAP and POP3 on the server: capabilities, switches, shared mailboxes, search limits"
url: https://www.hmailserver.co.uk/topic/28224/imap-and-pop3-on-the-server-capabilities-switches-shared-mailboxes-search-limits
author: "Progressiverobot"
published: 2026-09-27T19:06:13.731Z
updated: 2026-09-27T19:06:13.731Z
category: "General support"
tags: ["imap","smtp","administration","rest-api"]
site: hMailServer Community Forum
---

# IMAP and POP3 on the server: capabilities, switches, shared mailboxes, search limits

*Written for 6.3.4. hMailServer 6.3.7 (17 October 2026) changes some of what a client gets. IMAP `COPY` and `MOVE` by message number read their set in the client's numbering, and a set that names a message another session has just expunged is refused `NO [EXPUNGEISSUED]` for the client to send again; a `COPY` or `MOVE` that fails part way leaves the destination as it was; `SEARCH`, `SORT` and `THREAD` ask a criterion named again beside itself once; and `FETCH BODY[N.MIME]`, and `BODY[N]` of a multipart, are the stored octets. POP3 accepts the `UTF8` classic Outlook for Windows (2016 to 2024) sends after the login, until the session's first `STAT`, `LIST`, `UIDL`, `RETR`, `TOP`, `DELE` or `RSET`, so its downloads work again. SMTP, POP3 and ManageSieve refuse a SASL PLAIN sign-in that asks to act as another account. The IMAP and POP3 listeners can take the client's address from a PROXY protocol header, as the SMTP listener does, each from the peers on a list of its own, both off by default. The send-as grant now bears on DKIM too: an authenticated submission is signed as another hosted domain only when its account may send as the address its From names - its own, an alias pointing at it, a mailbox that granted it the post right, an address it proved, or a masked address of its own - and is otherwise accepted and sent unsigned as that domain. See [the 6.3.7 announcement](/topic/28277). hMailServer 6.3.8 (2 November 2026) signs a name in to an account only when it is the account's stored address, compared in lower case after a domain alias and the default domain, on IMAP, POP3 and SMTP alike, SCRAM-SHA-256 among them: a client that signs in with another spelling of the address, in more than the case of the letters A to Z, or with white space at either end, may no longer sign in, since such a name fails as a name that does not exist fails and is counted as a failure. Correct the name in the client. See [the 6.3.8 announcement](/topic/28278).*

This topic is the server side of IMAP, POP3 and SMTP in hMailServer 6.3.4: what each listener advertises and which switch gates it, search limits and the full-text index, QRESYNC's expunge history, connection limits, shared mailboxes, and what 6.3.4 fixed that a client may notice. **Know this first: a capability missing from an answer is nearly always a switch or the session's state, not a fault.** Two IMAP switches ship off, and since 6.3.4 IMAP offers `STARTTLS` only before TLS and sign-in, and `COMPRESS=DEFLATE` only after sign-in. What a mail client needs is in [Connecting a mail client](/topic/28255); the ACL rights table is in [Aliases, distribution lists, mailing lists and public folders](/topic/28270).

### Seeing what the server advertises

Ask the server, from any machine with OpenSSL. For SMTP type `EHLO test.example.org`; for IMAP, `CAPABILITY`:

```
openssl s_client -connect mail.yourcompany.com:25 -starttls smtp -quiet
openssl s_client -connect mail.yourcompany.com:993 -quiet
```

On 6.3.4 ask IMAP before `LOGIN` and after: the answers differ by design. For POP3, connect to 995 the same way and send `CAPA`. Ports 993 and 995 exist only once you have created them (**Connections & protocols → TCP/IP ports** in the Windows Control Panel, or the Control Deck).

### IMAP: what is always there

On every connection, as in 6.3.3:

```
IMAP4 IMAP4rev1 IMAP4rev2 CHILDREN THREAD=ORDEREDSUBJECT THREAD=REFERENCES
NAMESPACE RIGHTS=texk MOVE ID SPECIAL-USE CREATE-SPECIAL-USE UNSELECT UIDPLUS ENABLE
STATUS=SIZE ESEARCH CONDSTORE QRESYNC LIST-EXTENDED SEARCHRES WITHIN UTF8=ACCEPT
LIST-STATUS PREVIEW MULTIAPPEND REPLACE SAVEDATE METADATA OBJECTID BINARY LITERAL- APPENDLIMIT
```

`APPENDLIMIT` is bare before authentication and `APPENDLIMIT=<bytes>` after. `LITERAL-` caps non-synchronising literals at 4096 bytes, so an oversized `APPEND` can still be refused with `TOOBIG`.

**A client opts in to IMAP4rev2 per session** with `ENABLE IMAP4rev2`, which implies `UTF8=ACCEPT`. `ENABLE` recognises exactly four names: `QRESYNC` (implies `CONDSTORE`), `CONDSTORE`, `UTF8=ACCEPT` and `IMAP4rev2`. After `ENABLE IMAP4rev2` the session drops the `RECENT` response and the `[UNSEEN]` code on `SELECT` and `EXAMINE`, drops `RECENT` as a `STATUS` item, and answers a `SEARCH` with no `RETURN` options as `ESEARCH`.

### IMAP: what is gated, and by what

| Capability | Advertised when | Shipped |
|---|---|---|
| `IDLE` | `enableimapidle` is on | On |
| `QUOTA QUOTA=RES-STORAGE` | `enableimapquota` is on | On |
| `SORT` | `enableimapsort` is on | On |
| `ACL` | `enableimapacl` is on; it also switches the `#Users` namespace | On |
| `AUTH=PLAIN`, `AUTH=SCRAM-SHA-256` | `EnableImapSASLPlain` is on and authentication is available | **Off** |
| `SASL-IR` | `EnableImapSASLInitialResponse` is on | **Off** |
| `COMPRESS=DEFLATE` | `IMAPCompressionEnabled=1`, the client has signed in (since 6.3.4), and the session is not yet compressed | On |
| `STARTTLS` | The port is STARTTLS-optional or -required, TLS is not active, and (since 6.3.4) the client has not signed in | Per port |
| `LOGINDISABLED` | Authentication is refused on this cleartext connection (STARTTLS-required port, or `RequireTLSForAuth` on the IP range) | Per range |

The rest depend on the connection: `AUTH=SCRAM-SHA-256-PLUS` only on TLS (and behind the same SASL switch), `AUTH=XOAUTH2 AUTH=OAUTHBEARER` with `OAuth2Enabled` and, unless `OAuth2RequireTLS=0`, only over TLS, `AUTH=EXTERNAL` on a verified client certificate that names an address, and `UNAUTHENTICATE` once signed in.

- **`IDLE`** reports changes in the selected folder (`EXISTS`, `RECENT`, `EXPUNGE`, `FLAGS`) as they happen. A folder another client has just created is seen at the next folder-list refresh, as there is no IMAP `NOTIFY`; that is IMAP, not a fault.
- **`QUOTA`** answers with one unnamed root, `""`, and a `STORAGE` resource in kilobytes from the account's maximum size; an account with no limit gets an empty list. `SETQUOTA` is refused, because the quota is the administrator's. Refusals of `APPEND`, `COPY` and `MOVE` for a full mailbox carry `OVERQUOTA`.
- **`SORT`**: with message indexing off, as it ships, `SORT` reads each message's header from disk.
- **`EnableImapSASLPlain`** gates SCRAM as well as PLAIN, despite its name. [Roadmap.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/Roadmap.md) says it gates the whole `AUTHENTICATE` command, while the Capabilities wiki gives OAuth2 and `EXTERNAL` conditions of their own: with it off, test `XOAUTH2`, `OAUTHBEARER` and `EXTERNAL` over IMAP before relying on them.

**`COMPRESS DEFLATE`** (RFC 4978) compresses both directions of the rest of the session; a client that does not ask is unaffected. A second one is `NO [COMPRESSIONACTIVE]`, `STARTTLS` under compression is `BAD`, and `IMAPCompressionEnabled=0` withdraws it, the command then answering `BAD` like an unknown one.

### POP3 and SMTP: the same question

**POP3 `CAPA`** always carries `UIDL`, `TOP`, `RESP-CODES`, `AUTH-RESP-CODE`, `IMPLEMENTATION hMailServer`, `PIPELINING`, `UTF8` and `EXPIRE NEVER`. The `SASL` mechanisms depend on TLS, `STLS` on the port, and `LOGIN-DELAY <n>` appears only when `Pop3LoginDelaySeconds` is above 0 (0 ships). That key advertises and enforces a minimum interval between sign-ins, refusing an early one with `-ERR [LOGIN-DELAY] …`; on Windows it is the POP3 tab's card *How often a client may check for mail*.

**SMTP `EHLO`** always carries `SIZE <n>` (the maximum message size in KB times 1024; bare `SIZE` when 0), `8BITMIME`, `PIPELINING`, `CHUNKING`, `BINARYMIME`, `SMTPUTF8`, `ENHANCEDSTATUSCODES`, `DSN` and `HELP`. `BINARYMIME` is for local delivery: a recipient needing onward relay is refused at `RCPT TO` with 554 5.6.3. Conditionally:

- `XCLIENT` only when `SMTPXClientEnabled=1` and the real peer is in `SMTPXClientTrustedIPs`; an untrusted peer that tries it gets 550.
- `STARTTLS` on a cleartext connection to a STARTTLS-optional or -required port.
- `AUTH` only when authentication is enabled, withheld on cleartext when the port requires STARTTLS or the range sets `RequireTLSForAuth`, and never on the ports in `DisableAUTHList`.
- Not a keyword, but decided the same way: the HAProxy PROXY protocol is accepted only with `SMTPProxyProtocolEnabled=1` and from a peer in `SMTPProxyProtocolTrustedIPs`, and nothing in `EHLO` announces it.

On SMTP and POP3 the `AUTH` line and its SASL responses take up to 12,288 octets; every other line keeps 510 (SMTP) or 500 (POP3). What 6.3.4 added to SMTP is refusals, not capabilities.

### Where the switches are set, and when a change applies

| What | Windows Control Panel | Elsewhere | Applies |
|---|---|---|---|
| `IDLE`, `QUOTA`, `SORT`, `ACL`, the two SASL switches, the connection limits | **Connections & protocols → Protocols**, IMAP, SMTP and POP3 tabs | COM `Settings` (`IMAPIdleEnabled` and its neighbours); REST `PUT /api/v1/settings` (`imap_idle_enabled`, `imap_quota_enabled`, `imap_sort_enabled`, `imap_acl_enabled`, `imap_sasl_plain_enabled`, `imap_sasl_initial_response_enabled`); the Deck's Settings view; `hmctl settings set` | At once |
| Message indexing | **Maintenance → Performance**, Indexing tab | COM `Settings.MessageIndexing`; `PUT /api/v1/settings/indexing` (`enabled`); `hmctl settings`, group `indexing` | At once |
| `IMAPCompressionEnabled`, `IMAPSearchTimeout`, `IMAPSearchMaxMegabytes`, `IMAPExpungeRetentionRecords`, `Pop3LoginDelaySeconds`, `IndexerFullText` and its tuning keys | Cards on the IMAP and POP3 tabs; the Indexing tab | COM `Settings.SetIniSetting`; `PUT /api/v1/settings/ini/{name}` (administrator password only); `hmctl ini`; on Linux `hmailserver --set-setting NAME=VALUE`. No Deck page | When saved |

The Control Panel and COM are Windows-only. The last row's keys were the `[Settings]` section of `hMailServer.ini`; **since 6.3.4 the database holds them**, none of them waits for a reinitialise or a restart ([docs/SettingsApply.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/hmailserver/docs/SettingsApply.md)), and the server does not take a line edited in the file, so set them through an interface. [Settings: when a save takes effect](/topic/28222) covers the store, `HM5804`, and a value stored by `--set-setting` while the service runs.

The REST lines assume the listener on `127.0.0.1:8443`, as the REST API wiki's examples do; `RestApiPort` ships at 0 (off) and waits for a reinitialise.

```bash
# Switch IDLE off; in effect when the answer comes back
curl -u Administrator:your-admin-password -X PUT -H "Content-Type: application/json" \
     -d '{"imap_idle_enabled":false}' http://127.0.0.1:8443/api/v1/settings

# A [Settings] key: the administrator password only, never an API key
curl -u Administrator:your-admin-password -X PUT -H "Content-Type: application/json" \
     -d '{"value":"120"}' http://127.0.0.1:8443/api/v1/settings/ini/IMAPSearchTimeout

# On Linux, then a restart so the running server takes it
sudo hmailserver --set-setting IMAPSearchTimeout=120
sudo systemctl restart hmailserver
```

### Search: two ceilings and the full-text index

**Without the full-text index, `SEARCH BODY` and `TEXT` read every message in the mailbox**, attachments whose media type is text included (decoded, bounded at 1 MB). Two ceilings, measured from the moment a command starts and never re-armed by progress, bound `SEARCH`, `SORT` and `THREAD`: `IMAPSearchTimeout` (60 seconds) and `IMAPSearchMaxMegabytes` (2048 MB of message content read); 0 turns either off. They are the IMAP tab's card *IMAP search limits*, and [README.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/hmailserver/docs/README.md) says to raise them for mailboxes of several hundred thousand messages.

**What a client gets at a ceiling is stated two ways.** [Roadmap.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/Roadmap.md) records `NO` with RFC 9051 `LIMIT` and no untagged result, so a cut-short list cannot pass for a complete one; [README.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/hmailserver/docs/README.md)'s comment beside `IMAPSearchTimeout` says the search returns the matches found so far. Until that is settled, treat a search that hit a ceiling as incomplete, and let nothing act on its result in bulk.

**The full-text index is off, and needs two switches**: `IndexerFullText=1` indexes nothing unless message indexing (`Settings.MessageIndexing`) is on too. It costs a term table of a few kilobytes per message and a backfill pass over every message already delivered, which is why no upgrade turns it on. **The index can only prove that a message cannot match**; everything else is read and scanned as before, so results are identical on or off. The webmail's search and eDiscovery use the same filter.

| Key | Default | What it does |
|---|---|---|
| `IndexerFullTextBatchSize` | 250 (1 to 100000) | Messages one backfill pass reads before the cursor is saved and the thread pauses |
| `IndexerFullTextMinTokenLength` | 3 (3 to 64) | The shortest search string the index answers for |
| `IndexerFullTextMaxTokensPerMessage` | 2048 (64 to 1000000) | Distinct terms before a message is marked always-scanned instead of indexed |

The Indexing tab's *Index now, and show how far behind it is* and *Discard the index and rebuild it* are `POST /api/v1/settings/indexing/index` and `/clear` over REST, and `Index()` and `Clear()` over COM, where `TotalIndexedCount` against `TotalMessageCount` shows a rebuild's progress. With mailboxes encrypted at rest, the indexed count stays short by their messages for good: those are never indexed.

### QRESYNC: how much expunge history is kept

`IMAPExpungeRetentionRecords` keeps the newest 5000 expunge records per mailbox (0 keeps all), pruned every twelve hours and once at service start; on Windows it is the card *Change history for synchronising clients*. The newest is never removed. **A client whose last sync is older than what is kept gets a full resync, never a wrong one**: every UID in its range that the mailbox does not hold. An installation upgraded from a release older than 6.2.23-alpha1 prunes the table in one pass at its first start. [README.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/hmailserver/docs/README.md) says 0 defers that prune, and an `IMAPExpungeRetentionRecords` line of 0 added to `[Settings]` before the upgrade is taken: 6.3.4's first start adopts from the file a key the database has never held, and before 6.2.23-alpha1 the database held this one only if the file had the line. Restart the old service once after adding or changing it (Upgrading hMailServer wiki, 18.3, step 6): [CHANGELOG.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/CHANGELOG.md)'s note that a line edited to prepare an upgrade is put back concerns a key the database already holds, and that restart settles it. Set it back to 5000 afterwards through an interface; [Upgrading to 6.3.4](/topic/28193) has the rest of the order.

### Connection limits and what guards them

`MaxSMTPConnections`, `MaxIMAPConnections` and `MaxPOP3Connections` are on the Protocols page (REST `max_smtp_connections`, `max_imap_connections`, `max_pop3_connections`). None has a limit by default; SMTP and IMAP ship at 0, no cap. The Services tab turns a protocol off altogether (`ServiceSMTP`, `ServiceIMAP`, `ServicePOP3`).

Watch `hmailserver_sessions{protocol}` on `/metrics` (off until `MetricsServerPort` is set, which waits for a reinitialise) or `sessions` in `GET /api/v1/status`. Around the limits: auto-ban counts failed sign-ins per IP across SMTP, IMAP, POP3, ManageSieve and REST (on: 3 in 30 minutes, a 60-minute ban); `LogonTarpitSeconds` (off) delays each failed sign-in's refusal; a second POP3 session on one mailbox gets `-ERR [IN-USE]`; and since 6.3.4 an IMAP `LIST` or `LSUB` pattern over 8,192 characters, or more than 32 patterns in one `LIST`, is answered `BAD`. The submission rate limit and the tarpits are in [IP ranges, auto-ban, lockout and tarpits](/topic/28239); refusing a connection by country is in [allow and block lists and country blocking](/topic/28249).

### Opening a mailbox to a colleague

Shared and delegated mailboxes are IMAP ACL (RFC 4314). The owner opens a folder to another account, and it appears to that account under the Other Users namespace as `#Users.owner@domain.folder`. **No administrator step is needed**: any account whose client speaks `SETACL` can do it, and the audit trail records no row for it.

1. Leave ACL on. With it off, `#Users` stops existing (`NAMESPACE` advertises `NIL`), public folders are open to everyone, and the send-as grant is not honoured.
2. The owner grants rights from an IMAP client with ACL support. An administrator can do it over REST: `GET` on `/api/v1/accounts/{address}/folders` gives the folder's id, and `/api/v1/accounts/{address}/folders/{id}/permissions` lists, adds, changes and removes entries (since 6.3.3; writes need a full key). On Windows, COM has `IMAPFolderPermissions.Add`. The grantee is an account, a group (`/api/v1/groups`, since 6.3.4), or Anyone, which is every authenticated account on the server.
3. Grant `l`, or the folder does not exist for the colleague. `r` reads, `s` changes read state, `i`, `t` and `e` file and delete, and `p` on the INBOX is the send-as grant.
4. Grant on each top-level folder needed. A right is decided at the nearest folder up the owner's tree that has any entries, and entries are not merged: a grant on INBOX reaches its sub-folders that have none of their own, not the Sent folder, and one entry on a sub-folder cuts it off from the parent's.
5. Over SMTP the `p` grant counts only while `SmtpAuthenticatedSenderCheck` is on, and it ships off: until then nothing constrains an authenticated `MAIL FROM`, so any account can send as the mailbox, or as anyone else. Turned on, it applies to every authenticated session on the server; the addresses it then allows are in [who may send as whom](/topic/28239).
6. In the colleague's client, a pane of subscribed folders shows only the ones the owner subscribed to; the webmail shows them under `Shared by <owner>`.

**What follows from sharing:**

- `\Seen` is stored on the message, not per person: with `s`, a delegate marks a message read for everyone; with `lr` alone they leave no trace, and their client cannot track what they have read.
- Since 6.3.4 an `APPEND` into a `#Users` folder is charged to the owner's quota, as `COPY` and `MOVE` already were.
- A delegate reads a folder of a mailbox encrypted at rest only while the owner's key is open; otherwise a `FETCH` that reads the message answers `NO [UNAVAILABLE]`, and copying out is refused.
- In the webmail a read-only share refuses a flag or a delete with 403, a message cannot move between one's own mailbox and a shared one, and the owner cannot grant access from the page.
- Since 6.3.4 a restore puts each folder's access grants back. Every `LIST` runs one more query while ACL is on.

### What 6.3.4 fixed that a client may notice

Where Dovecot's `imaptest` found IMAP answering other than the RFCs say (`\Seen` without `.PEEK`, `APPEND` byte for byte, `SORT` and `THREAD` order, among others), [Connecting a mail client](/topic/28255) has the list. The rest:

| What a client did | What it gets since 6.3.4 |
|---|---|
| Sent `STARTTLS` after `LOGIN`, or inside TLS | `BAD`, and no `STARTTLS` in `CAPABILITY` |
| Sent `COMPRESS DEFLATE` before signing in | `NO` |
| Appended over a compressed connection, data inflating past the 250,000-octet receive buffer | The whole message, where it was stored cut short or never finished |
| Read `ENVELOPE` with a backslash in `Date`, or `BODYSTRUCTURE` with a quote or backslash in a part's parameters | A structure that parses: the date's backslashes left out; quotes and backslashes escaped, a control character sent as a space |
| Fetched a message the server cannot read | `NO [UNAVAILABLE]` for a closed key; a damaged one (`HM7350`) left out, the rest fetched and the command ending `NO` - not `OK` with an empty `ENVELOPE` |
| Changed one message's flags from two sessions at once | Both changes kept; `STORE ... (UNCHANGEDSINCE n)` tested in the same step |
| Went on sending a `MULTIAPPEND`'s later literals after a refusal, one over the maximum message size (and 1 MB) | The connection closed with `BAD [TOOBIG]`, where it was read whatever its size |
| Fetched a message only an unreachable object store holds | IMAP `NO [UNAVAILABLE]`, POP3 `-ERR [SYS/TEMP]` (object storage is new in 6.3.4, and off) |

Two heap-corruption aborts are gone as well (two sessions on one message's keywords; `LIST` beside folder changes). Most of these were in 6.3.3 too.

### What it does not do

- **No APOP or CRAM-MD5** on POP3, and `THREADID` is answered `NIL`.
- **Delegation is not measured in Thunderbird or Outlook**, and an Outlook IMAP profile never acts on the Autodiscover answer's delegated mailboxes; the `#Users` namespace is what works.

### Where to read more

- Wiki: [Capabilities and Configuration](https://gitlab.com/hmailserver/hmailserver/-/wikis/Capabilities-and-Configuration), [Settings Reference](https://gitlab.com/hmailserver/hmailserver/-/wikis/Settings-Reference) (9.12), [Connecting a Mail Client](https://gitlab.com/hmailserver/hmailserver/-/wikis/Connecting-a-Mail-Client), [Aliases, Lists and Public Folders](https://gitlab.com/hmailserver/hmailserver/-/wikis/Aliases-Lists-and-Public-Folders) (13.3), [Control Panel Reference](https://gitlab.com/hmailserver/hmailserver/-/wikis/Control-Panel-Reference) (7.5), [Security Hardening](https://gitlab.com/hmailserver/hmailserver/-/wikis/Security-Hardening) (17.5, 17.7), [Changes Since 6.2.10](https://gitlab.com/hmailserver/hmailserver/-/wikis/Changes-Since-6210) (4.3, 4.4).
- At the 6.3.4 tag: [SettingsApply.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/hmailserver/docs/SettingsApply.md), [SendAs.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/hmailserver/docs/SendAs.md), [EncryptionAtRest.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/hmailserver/docs/EncryptionAtRest.md), [DeckParity.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/hmailserver/docs/DeckParity.md), [README.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/README.md), [CHANGELOG.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/CHANGELOG.md) (6.3.4, *IMAP, POP3 and the webmail*), [Roadmap.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/Roadmap.md).
- The public documentation: [34.3 IMAP details worth knowing](https://www.progressiverobot.com/hmailserver-documentation/#343-imap-details-worth-knowing), [30.3 IMAP folders and permissions](https://www.progressiverobot.com/hmailserver-documentation/#303-imap-folders-and-permissions).
- On this forum: [Upgrading to 6.3.4](/topic/28193), [The Control Deck](/topic/28192), [The REST API: turning it on](/topic/28264), [Message storage: object storage and encryption at rest](/topic/28233), [What runs out first: pools, connections, large folders](/topic/28238) and [Monitoring and health](/topic/28272).
- A client that does not get on with these answers is a bug: a GitLab issue or, without a GitLab account, an email to contact-project+hmailserver-hmailserver-86730559-issue-@incoming.gitlab.com, filed as a confidential issue ([SUPPORT.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/SUPPORT.md)). A vulnerability goes only by [SECURITY.md](https://gitlab.com/hmailserver/hmailserver/-/blob/v6.3.4/SECURITY.md)'s routes.