| |* delivered (used for MMS status
| |values ’retrieved’ and ’rejected’,
| |depending on ’Status’ code).
| |
| |* failed (used for MMS status
| |values ’expired’ and ’unreachable’)
| |
| |* delayed MAY be used for MMS
| |status value ’deferred’
| |
| |* relayed (used for MMS status
| |value ’indeterminate’)
| |
| |* expanded (SHOULD NOT be used)
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
----------------------|------------|-----------------------------------
When an MMS Relay/Server generates a [DSN-Msg] in response to a
message received using [SMTP] on MM3:
* Top-level header field ’To:’ SHOULD be the [SMTP] return-path of
the message whose status is being reported.
* Top-level header field ’From:’ SHOULD be the address of the
recipient that the delivery-report concerns.
* The first part of the [DSN-Msg] SHOULD include the MM Status Text
field that would have been generated for an MM1 delivery-report.
2.1.4.2 Delivery Report Mapping from Internet Message to MMS
Below, Table 5 maps information elements from a delivery report as
specified in [DSN-Msg] to the format of an MMS delivery report. Note
that a single DSN that reports multiple recipients will result in
several MMS delivery reports.
2.1.4.2.1. Table 5: Delivery Report Mappings (Internet Message to MMS)
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
ID of the original |Message-Id: |’Message-ID:’ header preserved
message (object of | |in third sub-part of report.
delivery report) | |
-------------------|------------------|--------------------------------
Recipient address |From: |If available, the ’Original
of the original | |-Recipient’ field of the per-
message (object of | |recipient section should be
delivery report) | |used; otherwise, the ’Final-
| |Recipient’ field of the per-
| |recipient section is used.
-------------------|------------------|--------------------------------
Destination address|To: |’To:’ header field value of
of report | |top-level.
| |
| |Value taken from [SMTP] envelope
| |return-path of message being
| |reported, not its ’From:’ header
| |field.
-------------------|------------------|--------------------------------
Date and time the |Date: |’Date:’ header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
Delivery status of |X-Mms-Status: |’Action’ and ’Status’ fields of
original message | |per-recipient section.
|Set to one of the |
|following values: |
| |
|’retrieved’ (used |
|for ’Action’ value|
|’delivered’). |
| |
|’unreachable’ |
|(used for ’Action’|
|value ’failed’) |
| |
|’forwarded’ (used |
|for ’Action’ value|
|’relayed’) |
| |
|’deferred’ MUST |
|NOT be used |
|(ignore DSNs with |
|’Action’ value |
|’delayed’) |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================
2.1.4.3. Read Report Mapping from MMS to Internet Message
Below, Table 6 maps information elements from MMS read reports to the
format specified in [MDN].
2.1.4.3.1. Table 6: Read Report Mappings (MMS to Internet Message)
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
ID of the original |Message-Id: |’Message-ID:’ header preserved in
message (object of | |third part of report.
read report) | |
----------------------|------------|-----------------------------------
Recipient address of |From: |’Final-Recipient’ field.
the original message | |
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
Destination address of|To: |’To:’ header field value of top-
report | |level.
| |
| |Value taken from ’Disposition-
| |Notification-To:’ header field of
| |message being reported, not its
| |’From:’ header field.
----------------------|------------|-----------------------------------
Date and time the |Date: |’Date:’ header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
Disposition of message|X-Mms-Read- |Disposition-field
being reported | Status: |
| |For X-MMS-Read-Status value ’read’,
| |use ’disposition-type’ value
| |’displayed’; for X-MMS-Read-Status
| |value ’Deleted without being read’,
| |use ’disposition-type’ value
| |’deleted’).
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
======================|============|===================================
When an MMS Relay/Server generates an [MDN] in response to a message
received using [SMTP] on MM3:
* Top-level header field ’To:’ SHOULD be the value of the
’Disposition-Notification-To:’ header field of the message whose
disposition is being reported.
* Top-level header field ’From:’ SHOULD be the address of the
recipient that the read report concerns.
2.1.4.4. Disposition Report Mapping from Internet Message to MMS
Below, Table 7 maps information elements from a disposition report as
specified in [MDN] to the format of an MMS read report.
2.1.4.4.1. Table 7: Disposition Report Mappings
(Internet Message to MMS)
===================|==================|================================
Information Element|MMS Read Report |[MDN] Element
|Element |
===================|==================|================================
ID of the original |Message-Id: |’Message-ID:’ header preserved
message (object of | |in third subpart of report.
disposition report)| |
-------------------|------------------|--------------------------------
Recipient address |From: |’Final-Recipient’ field.
of the original | |
message | |
-------------------|------------------|--------------------------------
Destination address|To: |’To:’ header field value of
of report | |top-level.
| |
| |Value taken from ’Disposition-
| |Notification-To:’ header field
| |of message being reported, not
| |its ’From:’ header field.
-------------------|------------------|--------------------------------
Date and time the |Date: |’Date:’ header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
Disposition of |X-Mms-Read-Status:|disposition-field.
message being | |
reported |Set to one of the |
|following values: |
| |
|’read’ (used for |
|disposition-type |
|value ’displayed’)|
| |
|’Deleted without |
|being read’ (used |
|for disposition- |
|types ’deleted’, |
|’denied’ and |
|’failed’ when |
|action-mode is |
|’automatic- |
|action’) |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================
2.1.5. Message Delivery
Within Internet mail, when [SMTP] is used and delivery reports are
requested [DSN-SMTP], delivery is considered to be acceptance of a
message by the final server, that is, the server closest to the
recipient. When an MMS Relay/Server receives a message using [SMTP]
and a delivery report is requested, the MMS Relay/Server MAY consider
the message delivered when it has been sent to the MMS User Agent.
3. Security Considerations
Both MMS and Internet mail have their own set of security risks and
considerations. This document specifies how to exchange messages
between these two environments, so it is only appropriate to discuss
considerations specific to this functionality, not those inherent in
either environment.
When a message uses end-to-end security mechanisms such as [PGP] or
S/MIME [SMIME], servers MUST be careful not to accidently destroy the
integrity of the protected content (for example, by altering any text
within the region covered by a signature while mapping between MMS
and email). [Mime-Sec-gw] discusses issues with use of such
mechanisms in gateways.
Some MMS features contain inherently more risk than others, including
reply charging and sender address hiding. Support for these
mechanisms is not included in this document.
4. IANA Considerations
IANA has added "MMS" as one of the "WITH protocol types" under its
"MAIL Parameters" registry. The description is "Multimedia Messaging
Service"; the reference is to this document.
5. Acknowledgements
A number of people contributed to this document, especially the
members of the IETF Lemonade working group, including Greg Vaudreuil.
John Klensin did a very thorough and helpful review. Greg White
caught a large number of nits. Ted Hardie was very helpful. Alexey
Melnikov and Chris Newman sent very useful and detailed comments.
6. Normative References
[DSN-Msg] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464,
January 2003.
[DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[Hdr-Enc] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text ", RFC 2047, November 1996.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[IDN] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[Msg-Fmt] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[Report-Fmt] Vaudreuil, G., "The Multipart/Report Content Type for
the Reporting of Mail System Administrative Messages",
RFC 3462, January 2003.
[RESP] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[OMA] OMA specifications are available at the OMA web site
<http://www.openmobilealliance.org>.
[OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C
[3GPP2] 3GPP2 specifications are available at the 3GPP2 (Third
Generation Partnership Project 2) web site
<http://www.3gpp2.org>.
[3GPP] 3GPP specifications are available at the 3GPP (Third
Generation Partnership Project) web site
<http://www.3gpp.org>
[Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
"MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-
340
"Multimedia Messaging Service: Functional description;
Stage 2", TS 23.140 Release 5.
7. Informative References
[BINARY] Vaudreuil, G., "SMTP Service Extensions for
Transmission of Large and Binary MIME Messages", RFC
3030, December 2000.
[Deliver-By] Newman, D., "Deliver By SMTP Service Extension", RFC
2852, June 2000.
[Hdrs] Palme, J., "Common Internet Message Headers", RFC 2076,
February 1997.
[Mime-Sec-gw] Freed, N., "Gateways and MIME Security Multiparts", RFC
2480, January 1999.
[PGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
[SMIME] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[Submission] Gellens, R. and J. Klensin, "Message Submission", RFC
2476, December 1998.
[VPIM] Vaudreuil, G. and G. Parsons, "Voice Profile for
Internet Mail - version 2 (VPIMv2)", RFC 3801, June
2004.
[Overview] "Multimedia Messaging Services (MMS) Overview",
X.S0016-000
[Stage_1] "Multimedia Messaging Services (MMS); Stage 1",
Requirements, October 2002, S.R0064-0.
[Stage_2] "Multimedia Messaging Service (MMS); Stage 2",
Functional Specification, April 2003, X.S0016-200.
"Multimedia Messaging Service; Media formats and
codecs", TS26.140Release 5.
Author’s Address
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
EMail: randy@qualcomm.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).