Purelymail Calendar

Docs

Purelymail CalDAV RSVP tracking

Purelymail CalDAV stores calendar events, but it does not poll attendee replies and write their RSVP status back. That handshake is the iTIP REPLY half of the iCalendar protocol (RFC 5546).

Purelymail Calendar closes the loop. When an attendee accepts or declines, their mail client sends an iTIP REPLY back to the organizer's Purelymail inbox. Purelymail Calendar polls that inbox over IMAP, matches the reply to the original event by UID, and updates the PARTSTAT field on the CalDAV record.

The reply loop.

Attendee
Clicks Accept / Decline / Tentative in their mail client.
→
SMTP
Their client sends an iTIP REPLY to the organizer.
→
Organizer IMAP
REPLY lands in the Purelymail inbox.
→
Poller
Purelymail Calendar scans IMAP every 5 min.
→
CalDAV PUT
PARTSTAT set on the matching VEVENT.

The organizer's calendar reflects each attendee's answer within minutes of their reply, without any manual sync.

What each step looks like.

Event Where it happens Stored in
Organizer sends REQUEST Purelymail Calendar via your Purelymail SMTP. Purelymail mail logs (sent folder).
Attendee replies Their mail client (Gmail, Apple Mail, Outlook, Thunderbird). Their own mailbox.
REPLY reaches organizer Standard SMTP delivery to the organizer's Purelymail mailbox. Organizer's Purelymail IMAP inbox.
Poller matches and applies Purelymail Calendar IMAP poller (5-min cron). Purelymail CalDAV: PARTSTAT on the VEVENT.

What the poller looks for.

On each tick the poller searches the organizer's inbox for messages whose text/calendar part has METHOD:REPLY, extracts the VEVENT, and matches it to a stored event by UID. Each ATTENDEE line in the reply carries a PARTSTAT value (ACCEPTED, DECLINED, or TENTATIVE), which is written back to the matching ATTENDEE line on the CalDAV VEVENT.

A small but important detail: replies must keep the original UID. iTIP clients all do this correctly. If you ever see an RSVP that does not stick, the most common cause is a forwarded or rewritten reply where the UID was altered.

What an iTIP REPLY looks like.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//macOS 14//EN
METHOD:REPLY
BEGIN:VEVENT
UID:9c7b6e1c-58fd-4ab1-9b8c-d3f5d4e7a012
SEQUENCE:1
ORGANIZER;CN=You:mailto:you@yourdomain.com
ATTENDEE;CN=Alex;PARTSTAT=ACCEPTED:mailto:alex@example.com
DTSTART:20260601T150000Z
DTEND:20260601T160000Z
SUMMARY:Project sync
END:VEVENT
END:VCALENDAR

Failure modes worth knowing.

The reply hits the spam folder.

The poller scans INBOX only. If your domain's SPF/DKIM/DMARC records are misconfigured, attendees' replies can land in the Junk folder and never reach the poller. Standard mail-deliverability hygiene applies.

The attendee uses a non-iTIP-aware client.

A handful of webmail clients still send a plain-text "Yes I will be there" reply rather than an iTIP REPLY. There is no machine-readable status in that message and no CalDAV record can be updated automatically. This is rare on modern Gmail, Apple Mail, Outlook, and Thunderbird.

SEQUENCE mismatch.

Per RFC 5546, an attendee should reply with the same SEQUENCE they received. Replies to a stale event version are still applied, because the UID matches; the trade-off is the attendee may have answered a meeting that has since moved.

Where to go next.

Sign in to Purelymail Calendar  →