Aliases, distribution lists, membership queries, mailing lists and public folders

Written for 6.3.4. hMailServer 6.3.7 (17 October 2026) signs an authenticated submission as another hosted domain only when the 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; otherwise the mail is sent unsigned as that domain, so give such an account the alias or the grant before upgrading. Mail from outside whose From names a hosted domain is no longer signed as it, nor is an alias's or a distribution list's copy of it to an outside address; where such a message did not pass DMARC for the organisation its From names when it arrived, a copy whose envelope sender is at this server's host name, or at a hosted domain or a subdomain of one, in that organisation is not sent where an alias or a distribution list expands to an outside address, a managed list does not distribute a posting whose From names the list domain's organisation, and a distribution list's bounce address is not given to it; a managed list's copies of a posting from outside are not signed as the list's domain when an address of the list domain's organisation is in its From fields. Creating a domain alias is now the server administrator's: a credential confined to named domains is refused it, over REST and over COM. See the 6.3.7 announcement.

There are three ways of making one address reach somewhere other than a mailbox of the same name - an alias, a distribution list and a route - and one way of giving several people the same folder. This topic covers all of them as they are in 6.3.4 (27 September 2026, schema 6104): aliases, domain aliases and plus addressing; distribution lists, who may post to them and how moderation works; the membership query, which lets a list define its own members; the list manager, which turns a distribution list into a mailing list people join and leave themselves; and public folders with their permissions. The membership query and the list manager are new in 6.3.4; the distribution list itself is in every release. The one thing to know first: the address is resolved in one function (RecipientParser::CheckDeliveryPossibility), in a fixed order, and an account always wins.

The order an address is resolved in

At RCPT TO the server works through this, and stops at the first answer:

1. Domain aliases rewrite the domain.
2. Plus addressing trims the local part.
3. Account? If found, deliver to the mailbox.
4. Alias? If found, follow it and start over, up to 25 hops.
5. Distribution list? If found, expand to the members, or to the moderator.
6. Route? If found, send to the route's target server.
7. The domain's postmaster address, the catch-all: when nothing above matched, the resolution starts again with that address, which is why a mistyped address is delivered there rather than refused. If it is empty, 550 Unknown user.

Since 6.3.4 one question is asked before all of these: is the address, or its domain, routed to a webhook? A webhook route that only posts takes the address's mail instead of its mailbox, alias or list - a list whose address is routed never sees the message, nor applies its posting rules to it. Route the addresses you mean rather than a list's whole domain; mail in to a webhook has the routes themselves.

Aliases

An alias is a second address that delivers to an existing target. In the Control Panel: Accounts & domains → Domains, select the domain, then the Aliases panel.

The Control Panel and COM are Windows-only. On Linux, where there is neither, the Control Deck is the administration people click through, and it is the front end of the REST API, which both platforms have:

What	REST route
A domain's aliases	GET and POST /api/v1/domains/{domain}/aliases; DELETE /api/v1/aliases/{address}
A domain's other names	GET and POST /api/v1/domains/{domain}/domain-aliases; DELETE on .../{name} beneath it
A domain's lists	GET and POST /api/v1/domains/{domain}/lists; PUT and DELETE /api/v1/lists/{address}
A domain's plus addressing	PUT /api/v1/domains/{domain} (plus_addressing_enabled, plus_addressing_character)

The Control Panel paths and COM properties below are for Windows.

Field	COM property	Meaning
Alias address	Alias.Name	The address people send to. Must be in this domain
Target	Alias.Value	May be anything: another account here, another alias, a distribution list, an address covered by a route, or an address at a different server
Active	Alias.Active	Unticked: RCPT TO is answered 550 Alias is not active. - not passed on to the catch-all

• The target replaces the address and resolution starts again, so an alias may point at an alias, which may point at a list. Beyond 25 hops the answer is 550 Mail server configuration error. Too many recursive forwards.
• An alias is only consulted when no account has that address. Creating sales@ as an account after sales@ exists as an alias silently changes where the mail goes.
• An alias to an external address is treated as inbound mail, not as relaying, so [email protected] → [email protected] works for external senders without opening a relay.

Since 6.3.4 three more kinds of second address exist, and they are the person's own rather than the administrator's: the alias a mailbox move leaves (renaming or moving a mailbox keeps the old address as an alias of the new one by default); masked addresses (schema 6067), which the person makes in the webmail for one shop or sign-up and which, switched off, are refused as an address that never existed; and verified send-as (schema 6066), which receives nothing here - it is a From address, not an alias.

Domain aliases. Accounts & domains → Domains → Properties → Names. The rewrite is total: [email protected] becomes [email protected] before anything else is looked at. You do not create per-address aliases for an alias domain; the sender address is rewritten too, which is what lets a list in membership mode recognise a member who posts from the alias domain; and the alias domain needs its own MX record. Since 6.3.7 adding one is the server administrator's: a credential confined to named domains - such as a domain administrator, or an API key issued for its domains - is refused, over REST and over COM, because a domain alias decides what names the server accepts mail for.

