An Email Header for Improved iMIP Interoperability

Abstract

This document defines a new email message header to improve interoperability when the iCalendar Message-Based Interoperability Protocol (iMIP) is being used to send scheduling messages.¶

1. Introduction

The iCalendar [RFC5545] specification defines a standard way to describe calendar data. The iTIP [RFC5546] specification defines a transport independent messaging protocol for scheduling messages based on iCalendar. The iMIP [RFC6047] specification defines how the iTIP protocol can be used over an email [RFC5322] transport by "attaching" iCalendar parts to an email message.¶

Whilst iMIP has been in use for quite some time, there continue to be problems with interoperability between different implementations. In particular, many implementations are sensitive to the exact "structure" of the email message parts. Some clients expect specific headers to be present, or to have specific values (e.g., a "Content-Disposition" header with a value "attachment"). What this means is that an iMIP message sent from one client to another often goes unrecognized as an iMIP message, and the calendar data is never processed as a scheduling message. In some cases, clients generate multiple iCalendar attachments, with different "Content-Type" header values in order to have a greater chance of their message being processed correctly.¶

This specification addresses these problems by introducing a new email message header that can be used by clients to clearly identify that an email message is in fact an iMIP message, as well as clearly identify which part within the email message corresponds to the iCalendar data to be processed as an iMIP message.¶

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶

3. iMIP-Content-ID Email Message Header

When a client generates an iMIP email message it includes an "iMIP-Content-ID" header field in the MIME part corresponding to the iCalendar data used for scheduling. There MUST be only one iCalendar part with that header present. The client then includes an "iMIP-Content-ID" header in the top-level email message headers, setting the value of that header to the value used for the "iMIP-Content-ID" header associated with the iCalendar data part.¶

A mail user agent that is capable of processing iMIP messages can do the following:¶

1. If a top-level "iMIP-Content-ID" message header is present, the mail user agent can parse the message body and extract the iCalendar data in the message sub-part with the matching "iMIP-Content-ID" header value. This can then be handed off to the appropriate calendar user agent for processing as an iTIP message. If an "iMIP-Content-ID" header is present at the top-level of the message, but no matching iCalendar data is found, then the email message MUST be processed as if the "iMIP-Content-ID" header were not present.¶

2. If an "iMIP-Content-ID" header is not present at the top-level of the message, then the client SHOULD look for the presence of that header in a message sub-part and apply the following rules:¶

   1. If a single "iMIP-Content-ID" is present in a sub-part of the message and the associated part is a valid iCalendar iMIP message, then the iCalendar data can be handed off to the appropriate calendar user agent for processing as an iTIP message.¶
   2. In all other cases (including multiple "iMIP-Content-ID" headers present in different sub-parts), the email message MUST be processed as if the "iMIP-Content-ID" header were not present.¶

The key benefit of this approach is that it allows mail user agents (and automated email processing/filtering systems like SIEVE [RFC5228]) to quickly and clearly identify incoming iMIP messages, without the need to do an in-depth examination of the MIME structure of the message to look for suitable iCalendar attachments. In addition, the presence of this header will not impact current processing of iMIP messages and thus provides a backwards compatible, incremental upgrade to a more reliable mechanism.¶

imip-content-id = "iMIP-Content-ID:" msg-id

4. Security Considerations

Email message security typically does not cover top-level message headers in signed or encrypted email data. It is therefore possible for an attacker to add, modify or remove an "iMIP-Content-ID" header in the top-level message headers. Such an attack can be mitigated by using a technology such as DomainKeys Identified Mail (DKIM) [RFC6376], and it is RECOMMENDED that the "iMIP-Content-ID" header be included as one of the signed header fields.¶

5. IANA Considerations

The IANA is asked to register the new header field, using the template as follows, in accordance with [RFC3864].¶

Header field name:

iMIP-Content-ID¶

Applicable protocol:

mail¶

Status:

standard¶

Author/Change controller:

IETF¶

Specification document(s):

This document¶

Related information:

iMIP [RFC6047]¶

6. Acknowledgments

Thanks to the following for feedback: Ken Murchison.¶

This specification originated from discussions at a Calendaring and Scheduling Consortium interoperability event.¶

7. References

Appendix A. Example of Common iMIP Message Structures

TBD¶