How it works

xListman runs mailing lists: a place where a group of people discuss something by email, and every message is kept, threaded, and searchable. This page explains the model in plain language. If you already know Mailman’s model, most of this will look familiar.

The pieces

A domain. An xListman instance hosts one or more virtual domains — the part after the @. An instance can host example.com and lists.example.org at the same time.

A list. A mailing list lives at an address like dev@example.com. It’s the conversation: who’s on it, what gets posted, how posts are handled, and the archive of everything that’s been said. A list is either a discussion (two-way) or a newsletter (one-way), and the owner picks which.

A subscriber. An email address that xListman knows about. Being a subscriber doesn’t mean being on any particular list — it’s the identity. People sign up with their address, no passwords anywhere.

A subscription. The relationship between a subscriber and a list: posts are delivered to that address while the subscription is active.

The four subscription states

Every subscription is in one of four states, and each one matters for what happens:

Pending — the person requested a subscription and is waiting to confirm their address (the first half of double opt-in).
Active — confirmed; posts are delivered. Only active subscriptions receive posts.
Held — confirmed, but the list owner hasn’t approved yet. This only happens on lists with a moderated subscription policy.
Disabled — delivery stopped because too many emails to that address bounced. The subscription isn’t deleted — it can be re-enabled, which starts the bounce count over.

Double opt-in

Signing up works by double opt-in: a person requests to subscribe, xListman emails a confirmation link to that address, and only when the person confirms is anything added. That way no one can subscribe someone else’s address without their action. On an open list, confirmation is the whole process; on a moderated list, the owner then approves.

Posting and moderation

Posting is by email. There’s no web composer — you write to the list address, and the message goes out. (Email is the point: the list is a conversation that lives in your mail client.)

What happens to a post depends on the list type:

On a discussion list, subscribers’ posts go out immediately. A moderator can be switched on, in which case every post is held for approval first.
On a newsletter list, only the owners and people on the list’s allowlist can post; everyone else is rejected.

A held post sits in the moderation queue until an owner or moderator approves, rejects, or discards it. Held messages expire after a set number of days — by default two weeks — and are then quietly removed.

Digests and delivery

Members choose how they receive posts: regular (each post as it arrives), digest (a batched daily or weekly compilation), or nomail (paused — still subscribed, no delivery). Digests are sent when the period elapses, only if there are new messages.

Bounces and health

When a message to a subscriber bounces, xListman notices — it encodes the recipient in the return-path envelope, so it knows exactly which subscription failed. Enough bounces (the list’s threshold, five by default) disables that subscription automatically rather than burning delivery effort forever. The owner can re-enable it, or the member can from their self-service page.

Who does what

Three roles exist on a list: owners (full control — settings, membership, moderation), moderators (approve or reject held posts, nothing else), and designated senders (allowed to post to a newsletter). One step above the list roles, an administrator runs the whole instance: creating domains and lists and managing other administrators.

Everything a privileged person does is recorded in an audit trail — kept forever, never edited or deleted.

Next: Install, or if you’re deciding whether it fits, the narrative is on the front page.