Plus addressing is off by default and enabled per domain on Accounts & domains → Domains → Properties → Limits (default character +). With it on, [email protected] resolves to [email protected], and the full original address is still in the To: header. It applies to the recipient address only, after domain aliases and before the account, alias and list lookups. When off, alice+invoices@ is an unknown address.

Distribution lists

A distribution list delivers one message to many recipients. In the Control Panel: the Distribution lists panel of the domain, then Properties and Members.

Mode	Stored value	Who may post	Refusal
Public - anyone can send	0	Anyone at all	-
Membership - only list members can send	1	Any address on the member list, after domain aliases are applied to both sides	550 Not authorized sender.
Announcements only	2	Only the address in Require sender address	550 Not authorized owner.
Anyone in the domain can send	3	Any sender whose domain is the list's own	550 Not authorized domain.
(on any mode) Require SMTP authentication	flag	An unauthenticated session is refused first	550 SMTP authentication required.

"Anyone in the domain" is a claim, not a proof. MAIL FROM is free text, so an outsider can assert a local address. Tick Require SMTP authentication with that mode or the list is open to the Internet. A fifth mode, 4, "Anyone with a server account can send", existed only in the type library and behaved as Public; put_Mode now refuses the value and the option is gone from the dialog.

One more check runs for every mode, Public included: the poster must be allowed to reach every recipient of the list, so a list containing a members-only list the poster is not in is refused as a whole.

Moderation. Set a Moderator address and a posting the rules above would refuse is accepted with 250 and forwarded to the moderator instead, stamped X-hMailServer-Moderation. The moderator approves it by resending it to the list from an authenticated session; that authentication is the security boundary and is unconditional. Three failures are numbered in the log: 6360 (the moderator was removed between the check and the expansion), 6361 (the moderator address does not resolve; the recipient is refused with 550) and 6363 (the list is its own moderator).

Bounce address. Empty means bounces go to the poster. Set, it becomes the envelope sender of every copy, so a dead subscriber's bounce reaches the list owner, and an external member's server evaluates SPF against the list's own domain. A bounce address pointing at the list itself is ignored, with error 6362.

Headers. An unmanaged list adds List-Id, List-Post (the literal NO for an announcements-only list), List-Help, List-Owner and a mailto:-only List-Unsubscribe, before DKIM signing. Nothing is added when the message already carries a List-Id, or when the list or owner address is not US-ASCII.

A list that defines itself: the membership query, since 6.3.4

Schema 6074. A list can carry a membership query: one short text that says who its members are, answered against the server's accounts at the moment a message is sent to it. [email protected] with the query domain reaches every active account of the domain on the day, including the person who joined this morning and not the one switched off last night.

Query	Members
(empty)	A static list: the addresses under Recipients and nothing else
domain	Every active account of the list's own domain
domain:other.example	Every active account of that domain, which this server has to host
pattern:sales-*@example.com	Every active account whose address matches the wildcard; * is any run, ? exactly one, case ignored
everyone	Every active account of every active domain on the server

• It is a union with the list's own recipients, never a replacement. An address that is both is delivered to once.
• It answers accounts only - not aliases, other lists or outside addresses - and never a disabled account or an account of a disabled domain.
• It is resolved once per SMTP transaction, not once per RCPT TO, and nothing is stored.
• Who may set which form. A domain administrator, or an API key with a domain scope, may set domain or a pattern: in a domain it holds. everyone, domain: naming another tenant's domain, and a pattern whose domain part is itself a wildcard are the server administrator's. The same rule governs reading the answer: GET /api/v1/lists/{address}/members answers 403 to a confined credential when the query reaches past its domains.
• A query is judged when it is saved. domain: naming a domain this server does not host, a pattern: with no @, or any text that is none of the five forms is refused, by the same sentence over COM, over REST and in the Control Panel.
• "Answers nobody" and "could not be answered" are different. A query whose named domain has been deleted is not an error at delivery: the message goes to the list's rows and code 6980 is logged. But when the accounts cannot be read - the database locked by a backup - the recipient is refused 451 4.3.2 and the sender retries, with code 6982, and the members route answers 503.

It is set as Membership query in the Control Panel's list dialog and the Control Deck, membership over REST, DistributionList.Membership over COM, and hmctl list update [email protected] --set membership=domain. The Deck's list editor shows Delivers to now, each address marked Kept by hand or From the query.

The list manager: a mailing list, since 6.3.4

Schema 6092. A distribution list with the list manager switched on is one people join and leave themselves. Nothing changes for a list until it is switched on: every list an upgrade finds is unmanaged.

1. On the list: Managed in the Control Panel's list dialog, managed in the Deck's list editor and on PUT /api/v1/lists/{address}, or DistributionList.Managed over COM.
2. The links. The confirmation page, each member's page, the owner's approval page, the subscribe form and the archive are served by the REST listener, which is off until RestApiPort is set (turning the REST API on). Make it reachable over HTTPS, then set list_base_url (ListBaseUrl), such as https://lists.example.com. Empty, the default, offers no link at all. Only an https:// base gives RFC 8058's one-click.
3. DKIM on the list's domain. The copies are signed as that domain after the list's fields are in place, so the signature covers List-Unsubscribe and List-Unsubscribe-Post. With DKIM off for the domain the copies go unsigned and the providers do not offer the one-click.

