Request for Comments: 4356 Qualcomm
Category: Standards Track January 2006
Mapping Between the Multimedia Messaging Service (MMS)
and Internet Mail
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The cellular telephone industry has defined a service known as the
Multimedia Messaging Service (MMS). This service uses formats and
protocols that are similar to, but differ in key ways from, those
used in Internet mail.
One important difference between MMS and Internet Mail is that MMS
uses headers that start with "X-Mms-" to carry a variety of user
agent- and server-related information elements.
This document specifies how to exchange messages between these two
services, including mapping information elements as used in MMS
X-Mms-* headers as well as delivery and disposition reports, to and
from that used in SMTP and Internet message headers.
Table of Contents
1. Introduction ....................................................2
1.1. Scope ......................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Definitions ................................................3
1.4. Abbreviations ..............................................4
1.5. Assumptions ................................................4
2. Mapping Between MMS and Internet Mail ...........................4
2.1. Mapping Specification ......................................5
2.1.1. MMS to Internet Mail ................................5
2.1.2. Internet Mail to MMS ................................5
2.1.3. MMS Information Element Mappings ....................6
2.1.4. Report Generation and Conversion ...................20
2.1.5. Message Delivery ...................................27
3. Security Considerations ........................................27
4. IANA Considerations ............................................27
5. Acknowledgements ...............................................27
6. Normative References ...........................................27
7. Informative References .........................................29
1. Introduction
1.1. Scope
This document describes how to exchange messages between Multimedia
Messaging Service (MMS) systems (as defined by [3GPP][3GPP2][OMA])
and Internet mail systems (that is, [SMTP] and [Msg-Fmt]). This
includes the translation of message formats, message header elements,
message delivery reports [DSN-Msg], and message disposition reports
[MDN].
The MMS architecture [Stage_2] and specifications [Stage_3] refer to
interfaces as reference points named MMx. For example, MM1 is the
client-server interface, MM4 is the server-server interface, and MM3
is an interface to "external" or non-MMS systems. The specification
in this document can be used for message exchange between any system
that uses Internet message formats and protocols and an MMS system;
from the perspective of the MMS system, reference point MM3 is used.
This document includes support for voice messages specified by the
Voice Profile for Internet Mail [VPIM]. The VPIM specification
allows voice messages to be exchanged between voice mail systems
using the Internet mail format [Msg-Fmt] and transported via [SMTP].
Thus, the MMS MM3 interface supports the ability to exchange voice
messages between an MMS system and a voice mail system. Note that
such use is distinct from voice media being part of a user-composed
multimedia message.
Note that MM3 can also be used for interworking with "external"
(non-MMS) systems other than Internet mail, such as Short Messaging
Service (SMS) and access to external mail stores (such as a voice
mail system). This specification does not address these other uses
or sub-interfaces of MM3; it is only concerned with Internet mail
interworking and specifically exchange of messages.
All MM3 Stage 2 [Stage_2] functions are supported except for reply
charging and sender address hiding.
1.2. Conventions Used in This Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
and "MAY" in this document are to be interpreted as described in "Key
Words for Use in RFCs to Indicate Requirement Levels" [KEYWORDS].
1.3. Definitions
--------------------|----------------------------------------------
Body |The portion of an [SMTP] message’s Content
|following the Header (that is, following the
|first blank line). The Body may contain
|structured parts and sub-parts, each of which
|may have its own Header and Body. The Body
|contains information intended for the message
|recipient (human or software).
--------------------|----------------------------------------------
Content |The portion of an SMTP message that is
|delivered. The Content consists of a Header
|and a Body.
--------------------|----------------------------------------------
Disposition Report |Feedback information to an originator User
|Agent by a recipient User Agent about
Message Disposition |handling of an original message. This may
Notification |include notification that the message was or
|was not read, was deleted unread, etc.
--------------------|----------------------------------------------
Envelope |The portion of an SMTP message not included in
|the Content, that is, not in the Header or in
|the Body. While some of it may be copied into
|the Content on delivery, envelope information
|exists only while the message is in transit,
|and contains information used by SMTP agents
|(Mail Transfer Agents (MTAs)).
--------------------|----------------------------------------------
Gateway |See [SMTP], Section 2.3.8.
--------------------|----------------------------------------------
--------------------|----------------------------------------------
Header |The first part of an SMTP message’s Content.
|The Header is separated from the Body by a
|blank line. The Header consists of Fields
|(such as "To:"), also known as Header Fields
|or Headers. The message Header contains
|information used by User Agents.
--------------------|----------------------------------------------
Relay/Server |An MMS server. See [Stage_2]. For purposes
|of this document, an MMS Relay/Server acts as
|a gateway when it receives or sends messages
|via Internet mail.
--------------------|----------------------------------------------
User Agent |An MMS or email user agent.
--------------------|----------------------------------------------
1.4. Abbreviations
--------|----------------------------------------------------------
MSA |Message Submission Agent. A server that accepts messages
|from User Agents and processes them, either delivering
|them locally or relaying to an MTA. See [Submission].
--------|----------------------------------------------------------
MTA |Mail Transfer Agent. A server that implements [SMTP].
--------|----------------------------------------------------------
1.5. Assumptions
It is assumed that the reader is already familiar with the contents
of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1
(requirements) [Stage_1] and Stage 2 (architecture and abstract
messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3]
documents. It is also assumed that the reader is familiar with
Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt].
2. Mapping Between MMS and Internet Mail
This section defines the interworking between MMS Relay/Servers and
External Servers using native [SMTP]. That is, information elements
are exchanged using standard Internet message [Msg-Fmt] header
fields, such as those in [Hdrs], and standard [SMTP] elements.
SMTP and Internet mail extensions are used for features such as
delivery reports, message expiration, and discovery of server support
for optional features.
2.1. Mapping Specification
2.1.1. MMS to Internet Mail
When sending a message to an Internet mail system, the MMS
Relay/Server MUST convert the MM if required, and MUST comply with
the requirements of [SMTP].
The MMS Relay/Server SHOULD use the information elements associated
with the MM to define the control information (Internet message
header fields and SMTP envelope values) needed for the transfer
protocol.
Section 2.1.3 lists the mappings between X-Mms-* headers and Internet
message header fields and SMTP values.
Delivery and read report MMs SHOULD be converted to standard Internet
message report format (multipart/report). In addition to converting
Internet Message reports, the MMS Relay/Server MUST generate delivery
and read report MMs for received messages as appropriate. See
Section 2.1.4 for more information.
2.1.2. Internet Mail to MMS
When receiving a message from an Internet mail system, the MMS
Relay/Server converts incoming messages to the MM format used within
the receiving system.
The MMS Relay/Server converts control information received from the
Internet mail server into appropriate information elements of an MM.
Section 2.1.3 lists the mappings between X-Mms-* headers and Internet
message header fields and SMTP values.
Standard Internet message report format (multipart/report) messages
MAY be converted to delivery or read report MMs, as appropriate. In
addition to converting report MMs, implementations conforming to this
document MUST generate standard Internet message delivery and
disposition reports for received Internet messages as appropriate.
See Section 2.1.4 for more information.
2.1.3. MMS Information Element Mappings
The mappings between MMS elements and SMTP/Internet message elements
([SMTP] parameters, [Msg-Fmt] headers, and [DSN-Msg] fields) are
summarized in table 1 below, and detailed in subsequent sections.
The "MMS Headers" are from [OMA-MMS]. Note that only information
elements that need to be mapped are listed. [Msg-Fmt] headers not
listed here SHOULD be passed unaltered.
2.1.3.1. Table 1: Information Element Mappings
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS
| | | -Version:
_________________|_________________|________________|______________
Message Type |N/A |N/A |X-Mms-Message-
(of PDU) | | | Type:
_________________|_________________|________________|______________
Transaction ID |N/A |N/A |X-Mms-Transact
| | | ion-Id:
_________________|_________________|________________|______________
Message ID |N/A |Message-ID: |Message-ID:
_________________|_________________|________________|______________
Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc:
address(es) |address(es) |omitted (Bcc) |
_________________|_________________|________________|______________
Sender’s address |MAIL FROM |From: |From:
|address if | |
|user-originated; | |
|MUST set MAIL | |
|FROM to null | |
|("<>") for all | |
|automatically- | |
|generated MMs | |
_________________|_________________|________________|______________
Content type |N/A |Content-Type: |Content-type:
| | |
| |For voice mes- |
| |sages compliant |
| |to [VPIM], see |
| |Note 2 |
_________________|_________________|________________|______________
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Message class |Class=auto: |MAY set ’Prece |X-Mms-Message-
|MUST set MAIL | dence: bulk’ | Class:
|FROM to null |on class=auto |
|("<>"). | |
_________________|_________________|________________|______________
Date and time |N/A |Date: |Date:
of submission | | |
_________________|_________________|________________|______________
Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry:
|[Deliver-By] | |
_________________|_________________|________________|______________
Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery
ery time |sion; not relay) | | -Time:
_________________|_________________|________________|______________
Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery
request |SHOULD also | | -Report:
|specify recip- | |
|ient address as | |
|ORCPT; SHOULD | |
|also specify | |
|ENVID | |
_________________|_________________|________________|______________
Importance (a/k/a|N/A |Importance: |X-Mms-
"priority") | | | Priority:
| | |
| | |
_________________|_________________|________________|______________
Sender visib- |(not currently |(not currently |X-Mms-Sender-
ility |supported) |supported) | Visibility:
_________________|_________________|________________|______________
Read reply |N/A |Disposition- |X-Mms-Read-
request | | Notification | Reply:
| | -To: [MDN] |
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
deadline | | | Deadline:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
limitation | | | Size:
_________________|_________________|________________|______________
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage request |supported) |supported) | Charging-
| | | Id:
_________________|_________________|________________|______________
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage reference |supported) |supported) | Charging:
_________________|_________________|________________|______________
Subject |N/A |Subject: |Subject:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-From: |X-Mms-Previous
by | | | ly-Sent-By:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-Date: |X-Mms-
date | | | Previously-
| | | Sent-Date-
| | | and-Time:
_________________|_________________|________________|______________
Hop/host trace |N/A |Received: |(Not sup-
| | |ported)
_________________|_________________|________________|______________
Sensitivity |N/A |Sensitivity: see|N/A
| |Note 1 |
_________________|_________________|________________|______________
Content |N/A |<message body> |<message body>
=================|=================|================|==============
Note 1: The [VPIM] ’Sensitivity’ header element indicates the
privacy requested by the message originator (values are "personal" or
"private"); per [VPIM], a message recipient MUST NOT forward a
message with a ’Sensitivity’ header. Since sensitivity is not an MMS
feature, any messages that contain a ’Sensitivity:’ header SHOULD NOT
be sent to an MMS system.
Note 2: [VPIM] specifies how conforming messages are identified.
2.1.3.2. Conversion of Messages from MMS to Internet Format
3GPP MMS Version
The ’X-Mms-3GPP-MMS-Version:’ header, if present, SHOULD be removed.
Message Type (of PDU)
The ’X-Mms-Message-Type:’ header, if present, SHOULD be removed.
Transaction ID
The ’X-Mms-Transaction-Id:’ header, if present, SHOULD be removed.
Message ID
The ’Message-Id:’ header MUST be retained. If not present, it MUST
be created, with a unique value, per [Msg-Fmt].
To facilitate the case where an MMS message traverses the Internet
prior to returning to an MMS system, implementations might wish to
retain the ’X-Mms-Message-Id:’ header. Such systems should be aware
that headers that begin with "X-" might be removed during transit
through Internet MTAs.
Recipient(s) address
The address of each recipient MUST be transmitted in the [SMTP]
envelope as a RCPT TO value. All disclosed recipients SHOULD also
appear in a ’To:’ or ’Cc:’ header. At least one ’To:’, ’Cc:’, or
’Bcc:’ header MUST be present. If none are present, a ’To:’ header
SHOULD be created using empty group syntax whose name gives an
indication to a human reader, for example, ’To: undisclosed-
recipients:;’.
The ’To:’ header SHOULD NOT appear more than once. The ’Cc:’ header
SHOULD NOT appear more than once.
Each recipient address MUST obey the length restrictions per [SMTP].
Current Internet Message format requires that only 7-bit US-ASCII
characters be present in headers. Non-7-bit characters in an address
domain must be encoded with [IDN]. If there are any non-7-bit
characters in the local part of an address, the message MUST be
rejected. Non-7-bit characters elsewhere in a header MUST be encoded
according to [Hdr-Enc].
All recipient addresses in the [SMTP] envelope must be fully-
qualified in accordance with [SMTP]. In particular, messages MUST
NOT be sent to an Internet mail system with an unqualified E.164