When enabled, the CalDAV module allows Cyrus to function as a calendar and
scheduling server. This module uses a subset of the mailbox hierarchy as
calendar collections, the toplevel of which is specified by the
option. The public calendar hierarchy will reside at the toplevel of the shared
mailbox namespace. A user’s personal calendar hierarchy will be a child of
For example, using the default value for calendarprefix, a
calendar named Default for user “murch” would reside in the mailbox named
Note that mailboxes in the calendar hierarchies (those under calendarprefix) should not be accessed with an IMAP client as doing so will leave a mailbox in a state unsuitable for CalDAV. To this end, calendar mailboxes will not returned by Cyrus imapd in response to an IMAP client’s request for the available calendar list, but Cyrus imapd can not otherwise prevent an IMAP client from accessing them.
By default, the CalDAV module will automatically perform scheduling operations
when a scheduling object (invite or reply) is stored on or deleted from the
server. Support for the calendar-auto-schedule feature can be disabled with the
The CalDAV module will automatically create the required calendars for a user the first time that the user authenticates to the CalDAV server. Note that the user MUST have an existing IMAP Inbox in order for the calendars to be created.
Autocreate of the various calendars can be disabled with the “caldav_create_default/sched/attach” options, if you have an alternate mechanism to create calendars.
There is also a Cyrus web GUI for managing calendar resources. It allows you to:
- Create new collections, with whichever components are required
- Alter existing collections with different components
- Subscribe or download existing collections via prepared URLs
- Set visibility attributes such as Public or Transparent
- Delete existing collections
The Cyrus web GUI for CalDAV Collection Management is disabled by default, but can be enabled with the “caldav_allowcalendaradmin” option.
To access the Cyrus web GUI for CalDAV Collection Management, point
a web browser at
Calendar access controls¶
The CalDAV module uses the same access controls as the other Cyrus services. The cyradm(8) tool can be used to adjust ACLs on calendars as needed. The tables below show how the access controls are used by the CalDAV module.
|IMAP rights||WebDAV privileges||HTTP methods|
|l - lookup
r - read
COPY/MOVE (on source)
|w - write
n - write shared annotation
COPY/MOVE (on destination)
|i - insert||DAV:write-content||PUT
COPY/MOVE (on destination resource)
UNLOCK (lock owner ONLY)
|p - post||DAV:bind||CYRUS:add-resource||POST|
|k - create mailbox||CYRUS:make-collection||MKCOL
COPY/MOVE (on destination collection)
|x - delete mailbox||DAV:unbind||CYRUS:remove-collection||DELETE (collection)
MOVE (on source collection)
|t - delete message
e - expunge
MOVE (on source resource)
|a - admin||CYRUS:admin||DAV:read-acl
PROPFIND (DAV:acl property ONLY)
UNLOCK (ANY lock)
|Regular Calendar Collections ONLY read freebusy time?|
|9 - freebusy||CALDAV:read-free-busy||REPORT (CALDAV:free-busy-query ONLY)
GET/HEAD (Freebusy URLs ONLY)
|Scheduling Outbox ONLY implicitly create/send iTIP message?|
|9 - freebusy||CALDAV:schedule-send||CALDAV:schedule-send-freebusy||POST
(by organizer on scheduling Outbox)
|8 - invite||CALDAV:schedule-send-invite||PUT/PATCH/DELETE
(by organizer on calendar resource/collection)
|7 - reply||CALDAV:schedule-send-reply||PUT/PATCH/DELETE
(by attendee on calendar resource/collection)
|Scheduling Inbox ONLY implicitly deliver/process incoming iTIP message?|
|9 - freebusy||CALDAV:schedule-deliver||CALDAV:schedule-query-freebusy|
|8 - invite||CALDAV:schedule-deliver-invite|
|7 - reply||CALDAV:schedule-deliver-reply|
|Collection||User ID||WebDAV Privileges||IMAP rights|
|Regular Calendar Collection||owner||DAV:all + CALDAV:read-free-busy||lrwipkxtan9|
|Managed Attachments Collection||owner||DAV:all||lrwipkxtan|
|Scheduling Inbox||owner||DAV:all + CALDAV:schedule-deliver||lrwipkxtan789|
|Scheduling Outbox||owner||DAV:all + CALDAV:schedule-send||lrwipkxtan789|
When enabled in conjunction with the CalDAV module, the Freebusy URL module allows non-CalDAV and/or remote calendaring clients to query the freebusy information of Cyrus CalDAV users.
Access to the freebusy information is controlled by the “freebusy” ACL (9) on a
user’s home calendar collection. (e.g. a mailbox named
user.murch.#calendars). To enable unauthenticated users (non-Cyrus) to
access freebusy information, the freebusy ACL must be given to “anyone”.
Freebusy information is accessed via URLs of the following form:
Query parameters can be added to the URL per Section 4 of Freebusy Read URL, allowing the user to choose to set the start, end, period and format of their query results.
Time Zone Distribution Service (TZDist)¶
What is TZDist¶
The Time Zone module allows Cyrus to function as a Time Zone Distribution Service (RFC 7808 and RFC 7809), providing time zone data for CalDAV and calendaring clients, without having to wait for their client vendor and/or OS vendor to update the timezone information. The responsibility for keeping the time zone information up to date then falls upon the Cyrus administrator.
TZDist is optional: without Cyrus having TZDist enabled, calendar clients should still be able to get their timezone information from their client or their OS.
TZDist is also required if you want the CalDAV server to strip known VTIMEZONEs
from incoming iCalendar data (as advertised by the
option from RFC 7809).
This module stores time zone data in the
zoneinfo/ subdirectory of the Cyrus
configuration directory (as specified by the
configdir option). The data is
indexed by a database whose location is specified by the
option, using the format specified by the
This module is designed to use the IANA Time Zone Database data (a.k.a. Olson Database) converted to the iCalendar format.
Cyrus uses a modified vzic to convert IANA
formatted data into iCalendar format. There is more information on Cyrus vzic in
The steps to populate the Cyrus
zoneinfo/ directory are:
Build the local “vzic” utility located in the
tools/vzic/subdirectory of the Cyrus source code. Run make in the tools/vzic/ subdirectory to build.
Download the latest version of the Time Zone Database data from IANA. Note you only need the data, not the code.
Expand the downloaded time zone data into a temporary directory of your choice.
configdir/zoneinfo/with iCalendar data:
Initial Install Only
Convert the raw data into iCalendar format by running vzic as follows:
vzic --pure --olson-dir <location-of-raw-data> --output-dir <configdir>/zoneinfo
This will create and install iCalendar data directly into the configdir/zoneinfo/ directory.
Updating Data Only
Convert the raw data into iCalendar format by running vzic as follows:
vzic --pure --olson-dir <location-of-raw-data>
This will create a zoneinfo/ subdirectory in your current location (which should be tools/vzic/).
Merge new/updated iCalendar data into the configdir/zoneinfo/ directory by running vzic-merge.pl in your current location:
Rebuild the Cyrus zoneinfo index by running ctl_zoneinfo(8) as follows:
ctl_zoneinfo -r <version-string>
where <version-string> describes the recently downloaded time zone data (e.g. “IANA Time Zone Database v.2013h”).
Check that the zoneinfo index database and all iCalendar data files/links are readable by the cyrus user.
iSchedule support in Cyrus is a work in progress.
iSchedule allows CalDAV servers to:
- query an event participant’s free/busy status prior to invitation in order to set up a good meeting time, which cannot be done over email.
- keep participant’s local event current by updating the status of other participants automatically. This is not done when scheduling over email as it would result in too much mail traffic and extra manual overhead for the users.
iSchedule is automatically enabled in Cyrus if both the CalDAV module and the
caldav_allowscheduling options are enabled in a
Cyrus Murder. In this instance, Cyrus uses iSchedule to move
scheduling messages from frontend to backend servers.
Support for scheduling with external servers is currently under development as there is the burden of authorization to verify the authenticity and integrity of these messages to prevent inadvertent or malicious data leaks or corruption.