Address	What it does
[email protected]	Post to the list
[email protected]	Ask to join, and confirm by replying
[email protected]	Ask to leave: the member is sent a link and a token, and nothing more happens until they follow it
[email protected]	The help text
[email protected]	The person who runs the list
[email protected]	Delivery reports; with VERP, [email protected]

None of them is an account; an account, an alias or a list of exactly one of those names is the administrator's and wins over the manager.

Joining. subscribe_policy is 0 closed (the default: the administrator adds members), 1 confirm (the address asked for is sent a confirmation with a token) or 2 moderated (after the address confirms, the owner approves on a page, signed in to the webmail as the owner's own account, or on the Deck; a reply by mail approves nothing). The list answers at most twenty requests an hour from one requester and two hundred an hour in all.

Delivery. Each member chooses each message, one digest a day, or none. With digest on, one digest goes at digest_hour (7 by default, the server's local time), at most 100 messages and 10 MB. With archive at 1 (members) or 2 (public), every distributed message is kept and shown by month, as text only, never as HTML. The rows of hm_listarchive are not in the backup.

What a member's copy carries, over an https:// base with the archive on:

List-Id: <team.example.com>
List-Post: <mailto:[email protected]>              (NO for an announcement list)
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <mailto:[email protected]?subject=subscribe>, <https://lists.example.com/lists/[email protected]/subscribe>
List-Unsubscribe: <mailto:[email protected]?subject=unsubscribe>, <https://lists.example.com/lists/unsubscribe?t=...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Owner: <mailto:[email protected]>
List-Archive: <https://lists.example.com/lists/[email protected]/archive>
Precedence: list
X-Loop: [email protected]
X-hMailServer-List-Member: <a tag, see Bounces>

Bounces. A 5.x.x is a hard bounce, a 4.x.x a soft one; a delayed warning counts for nothing. Anybody can write to the bounce address, so a report is believed only when it carries the member's tag, X-hMailServer-List-Member.

Setting	REST key	Default
ListHardBouncesToUnsubscribe	list_hard_bounces_to_unsubscribe	1
ListSoftBouncesToUnsubscribe	list_soft_bounces_to_unsubscribe	5
ListBounceWindowDays	list_bounce_window_days	30

A member who reaches either count is set to none - paused, never unsubscribed - and the owner is told once.

Public folders

Accounts & domains → Public folders, in the Control Panel on Windows, creates shared IMAP folders; public folders have no REST route yet, so Linux has no administrator's page for them. On either platform a client holding the a right manages a folder's permissions over IMAP. Public folders live in their own namespace, #Public, and sub-folders are made by typing the whole path with the hierarchy delimiter, . by default: #Public.Team.Archive. #[email protected] is a different namespace: one account's own folders, shared.

Each permission entry grants RFC 4314 rights to an account, a group or Anyone (every authenticated account).

Right	Letter	What it allows
Lookup	l	The folder appears in LIST/LSUB. Without it the folder does not exist as far as that user is concerned
Read messages	r	SELECT and STATUS
Keep seen/unseen state	s	Set or clear \Seen
Set flags	w	Flags other than \Seen and \Deleted
Insert	i	APPEND and COPY into the folder
Post	p	Send mail to the folder's submission address
Create sub-folders	k	CREATE beneath it
Delete folder	x	DELETE
Delete messages	t	Set or clear \Deleted
Expunge	e	EXPUNGE
Administer	a	SETACL, DELETEACL, GETACL, LISTRIGHTS

• An owner has every right implicitly. For anyone else the server walks up from the folder to the nearest ancestor that has any ACL rows, then uses the row for the account, else for a group the account is in, else for Anyone.
• The nearest ancestor with any rows wins, and rows are not merged. Adding one permission to a sub-folder removes everyone else's access to it.
• \Seen is shared in a shared folder, not per user. Grant lrs and delegates share one read/unread state; grant lr and they leave no trace.
• Turning ACL enforcement off opens public folders only. It does not extend to #Users, which stops existing entirely.

What it does not do

• The list manager does not rewrite From for DMARC. A posting from a domain that publishes p=reject reaches outside members with a From that fails DMARC when the list changed the message, and Gmail and Yahoo may refuse it.
• No posting from the web, no list password, no approval by reply, no NNTP, no IMAP access to an archive, no weekly digest, and one owner address per list.
• A membership query has no directory-attribute form and no group: form, and no query can name another list's query.
• The list manager's fixture is not linked into the Linux test suite: MailingLists.md says its thirty-four tests are of the Windows suite.

Where to read more

• Wiki: Aliases, Lists and Public Folders, Mailing Lists, Mail In to a Webhook
• Documents at the 6.3.4 tag: DistributionLists.md, MailingLists.md
• The public documentation: chapter 13
• On this forum: Being trusted by the servers you send to for DKIM and DMARC, the 6.3.4 release announcement, the webmail in depth for masked addresses and send-as, and IMAP on the server for shared mailboxes