RFC 9671: Sieve Email Filtering: Extension for Processing Calendar Attachments

4.1. Allow Public Argument

The optional :allowpublic argument is used to tell the implementation that it can process calendar data that does not contain any ATTENDEE properties, such as iTIP messages where the METHOD is PUBLISH or non-iTIP messages where the calendar data does not contain METHOD and/or ORGANIZER properties.¶

If used in conjunction with the :organizers argument (Section 4.6), the implementation MUST NOT process non-iTIP messages.¶

If :allowpublic is omitted, the implementation MUST NOT process calendar data unless is it is a well-formed iTIP message and one of the recipient user's email addresses matches the Calendar User Address (see Section 3.3.3 of [RFC5545]) of the intended target of the message, as determined by the iTIP method (see Section 1.4 of [RFC5546]) of the message:¶

The recipient user's email address matches the Calendar User Address of the target if the Calendar User Address is in the form of a mailto URI and the email address matches the "addr-spec" of the URI.¶

An email address is considered to belong to the recipient if it is one of the following:¶

4.2. Addresses Argument

The optional :addresses argument is used to specify email addresses that belong to the recipient in addition to the addresses known to the implementation.¶

4.3. Updates Only Argument

The optional :updatesonly argument is used to limit the messages processed to those targeting existing calendar objects only. If the message contains a new calendar object (its unique identifier does not exist on any of the user's calendars), the implementation MUST NOT add the object to a calendar.¶

If :updatesonly is omitted, new calendar objects may be added to one of the user's calendars.¶

The :updatesonly and :calendarid (Section 4.4) arguments are incompatible with each other. It is an error if both arguments are used in the same "processcalendar" action.¶

4.4. Calendar ID Argument

The optional :calendarid argument specifies the identifier of the calendar onto which new calendar objects should be placed.¶

If :calendarid is omitted, new calendar objects will be placed on the user's "default" calendar as determined by the implementation.¶

The :updatesonly (Section 4.3) and :calendarid arguments are incompatible with each other. It is an error if both arguments are used in the same "processcalendar" action.¶

4.5. Delete Cancelled Argument

The optional :deletecancelled argument is used to tell the implementation that if it receives a cancellation message, it SHOULD remove the associated calendar object from the calendar.¶

If :deletecancelled is omitted, the status of the associated calendar object will be set to cancelled and will remain on the calendar.¶

4.6. Organizers Argument

The optional :organizers argument is used to specify an external list of email addresses from which the recipient is willing to accept public events, invites, updates, and cancellations. Implementations MUST NOT process calendar data unless is it is a well-formed iTIP message and one of the addresses in the external list matches the Calendar User Address of the ORGANIZER property. An email address in the external list matches the Calendar User Address of the ORGANIZER property if it is in the form of a mailto URI and the email address matches the "addr-spec" of the URI.¶

If :organizers is omitted, no validation of the ORGANIZER property is performed.¶

4.7. Outcome Argument

The optional :outcome argument specifies the name of a variable into which one of the following strings specifying the outcome of the action will be stored:¶

"no_action":

No action was performed (e.g., the message didn't contain calendar data, or the set of provided options prevented the message from being processed).¶

"added":

A new calendar object was added to a calendar.¶

"updated":

A calendar object was updated, cancelled, or removed from the calendar.¶

"error":

The message would have been processed but encountered an error in doing so.¶

4.8. Reason Argument

The optional :reason argument specifies the name of a variable into which a string describing the reason for the outcome will be stored. If no reason for the outcome is available, implementations MUST set the variable to the empty string.¶

For example, an outcome of "no_action" may have a reason of "only processing updates", or an outcome of "error" may have a reason of "missing unique identifier".¶

4.9. Interaction with Other Sieve Actions

The "processcalendar" action does not cancel Sieve's implicit keep action.¶

The "processcalendar" action can only be executed once per script. A script MUST fail with an appropriate error if it attempts to execute two or more "processcalendar" actions.¶

The "processcalendar" action is incompatible with the Sieve "reject" and "ereject" actions [RFC5429].¶

4.10. Examples

The following example specifies email addresses belonging to the user and the identifier of the calendar onto which to place new calendar objects:¶

require [ "processcalendar" ];

processcalendar :addresses [ "me@example.com", "alsome@example.com" ]
                :calendarid "1ea6d86b-6c7f-48a2-bed3-2a4c40ec281a";

The following example tells the interpreter to process flight itineraries from a particular airline:¶

require [ "processcalendar" ];

if allof (address ["from", "sender"] "airline@example.com",
          header :contains "subject" "itinerary") {
   processcalendar :allowpublic;
}

The following example adds headers to the message if calendar data isn't processed :¶

require [ "processcalendar", "variables", "editheader" ];

set "processcal_outcome" "no_action";
set "processcal_reason" "";

processcalendar :outcome "processcal_outcome"
                :reason "processcal_reason";

if not string :is "${processcal_outcome}" ["added", "updated"] {
   addheader "X-ProcessCal-Outcome" "${processcal_outcome}";
   addheader "X-ProcessCal-Reason" "${processcal_reason}";
}