Summary

  • RFC 9671 lets a Sieve script add, update, cancel or remove calendar data carried by email, subject to explicit recipient, format and safety checks.
  • Its optional updated outcome intentionally combines three different mutations, while the accompanying reason may be empty.
  • A defensible record joins the message, trust inputs, MIME equivalence, target calendar, action options, coarse outcome and a readback of the final event, alarms, attachments and participant state.

The automation log contained one reassuring word: updated. The mail had carried a cancellation. The Sieve script used :deletecancelled. An operator opened the calendar expecting a retained event marked cancelled and found no event at all.

That result can be entirely conformant. RFC 9671 defines updated to mean that a calendar object was updated, cancelled or removed. The single value is useful inside a filtering script. It tells the script that calendar processing reached one family of successful outcomes. It was never designed to reconstruct the resulting calendar.

The distinction matters because calendar automation crosses two systems with different consequences. Email brings a claim about an event. A calendar service turns that claim into durable state, reminders and a human schedule. When a compact signal from the first system is promoted into proof about the second, an accurate log can support a false operational story.

Before mutation, the input must earn eligibility

RFC 9671 adds the processcalendar capability to Sieve. The action parses machine-readable calendar data encapsulated in MIME email and may create, update or delete calendar items. It is not permission to process every attachment that resembles an invitation.

Malformed data must be ignored. If several MIME parts carry calendar data, the implementation must compare them for semantic equivalence. Different representations that disagree must stop processing; equivalent representations yield only one processed copy. This is more than syntactic tidiness. A readable HTML invitation and a machine-readable attachment can tell different stories, and the calendar-changing representation is the consequential one.

The recipient boundary is also explicit. Unless :allowpublic is used, the data must be well-formed iTIP and one address belonging to the recipient must match the intended target: the ORGANIZER for a reply, or an ATTENDEE for a request, cancellation or addition. The address may come from account knowledge, the final envelope recipient or a script's :addresses list.

Each source answers a different question. The visible To field is not the final envelope recipient. An alias in :addresses is a policy assertion, not proof that every message using it should alter a calendar. A matching ATTENDEE is target evidence, not organizer authority.

The options change what success can mean

The action's options define materially different control surfaces. :updatesonly prevents a new UID from being added. Its no_action can therefore be the desired safety result, not a failure. :calendarid selects where a new object belongs; if it is absent, the implementation chooses a default calendar. A successful addition does not prove that the operator intended that destination.

Cancellation contains the sharpest ambiguity. With :deletecancelled, the implementation should remove the associated item. Without it, the item is marked cancelled and retained. Both routes can produce updated. Even the presence of :deletecancelled does not prove deletion, because the RFC expresses removal as a SHOULD. The result must be observed.

The optional :organizers list is another real but bounded control. When used, it requires well-formed iTIP and an ORGANIZER address matching an external list. When omitted, processcalendar performs no ORGANIZER-property validation. A list match establishes that a string fell within a configured trust set. It does not establish that the person controlling that address intended this particular cancellation at this time.

Authentication contributes evidence, not intention

RFC 9671 is unusually candid about the danger: changing a calendar without user interaction can be an abuse vector. It forbids processing data in mail flagged as spam or malicious, recommends known senders, discourages potentially malicious or untrustworthy senders, and points to S/MIME, SPF, DKIM and DMARC as possible trust inputs.

Those mechanisms should not be dismissed. They narrow important questions. SPF relates an SMTP client to a domain's authorization policy. DKIM verifies a signature over selected message material under a signing domain. DMARC evaluates alignment and receiver policy. S/MIME can provide message signing with its own certificate and identity checks.

But a pass does not prove the present mental act of a human organizer. A legitimate account can be compromised. An authorized service can send the wrong event. A signed message can be replayed within the limits of the surrounding system. An aligned domain can carry an automated decision no executive approved. Trust signals inform the calendar policy; they do not become the calendar policy.

This is the doctrine of minimum specification applied correctly. Standardize enough common behavior to interoperate, then leave local risk decisions visible. The mistake is to hide the local decision inside the prestige of the shared mechanism.

A four-value result cannot carry the whole state transition

The optional outcome has four values: no_action, added, updated and error. The optional reason may explain the result, but the RFC allows an empty string when no reason is available. Operators must not invent precision that the interface does not supply.

no_action can mean no calendar data or a policy option that prevented processing. error means the message would have been processed but encountered a failure. added identifies a new item, yet not necessarily the intended calendar. updated collapses content change, cancellation and removal.

The correct evidence chain therefore continues after Sieve. Preserve the message identifier, final envelope recipient, script generation, option set, all calendar-bearing MIME parts and their semantic-equivalence result. Record format, iTIP method, UID, organizer, target attendee, trust decisions, selected calendar and the exact outcome and reason.

Then read the calendar. Does the UID exist? On which calendar? What sequence or revision is present? Is STATUS now CANCELLED, or is the item absent? Did participant status remain unchanged, as RFC 9671 requires? Were alarms removed, as it recommends, or could old reminders still fire? Were embedded attachments decoded and scanned? If a malicious attachment was found, processing must have stopped.

Mail disposition also remains separate. processcalendar does not cancel Sieve's implicit keep. A calendar can change while the original email remains in the mailbox. Deleting the mail later does not prove the event was removed; removing the event does not prove the mail disappeared.

CalConnect's calendar-abuse guidance explains why this separation is operationally important. Unwanted events can be placed in the past or future, recur repeatedly and trigger alarms across several devices. One accepted invitation can create effects far from the mail-processing instant. The final human-visible outcome is therefore another observation, not a synonym for action success.

RFC 9671 is not weak because updated is coarse. It is honest. It supplies a portable branch condition and leaves the richer truth in the running calendar system. The failure begins when an organization turns that bounded fact into a claim about exact state, trusted intention or completed user outcome.

Sources