Rooms and Equipment

Rooms and Equipment

Written on 26 September 2026 from hmailserver/docs/RoomsAndEquipment.md in 6.3.4 (27 September 2026, schema 6104). Everything on this page is new in 6.3.4 (schema 6101), and nothing changes until an account is given a kind other than person. Brought up on 5 October 2026 to 6.3.6 (6 October 2026, schema 6108), for what 6.3.6 changes on this page. 6.3.7, the latest release (17 October 2026, schema 6108), is not yet reflected here.

A meeting room, or a projector, has a mailbox the way it has in Exchange: it is invited to a meeting like any guest, and it answers by itself - it accepts an invitation for a time it is free, inside its booking window, from somebody who may book it, and declines one that is not, saying why. Nobody reads its mail to decide. What it does not decide it leaves to its delegates.

flowchart TD
    I["An invitation (iMIP REQUEST)<br/>naming the room as a guest"] --> Q["Delivered to the room's mailbox,<br/>and queued for a decision"]
    Q --> W{"Is the ORGANIZER who sent it?<br/>from what the server recorded,<br/>never from a header"}
    W -->|"no"| DL["Left for the delegates,<br/>who are told by mail"]
    W -->|"yes"| B{"May they book it?"}
    B -->|"no"| DEC["Declined, with the reason"]
    B -->|"yes"| A{"Automatic answers on,<br/>not sent automatically,<br/>within the hour's answers?"}
    A -->|"no"| DL
    A -->|"yes"| P{"Recurring allowed? Inside the window?<br/>Not too long? In working hours?<br/>Free at that time?"}
    P -->|"no"| DEC
    P -->|"yes"| ACC["Accepted: filed in the room's calendar,<br/>REPLY from the room's address"]

Loading

Contents

• A room is an account
• The booking policy
• Who is asking
• The answer
• The delegates
• Where people find a room
• What Exchange does that this does not

A room is an account

A room or a piece of equipment is an account whose kind says so: person (every account there was, and the default), room or equipment. So everything that works on an account works on a room: its address and aliases, its quota, its calendar and the calendar's sharing, its place in the organisation's directory, the backup, a mailbox move.

Where	What
The Control Deck	The account editor's General group has a select of the three kinds, and a room or a piece of equipment gets a Booking policy card
REST	kind on GET and PUT /api/v1/accounts/{address}; the policy at GET and PUT /api/v1/accounts/{address}/booking-policy (view_accounts to read, manage_accounts to write)
COM	Account.Kind (0 person, 1 room, 2 equipment), saved by Save(). The booking policy is not on COM
The Control Panel	Neither: a room made on the Deck or over REST is an ordinary account to it

It cannot be signed into. From the moment its kind is saved every sign-in as it is refused, whatever the credential - IMAP, POP3, SMTP AUTH, ManageSieve, CalDAV, CardDAV, the webmail and REST, an OAuth2 token, a Kerberos ticket, a client certificate, a passkey or single sign-on - with the ordinary wrong-password answer. Setting the kind back to person lets it sign in again with the password it has.

Give a room a quota and a message retention that suit it: every request it receives stays in its mailbox, answered or not, and once the mailbox is full nothing more is delivered, so nothing more is answered. The account's MessageRetentionDays empties it of what is older (Profiles and Environment).

The booking policy

One row per room, made on the first save; a room with none answers by the defaults.

Field	Default	What it decides
auto_accept	true	Answer invitations by this policy. false leaves every one for the delegates
window_days	180	How many days ahead a booking may start, 1 to 1080
max_duration_minutes	1440	The longest booking; 0 is no limit
working_hours_only	false	Only inside the working hours, on the working days
work_days, work_start, work_end	Monday to Friday, 08:00 to 17:00	The working days and hours
time_zone	UTC	The zone the working hours are in, such as Europe/London
allow_conflicts	false	Accept a booking over another one
allow_recurring	true	Accept a recurring meeting
bookers	empty	Who may book: empty is everyone in this server's own domains; a list is its entries alone - an address, @domain, a distribution list's address, a group's name. An organiser from outside must be named here
capacity	0	How many people a room seats, shown in the directory; it decides nothing
delegates	none	Who answers for it: accounts' addresses and group names, each given a delegate share of the room's calendar

Every change of the policy is on the audit trail, and the policy is in the backup. The delegate shares are the calendar's and, like every calendar share, are not in the backup: name the delegates again after a restore.

Who is asking

Before anything else the room decides whether the invitation's ORGANIZER is who sent it - from what the server recorded when the message arrived, never from a From: header or a MAIL FROM, which a sender can write as they like:

• An organiser at this server's own domains is believed only when the message was submitted by a signed-in session as that account, or as an account allowed to send as it. A message sent through the send API is no organiser's, whatever address its key may send as - true since 6.3.6, and not of 6.3.4 and 6.3.5, which believed one sent with a key allowed to send as the organiser.
• An organiser from outside is believed only when the policy's bookers name that address or its @domain and the message passed DMARC for exactly the domain of a From: that is the organiser's address, written as that one mailbox (6.3.6; 6.3.4 and 6.3.5 took a DMARC pass for the domain whichever sender at it had written the message). SPF on its own is not enough. With DMARC off, no outside organiser is ever believed.
• Anything else is not the organiser: its request is not filed or answered, its update changes no booking and its cancellation frees nothing. The message stays in the room's mailbox, and the delegates are told - within limits per organiser and per room, so that forged requests cannot flood them.

The answer

The decision is made just after delivery, on a work queue of the rooms' own, one request at a time per room; no delivery and no SMTP answer waits for it. In order: who is asking; may they book; was it sent automatically (an empty reverse path or Auto-Submitted, never answered - RFC 3834); does the policy answer automatically; at most 20 answers an hour to one organiser; a recurring meeting when the policy takes none; the window; the longest booking; working hours; and conflicts, counting every booking the room holds that is not cancelled as busy.

• Accepted: filed into the room's calendar, and a METHOD:REPLY sent to the organiser from the room's address, through this server's own queue, marked Auto-Submitted: auto-replied.
• Declined: not filed, and a reply giving the reason alone - "Board Room can be booked at most 30 days ahead, and this meeting is on ...", "Board Room is already booked at that time: ...". A conflict says when, never whose, and a decline quotes nothing of the request.
• A cancellation from the booking's organiser frees the slot; of one occurrence, that occurrence alone. An update is decided again from the start. A change to one occurrence, as Google and Apple send a moved meeting, is decided as that occurrence alone.

Two servers sharing one database are not serialised for rooms, and could each accept a request for the same slot: run rooms on one node.

The delegates

A request is left for the delegates when the policy answers nothing automatically, when it was sent automatically, when the organiser has had the hour's answers, when it changes several occurrences at once, or when no decision could be reached (the calendar could not be read, the times cannot be placed). Such a request is never put into the room's calendar on the sender's word: it stays in the room's mailbox, and each delegate is told by mail from the room - who asked, for when, and why it was not answered automatically.

A delegate sees the room's calendar in their own calendars - in the webmail and over CalDAV - and can write to it. They book a request they approve themselves, in the room's calendar, and tell the organiser; they answer a booking the room holds with Accept, Maybe or Decline on the room's behalf - in the webmail, over REST or from a CalDAV client - and the answer goes to the organiser the room believed and to nobody else. A room with no delegates keeps what it leaves and tells nobody - name at least one.

Where people find a room

• The directory: a room is listed with its kind and capacity in the webmail's Directory page and GET /api/v1/me/directory, and its card in the read-only CardDAV directory says KIND:location (KIND:device for equipment) (The Webmail).
• CalDAV's room finder: every principal says its calendar-user-type - INDIVIDUAL, ROOM, or RESOURCE for equipment - and the principal-property-search report on /dav/principals/ answers the domain's rooms and equipment. Apple Calendar searches for locations this way; Thunderbird has no room finder (Connecting a Mail Client).
• Booking is inviting the room's address, from any client.

What Exchange does that this does not

Kept to what a small organisation uses, and left out deliberately:

• Different rules for different people (in policy, out of policy, request only): one list says who may book, and everything else is declined or left for the delegates.
• Tentative acceptance pending a delegate's approval: with automatic answers off, every request goes to the delegates.
• Declining one occurrence of a series and accepting the rest: a series with any conflicting occurrence is declined whole. Truncating a series at the booking window: a series that runs past it is declined.
• A minimum duration, and rewriting the booking (removing the subject or body, adding the organiser's name): the booking is filed as sent, and read only by the delegates.
• Custom resource properties, room lists, buildings and floors: capacity is the one property kept.
• Free-busy of a room on another server, RFC 6638 scheduling, and a room finder in the webmail's own event editor.
• Believing an organiser from a forwarded invitation, a list on another server, or an API key.
• COM properties for the policy, and a Control Panel page.

An address erased as a person's data is taken out of every policy's bookers; a list the erasure leaves empty turns that room's automatic answers off rather than opening it to everyone (Compliance and eDiscovery).

The full document, with every rule, message and test, is RoomsAndEquipment.md.

See also: Aliases Lists and Public Folders · Connecting a Mail Client · The Webmail · The Control Deck · Your First Domain and Mailbox