iCalendar Message-Based Interoperability Protocol (iMIP)
obsoletes
- rfc-2447 — iCalendar Message-Based Interoperability Protocol (iMIP)
Extracted elements (25)
The RFC 5322 'Reply-To' header field typically contains the originator's address but cannot be relied upon, because the MIME sender may not be the scheduling message originator and the MUA may not enforce iMIP semantics. Therefore, ORGANIZER/ATTENDEE must be determined from the iCalendar object itself.
A 'text/calendar' MIME body part that lacks the 'method' parameter is not considered an iMIP body part and is not subject to iMIP requirements. Receiving implementations must distinguish iMIP messages from generic iCalendar attachments by the presence of this parameter.
A MIME body part conforming to iMIP MUST have a Content-Type of 'text/calendar' and MUST also include the MIME parameter 'method', whose value MUST be the same (ignoring case) as the METHOD property within the iCalendar object.
A MIME message containing multiple iCalendar objects with different 'method' values MUST be further encapsulated within a 'multipart/mixed' MIME entity so each iCalendar object resides in its own 'text/calendar' part.
Any receiving UA compliant with this specification MUST be able to process 'text/calendar' body parts enclosed within 'multipart/*', and MUST be able to process all such parts when a 'multipart/mixed' message contains multiple 'text/calendar' components.
Authentication MUST be performed using S/MIME (RFC 5750, RFC 5751). Authentication is only possible on signed messages; unauthenticated (unsigned) messages may not be trusted.
Calendar addresses in ORGANIZER and ATTENDEE properties within an iMIP message MUST be proper 'mailto:' URI specifications for the corresponding Organizer or Attendee of the VEVENT or VTODO.
Compliant applications MUST support signing and encrypting 'text/calendar' body parts using S/MIME in order to facilitate authentication of the originator of the iCalendar object.
If the iCalendar object contains characters that cannot be represented in US-ASCII, a 'charset' MIME parameter MUST be present with the value 'UTF-8', since the iCalendar default is UTF-8 but the text/* MIME default is US-ASCII.
Implementations MUST provide mechanisms for Calendar Users to decide whether to accept changes from someone working on behalf of another Calendar User (via the 'sent-by' parameter), because iCAL and iTIP provide no mechanism to verify such delegation.
Implementations of iMIP SHOULD verify the authenticity of the creator of an iCalendar object before taking any action.
It is strongly RECOMMENDED that iMIP implementations include all CID- or MID-referenced messages and body parts in a single MIME entity to ensure the receiving CUA has access and authorization to view those objects.
'multipart/alternative' MUST NOT be used to represent two slightly different iCalendar objects (e.g., two VEVENTs with alternative starting times).
Scheduling messages SHOULD be sent with an alternative, human-readable form of the information to allow MIME UAs that do not support 'text/calendar' to render the content.
The handling of a MIME part MUST be based on its RFC 2045 Content-Type and not on the file extension specified in the Content-Disposition header, because malware is known to exploit Content-Disposition extension mismatches to trick UAs.
The Organizer MUST ignore an iTIP message from a spoofed address that attempts to decline a meeting invitation on behalf of another attendee. Only the respondent is authorized to indicate their status to the Organizer.
The relevant Organizer or Attendee address MUST be ascertained by opening the 'text/calendar' MIME body part and examining the ATTENDEE and ORGANIZER properties; it cannot be reliably inferred from RFC 5322 Sender or Reply-To header fields.
To ensure confidentiality, implementations SHOULD utilize encryption as specified in S/MIME. Within a single ADMD, SMTP STARTTLS (together with STARTTLS in IMAP/POP) MAY alternatively be used.
Unless transported over 8-bit clean transport, a transfer encoding such as quoted-printable or base64 MUST be used for iCalendar objects containing characters that cannot be represented in US-ASCII.
iMIP defines the binding of iTIP scheduling messages to Internet email (MIME/SMTP). A MIME entity carrying calendaring content uses the 'text/calendar' content type, transported over SMTP as defined in RFC 5322 and RFC 2045.
iMIP-based calendaring deployed within a single ADMD with boundary filtering can help minimize malicious changes to calendaring messages in transit and make authorization decisions less risky.
Once a signed and/or encrypted iMIP message is received, the CUA SHOULD remember whether the sender uses signing/encryption. If a subsequent unsigned message arrives from the same sender, the CUA SHOULD warn the user about a possible man-in-the-middle attack and SHOULD ignore the message unless the user explicitly overrides.
The four-step signed iMIP message processing procedure: (1) determine the S/MIME signer; (2) correlate the signer to an ATTENDEE or ORGANIZER property; (3) verify the signer is authorized for the operation per iTIP; (4) if all conditions are met, process the message. The signer's email MUST appear in the rfc822Name field of the subject alternative name extension of the signer certificate.
Two primary spoofing threats exist: spoofing the Organizer and spoofing an Attendee. To address these, the originator of an iCalendar object must be authenticated by the recipient before any action is taken, using S/MIME-based signing.
The Content-Type header for an iMIP body part takes the form: 'text/calendar; method=<METHOD>; charset=UTF-8; component=<component>'. The 'method' parameter is mandatory for iMIP; a 'text/calendar' part lacking it is not subject to iMIP requirements.