idnits 2.17.1 draft-ietf-lemonade-mms-mapping-03.txt: -(1362): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1416. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1402), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 62 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2005) is 6951 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BINARY' is defined on line 1296, but no explicit reference was found in the text == Unused Reference: 'Codes' is defined on line 1299, but no explicit reference was found in the text == Unused Reference: 'Hdrs' is defined on line 1308, but no explicit reference was found in the text == Unused Reference: 'Formats' is defined on line 1353, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2298 (ref. 'MDN') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2822 (ref. 'Msg-Fmt') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3462 (ref. 'Report-Fmt') (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 1893 (ref. 'RESP') (Obsoleted by RFC 3463) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'Auth') (Obsoleted by RFC 4954) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSec') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. 'SMIME') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2476 (ref. 'Submission') (Obsoleted by RFC 4409) -- Obsolete informational reference (is this intentional?): RFC 2421 (ref. 'VPIM') (Obsoleted by RFC 3801) Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Mapping Between MMS and Internet Mail R. Gellens 3 Document: draft-ietf-lemonade-mms-mapping-03.txt Qualcomm 4 Expires: October 2005 April 2005 6 Mapping Between the Multimedia Messaging Service (MMS) 7 and Internet Mail 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed 13 and any of which I become aware will be disclosed, in accordance 14 with RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, I accept the provisions of 17 Section 3 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt The list of 31 Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 The cellular telephone industry has defined a service known as the 41 Multimedia Messaging Service (MMS). This service uses formats and 42 protocols which are similar to, but differ in key ways from those 43 used in Internet mail. 45 Gellens [Page 1] Expires October 2005 46 This document specifies how to exchange messages between these two 47 services, including mapping information elements as used in MMS 48 X-Mms-* headers as well as delivery and disposition reports, to and 49 from that used in ESMTP and Internet message headers. 51 Gellens [Page 2] Expires October 2005 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2 Conventions Used in this Document . . . . . . . . . . . . 4 57 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 59 1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 60 2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6 61 2.1 Mapping Specification . . . . . . . . . . . . . . . . . . 6 62 2.1.1 MMS to Internet Mail . . . . . . . . . . . . . . . . . 6 63 2.1.2 Internet Mail to MMS . . . . . . . . . . . . . . . . 7 64 2.1.3 MMS Information Element Mappings . . . . . . . . . . . 7 65 2.1.3.1 Table 1: MM3 Mappings . . . . . . . . . . . . . . 8 66 2.1.3.2 Conversion of messages from MMS to Internet format 10 67 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet 14 68 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet 14 69 2.1.3.3 Conversion of messages from Internet to MMS format 17 70 2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 18 71 2.1.4 Report Generation and Conversion . . . . . . . . . . 20 72 2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 20 73 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Inte 21 74 2.1.4.2 Delivery Report Mapping from Internet Message to M 22 75 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Me 23 76 2.1.4.3 Read Report Mapping from MMS to Internet Message . 24 77 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet 25 78 2.1.4.4 Disposition Report Mapping from Internet Message t 26 79 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet 26 80 2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . . 27 81 3 Security Considerations . . . . . . . . . . . . . . . . . . . 27 82 4 Normative References . . . . . . . . . . . . . . . . . . . . . 29 83 5 Informative References . . . . . . . . . . . . . . . . . . . 30 84 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 85 Intellectual Property Statement . . . . . . . . . . . . . . . 31 86 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32 87 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 1 Introduction 91 1.1 Scope 93 This document describes how to exchange messages with Internet mail 94 systems. This includes translation between MMS (as defined by 95 3GPP/3GPP2/OMA) and Internet Mail messages using Extended Simple 96 Mail Transfer Protocol [SMTP] and Internet message format [Msg-Fmt]. 97 This also includes translation between delivery and disposition 98 reports as used in MMS and in Internet mail ([DSN-Msg] and [MDN]). 100 Gellens [Page 3] Expires October 2005 101 The MMS architecture [Stage_2] and specifications [Stage_3] refer to 102 interfaces as reference points named MMx. For example, MM1 is the 103 client-server interface, MM4 is the server-server interface, and MM3 104 is an interface to "external" or non-MMS systems. The specification 105 in this document can be used for message exchange between any system 106 which uses Internet Message formats and protocols and an MMS system; 107 from the perspective of the MMS system, reference point MM3 is used. 109 This document includes support for voice messages specified by the 110 Voice Profile for Internet Mail [VPIM]. The VPIM specification 111 allows voice messages to be exchanged between voice mail systems 112 using Internet mail format [Msg-Fmt] and transported via Extended 113 Simple Mail Transfer Protocol [SMTP]. Thus, the MMS MM3 interface 114 supports the ability to exchange voice messages between an MMS 115 system and a voice mail system. Note that such use is distinct from 116 voice media being part of a user-composed multimedia message. 118 Note that MM3 can also be used for interworking with "external" 119 (non-MMS) systems other than Internet mail, such as Short Messaging 120 Service (SMS) and access to external mail stores (such as a voice 121 mail system). This specification does not address these other uses 122 or sub-interfaces of MM3; it is only concerned with Internet mail 123 interworking and specifically exchange of messages. 125 All MM3 Stage 2 [Stage_2] functions are supported except for reply 126 charging and sender address hiding, which may be addressed in future 127 extensions. 129 1.2 Conventions Used in this Document 131 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 132 NOT", and "MAY" in this document are to be interpreted as described 133 in "Key words for use in RFCs to Indicate Requirement Levels" 134 [KEYWORDS]. 136 Note that in the text of this document, a distinction is made 137 between use of "SMTP" or "Simple Mail Transfer Protocol", and 138 "ESMTP" or "Extended Simple Mail Transfer Protocol": when the term 139 "ESMTP" or "Extended" is used, it indicates use of extended features 140 of SMTP; that is, those beyond the facilities of RFC 821. (These 141 extended facilities may be in RFC 2821 or in other RFCs, as 142 indicated by the specific RFC reference used; note that the name of 143 the RFC 2821 reference is "SMTP" because that is the official title 144 of the RFC.) 146 Gellens [Page 4] Expires October 2005 147 1.3 Definitions 149 --------------------|---------------------------------------------- 150 Anonymous Remailer |A service which accepts messages and resends 151 |them to their intended recipient, masking 152 |information about the original sender. 153 --------------------|---------------------------------------------- 154 Body |The portion of an SMTP message's Content 155 |following the Header (that is, following the 156 |first blank line). The Body may contain 157 |structured parts and sub-parts, each of which 158 |may have their own Header and Body. The Body 159 |contains information intended for the message 160 |recipient (human or software). 161 --------------------|---------------------------------------------- 162 Content |The portion of an SMTP message that is 163 |delivered. The Content consists of a Header 164 |and a Body. 165 --------------------|---------------------------------------------- 166 Disposition Report |Feedback information to an originator User 167 |Agent by a recipient User Agent about 168 Message Disposition |handling of an original message. This may 169 Notification |include notification that the message was or 170 |was not read, was deleted unread, etc. 171 --------------------|---------------------------------------------- 172 Envelope |The portion of an SMTP message not included in 173 |the Content; that is, not in the Header nor in 174 |the Body. Envelope information only exists 175 |while the message is in transit, and contains 176 |information used by SMTP agents (MTAs). 177 --------------------|---------------------------------------------- 178 Header |The first part of an SMTP message's Content. 179 |The Header is separated from the Body by a 180 |blank line. The Header consists of Fields 181 |(such as "To:"), also known as Header Fields 182 |or Headers. The message Header contains 183 |information used by User Agents. 184 --------------------|---------------------------------------------- 185 Gateway Function |An agent which acts as both MMSC and MTA 186 |and/or MSA. 187 --------------------|---------------------------------------------- 188 User Agent |An MMS or Email user agent 189 --------------------|---------------------------------------------- 191 Gellens [Page 5] Expires October 2005 192 1.4 Abbreviations 194 --------|---------------------------------------------------------- 195 ESMTP |Extended Simple Mail Transfer Protocol. The use of 196 |features and capabilities added to SMTP since RFC 821. 197 --------|---------------------------------------------------------- 198 MSA |Message Submission Agent. A server which accepts messages 199 |from User Agents and processes them; either delivering 200 |them locally or relaying to an MTA. 201 --------|---------------------------------------------------------- 202 MTA |Mail Transfer Agent. A server which implements [SMTP]. 203 --------|---------------------------------------------------------- 205 1.5 Assumptions 207 It is assumed that the reader is already familiar with the contents 208 of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 209 (requirements) [Stage_1] and Stage 2 (architecture and abstract 210 messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] 211 documents. It is also assumed that the reader is familiar with 212 Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt]. 214 2 Mapping Between MMS and Internet Mail 216 This section defines the interworking between MMS Relay/Servers and 217 External Servers using native ESMTP. That is, information elements 218 are exchanged using standard Internet Message [Msg-Fmt] header 219 fields and standard [SMTP] elements. 221 SMTP and Internet mail extensions are used for features such as 222 delivery reports, message expiration, discovery of server support 223 for optional features, etc. 225 2.1 Mapping Specification 227 2.1.1 MMS to Internet Mail 229 When sending a message to an Internet mail system the MMS 230 Relay/Server MUST convert the MM if required, and MUST comply with 231 the requirements of [SMTP] (for example, use of a null return-path 232 for automatically-generated messages). 234 The MMS Relay/Server SHOULD use the information elements associated 235 with the MM to define the control information (Internet Message 236 header fields and ESMTP values) needed for the transfer protocol. 238 Gellens [Page 6] Expires October 2005 239 Section 2.1.3 lists the mappings between X-Mms-* headers and 240 Internet Message header fields and ESMTP values. 242 Delivery and read report MMs SHOULD be converted to standard 243 Internet Message report format (multipart/report). In addition to 244 converting Internet Message reports, the MMS Relay/Server MUST 245 generate delivery and read report MMs for received messages as 246 appropriate. See section 2.1.4 for more information. 248 2.1.2 Internet Mail to MMS 250 When receiving a message from an Internet mail system the MMS 251 Relay/Server MAY convert incoming messages to the MM format used 252 within the receiving system. 254 The MMS Relay/Server MAY convert control information received from 255 the Internet mail server into appropriate information elements of an 256 MM. 258 Section 2.1.3 lists the mappings between X-Mms-* headers and 259 Internet Message header fields and ESMTP values. 261 Standard Internet Message report format (multipart/report) messages 262 MAY be converted to delivery or read report MMs, as appropriate. In 263 addition to converting report MMs, the MMS Relay/Server MUST 264 generate standard Internet Message delivery and disposition reports 265 for received Internet messages as appropriate. See section 2.1.4 266 for more information. 268 Gellens [Page 7] Expires October 2005 269 2.1.3 MMS Information Element Mappings 271 The mappings between MMS elements and ESMTP/Internet Message 272 elements (either [SMTP] parameters, [Msg-Fmt] headers, or both) are 273 summarized in the table below, and detailed in subsequent sections. 274 The "MMS Headers" are from [OMA-MMS]. Note that only information 275 elements which need to be mapped are listed. [Msg-Fmt] headers not 276 listed here SHOULD be passed unaltered 278 2.1.3.1 Table 1: MM3 Mappings 280 =================|=================|================|============== 281 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 282 =================|=================|================|============== 283 3GPP MMS Version |N/A |N/A |X-Mms-Version: 284 | | | 285 _________________|_________________|________________|______________ 286 Message Type |N/A |N/A |X-Mms-Message- 287 (of PDU) | | | Type: 288 _________________|_________________|________________|______________ 289 Transaction ID |N/A |N/A |X-Mms-Transact 290 | | | ion-Id: 291 _________________|_________________|________________|______________ 292 Message ID |ENVID [DSN-SMTP] |Message-ID: |X-Mms-Message- 293 | | | Id: 294 | | |Message-ID: 295 _________________|_________________|________________|______________ 296 Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc: 297 address(es) |address(es) |omitted (Bcc) | 298 _________________|_________________|________________|______________ 299 Sender's address |MAIL FROM |From: (MAY set |From: 300 |address if |to locally-gen- | 301 |user-originated; |erated value | 302 |MUST set MAIL |to hide sender | 303 |FROM to null |identity) | 304 |("<>") for all | | 305 |automatically- | | 306 |generated MMs | | 307 _________________|_________________|________________|______________ 308 Content type |N/A |Content-Type: |Content-type: 309 | | | 310 | |For voice mes- | 311 | |sages compliant | 312 | |to [VPIM], see | 313 | |Note 2 | 314 =================|=================|================|============== 316 Gellens [Page 8] Expires October 2005 317 =================|=================|================|============== 318 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 319 =================|=================|================|============== 320 Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- 321 |MUST set MAIL | dence: bulk' | Class: 322 |FROM to null |on class=auto | 323 |("<>"). | | 324 _________________|_________________|________________|______________ 325 Date and time |N/A |Date: |Date: 326 of submission | | | 327 _________________|_________________|________________|______________ 328 Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry: 329 |[Deliver-By] | | 330 _________________|_________________|________________|______________ 331 Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery 332 ery time |sion; not relay) | | -Time: 333 _________________|_________________|________________|______________ 334 Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery 335 request |SHOULD also | | -Report: 336 |specify recip- | | 337 |ient address as | | 338 |ORCPT; SHOULD | | 339 |also specify | | 340 |ENVID | | 341 _________________|_________________|________________|______________ 342 Importance (a/k/a|N/A |Importance: |X-Mms- 343 "priority") | |X-Priority: | Priority: 344 | | | 345 | | | 346 _________________|_________________|________________|______________ 347 Sender visib- |N/A |N/A |X-Mms-Sender- 348 ility | | | Visibility: 349 _________________|_________________|________________|______________ 350 Read reply |N/A |Disposition- |X-Mms-Read- 351 request | | Notification | Reply: 352 | | -To: [MDN] | 353 _________________|_________________|________________|______________ 354 Reply-charging |(not currently |(not currently |X-Mms-Reply- 355 permission |supported) |supported) | Charging: 356 _________________|_________________|________________|______________ 357 Reply-charging |(not currently |(not currently |X-Mms-Reply- 358 permission |supported) |supported) | Charging- 359 deadline | | | Deadline: 360 _________________|_________________|________________|______________ 361 Reply-charging |(not currently |(not currently |X-Mms-Reply- 362 permission |supported) |supported) | Charging- 363 limitation | | | Size: 364 =================|=================|================|============== 366 Gellens [Page 9] Expires October 2005 367 =================|=================|================|============== 368 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 369 =================|=================|================|============== 370 Reply-charging |(not currently |(not currently |X-Mms-Reply- 371 usage request |supported) |supported) | Charging- 372 | | | Id: 373 _________________|_________________|________________|______________ 374 Reply-charging |(not currently |(not currently |X-Mms-Reply- 375 usage reference |supported) |supported) | Charging: 376 _________________|_________________|________________|______________ 377 Subject |N/A |Subject: |Subject: 378 _________________|_________________|________________|______________ 379 Forward counter |N/A |Resent-Count: |(Not sup- 380 | | |ported) 381 _________________|_________________|________________|______________ 382 Previously-sent- |N/A |Resent-From: |X-Mms-Previous 383 by | | | ly-Sent-By: 384 _________________|_________________|________________|______________ 385 Previously-sent- |N/A |Resent-Date: |X-Mms- 386 date and-time | | | Previously- 387 | | | Sent-Date: 388 _________________|_________________|________________|______________ 389 Hop/host trace |N/A |Received: |(Not sup- 390 | | |ported) 391 _________________|_________________|________________|______________ 392 Sensitivity |N/A |Sensitivity: see|N/A 393 | |Note 1 | 394 _________________|_________________|________________|______________ 395 Content |N/A | | 396 =================|=================|================|============== 398 Note 1: The [VPIM] 'Sensitivity' header element indicates the 399 privacy requested by the message originator (values are "personal" 400 or "private"); a message recipient MUST NOT forward a message with a 401 'Sensitivity' header. 403 Note 2: A MIME-Version header with a comment of "Voice 2.0" 404 indicates that the voice message conforms to [VPIM]. 406 2.1.3.2 Conversion of messages from MMS to Internet format 408 3GPP MMS Version 410 The 'X-Mms-Version:' header, if present, SHOULD be removed. 412 Gellens [Page 10] Expires October 2005 413 Message Type (of PDU) 415 The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. 417 Transaction ID 419 The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. 421 Message ID 423 An 'X-Mms-Message-Id:' header, if present, SHOULD be retained. 425 The 'Message-Id:' header MUST be retained. If not present it MUST 426 be created, with a unique value. If an 'X-Mms-Message-Id:' header 427 is present and a 'Message-Id:' header is not, the value of the 428 'X-Mms-Message-Id:' header MAY be used in creating the 'Message-Id:' 429 header. 431 The message ID SHOULD be transmitted in the ESMTP envelope as the 432 ENVID parameter, as specified in [DSN-SMTP]. 434 Recipient(s) address 436 The address of each recipient MUST be transmitted in the SMTP 437 envelope as a RCPT TO value. All disclosed recipients SHOULD also 438 appear in a 'To:' or 'Cc:' header. At least one 'To:' or 'Cc:' 439 header MUST be present. If all recipients are undisclosed, a 'To:' 440 header MAY be created that contains a comment, for example 'To: 441 (undisclosed recipients)'. The 'To:' header SHOULD NOT appear more 442 than once. The 'Cc:' header SHOULD NOT appear more than once. 444 Each recipient address MUST obey the length restrictions per [SMTP]. 446 Current Internet message format requires that only 7-bit US-ASCII 447 characters be present in addresses. Other characters (for example, 448 non-7-bit characters in a phrase part of an address header) MUST be 449 encoded according to [Hdr-Enc]. Note that it would be possible to 450 define an SMTP extension to permit transmission of unencoded 8-bit 451 characters, but in the absence of such an extension [Hdr-Enc] MUST 452 be used. 454 Sender address 456 The address of the message sender SHOULD appear in the 'From:' 457 header, unless address hiding has been requested. If address hiding 458 has been requested, the 'From:' header MAY contain a comment to this 459 effect, for example, 'From: (anonymous sender)'. 461 Gellens [Page 11] Expires October 2005 462 The address of the message sender for all user-generated messages 463 ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the SMTP 464 envelope as the MAIL FROM value unless address hiding has been 465 requested and the receiving server is not known and trusted to 466 support address hiding. 468 The 'From:' header and the MAIL FROM value MAY be set to a 469 locally-generated value to hide the sender identity in anonymous 470 messages when the receiving system does not support anonymous 471 messages. Locally generated addresses MAY be internally mapped to 472 the actual address to allow replies to anonymous messages, but such 473 mapping is beyond the scope of this specification, as is a mechanism 474 for discovering and requesting support for anonymous messages. 476 Because of the risk of mail loops, it is critical that the MAIL FROM 477 be set to null ("<>") for all automatically-generated MMs (such as 478 'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to 479 null for all automatically-generated messages. This includes 480 reports, "out-of-office" replies, etc. 482 Current Internet message format requires that only 7-bit US-ASCII 483 characters be present in addresses. Other characters (for example, 484 non-7-bit characters in a phrase part of an address header) MUST be 485 encoded according to [Hdr-Enc]. Note that it would be possible to 486 define an SMTP extension to permit transmission of unencoded 8-bit 487 characters, but in the absence of such an extension [Hdr-Enc] MUST 488 be used. 490 The sender address MUST obey the length restrictions of [SMTP]. 492 Content type 494 The 'Content-Type:' header SHOULD be preserved. Content types not 495 in widespread use in the Internet MAY be converted into those that 496 are, when such conversion can be done without significant loss of 497 content. For example, SMIL messages MAY be converted into 498 widely-supported multipart/related with multipart/html. When such 499 conversion is done, the 'Content-Type:' header MUST be updated if it 500 is no longer correct. 502 Message class 504 The 'X-Mms-Message-Class:' header MAY be retained. A 'Precedence: 505 bulk' header MAY be inserted for class=auto or class=advertisement. 506 See 'Sender Address' above. (Class=personal and class=informational 507 do not require special handling.) 509 Gellens [Page 12] Expires October 2005 510 Time of Expiry 512 The 'X-Mms-Expiry:' header, if present, SHOULD be removed. 514 The remaining time until the message is considered expired SHOULD be 515 transmitted in the ESMTP envelope by using the DELIVER-BY extension, 516 as specified in [Deliver-By]. 518 Note that the ESMTP DELIVER-BY extension carries time remaining 519 until expiration; each server decrements the value by the amount of 520 time it has possessed the message. The 'X-Mms-Expiry:' header may 521 contain either the absolute time at which the message is considered 522 expired or the relative time until the message is considered 523 expired. 525 Earliest delivery time 527 The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed. 529 Future delivery is a message submission, not message relay feature. 531 Delivery report request 533 Requests for delivery status notifications (DSNs) SHOULD be 534 transmitted in the ESMTP envelope by using the DSN extension as 535 specified in [DSN-SMTP] to request "success" or "none" notification 536 (depending on the value of the 'X-Mms-Delivery-Report' header). 537 When the NOTIFY extension is used, the unaltered recipient address 538 SHOULD be transmitted as the ORCPT value, and the original message 539 ID SHOULD be transmitted as the ENVID value. 541 The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed. 543 Importance 545 The message sender's importance value (also called "priority", 546 although this can be confused with class-of-service values) SHOULD 547 be transmitted using an 'Importance:' header (although currently not 548 all Internet mail clients support this header). 550 An 'X-Priority:' header MAY be used in addition. Although not 551 standardized, most email applications support the 'X-Priority:' 552 header, and use an 'X-Priority' value of 3 for messages with 553 "normal" priority. More important messages have lower values and 554 less important message have higher values. In most cases, urgent 555 messages have an X-Priority value of 1. 557 Gellens [Page 13] Expires October 2005 558 Suggested mappings: 560 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message) 562 ---------------------------|------------------ 563 'X-Mms-Priority: High' |'Importance: High' 564 ---------------------------|------------------ 565 'X-Mms-Priority: Normal' |[omit] 566 ---------------------------|------------------ 567 'X-Mms-Priority: Low' |'Importance: Low' 568 ---------------------------|------------------ 570 Normal priority messages should omit the 'Importance:' header. 572 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet Message) 574 ---------------------------|---------------------- 575 'X-Mms-Priority: High' |'X-Priority: 2 (high)' 576 ---------------------------|---------------------- 577 'X-Mms-Priority: Normal |[omit] 578 ---------------------------|---------------------- 579 'X-Mms-Priority: Low |'X-Priority: 4 (low)' 580 ---------------------------|---------------------- 582 Normal priority messages SHOULD omit the 'X-Priority:' header. 584 The 'X-Mms-Priority:' header, if present, SHOULD be removed. 586 Sender visibility 588 Support for sender address hiding is not included in this version of 589 the mapping document. 591 The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be 592 removed. 594 Read reply request 596 A request for a read reply SHOULD be transmitted using a 597 'Disposition-Notification-To:' header as specified in [MDN]. 599 The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed. 601 Reply-charging 603 Reply charging permission and acceptance are complex issues 604 requiring both user agent and server support. Misapplied reply 605 charging may cause incorrect billing. Until the security issues 606 have been properly addressed, reply charging SHOULD NOT be honored 608 Gellens [Page 14] Expires October 2005 609 when using this interface. 611 The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 612 'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers 613 MAY be removed. Messages containing a reply-charging usage request 614 ('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or 615 'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be 616 rejected. 618 Subject 620 The 'Subject:' header MUST be preserved. Current Internet message 621 format requires that only 7-bit US-ASCII characters be present. 622 Other characters must be encoded according to [Hdr-Enc]. Note that 623 it would be possible to define an SMTP extension to permit 624 transmission of unencoded 8-bit characters, but in the absence of 625 such an extension [Hdr-Enc] must be used. 627 Resending/Forwarding 629 In MMS a message may be resent or forwarded, the difference being 630 that if the message has been downloaded then sending it to another 631 address is considered forwarding, while sending a message that has 632 not been downloaded is considered to be resending. 634 In Internet mail there are two primary ways of sending a previously 635 received message to a new recipient: forwarding and resending. 636 Forwarding is when a user creates a new message containing the 637 original message, either simply embedded within the text, or 638 delineated. Embedded messages generally have each original line 639 preceded by a quote symbol ('>'), surround the original text with a 640 preceding and trailing line which starts with hyphens as per 641 [Msg-Encap], such as '--- begin forwarded text' and '--- end 642 forwarded text', or encapsulate the original message as a 643 'message/rfc822' content type, perhaps within a 'multipart/mixed' 644 message. (This last method offers more robust delineation.) 645 Resending is when the original message is unaltered except for the 646 addition of 'Resent-' headers to explain the resending to the new 647 recipient. 649 A message may be resent more than once; each time new 'Resent-' 650 headers SHOULD be added at the top of the message. Thus, if more 651 than one series of 'Resent-' headers are present, the original 652 series is the last; the most recent is the first. 654 Forward counter 656 Gellens [Page 15] Expires October 2005 657 The 'Resent-Count:' header MAY be used to track the number of times 658 the message has been resent. Note that loop control is often done 659 by counting 'Received' headers, which are more general than 660 'Resent-' headers. 662 Previously-sent Information 664 A 'Resent-From:' header MAY be added to indicate the address of the 665 user who directed the message to be resent. 667 A 'Resent-Date:' header SHOULD be added to indicate the time and 668 date that the message was resent. 670 Any 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date' 671 headers, if present, SHOULD be removed. The information contained 672 in them SHOULD be translated into 'From:', 'Resent-To:', 673 'Resent-From:', 'Resent-Date:', and 'Resent-Count:' headers. The 674 original sender of the message SHOULD appear in the 'From:' header; 675 the original recipient(s) SHOULD appear in the 'To:' header; the 676 time and date the message was originally sent SHOULD appear in the 677 'Date:' header. The most recent sender SHOULD appear in the 678 top-most 'Resent-From:' header; the most recent recipient(s) SHOULD 679 appear in the top-most 'Resent-To:' header; the time and date the 680 message was most recently sent SHOULD appear in the top-most 681 'Resent-Date:' header. 683 'Received:' Headers 685 Each system that processes a message SHOULD add a 'Received:' header 686 as per [SMTP]. A message MAY be rejected if the number of 687 'Received:' headers exceeds a locally-defined maximum, which MUST 688 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 690 Privacy 692 Note that MMS systems do not currently support the 'Privacy' header 693 field as described by [VPIM]. 695 Content 697 The message content appears in the message body. Note that Internet 698 message format requires that line-endings be encoded as CR LF, thus 699 charset encodings that do not have this property cannot be used in 700 text/* body parts. (They MAY be used in other body parts, but only 701 when they are suitable encoded or when binary transmission has been 702 negotiated.) In particular, MMS allows UTF-16, while Internet 703 message format does not. UTF-16 encoding MUST be translated to 704 UTF-8 or another charset and encoding which is suitable for use in 705 Internet message format/protocols. 707 Gellens [Page 16] Expires October 2005 708 2.1.3.3 Conversion of messages from Internet to MMS format 710 3GPP MMS Version 712 An 'X-Mms-Mms-Version:' header SHOULD be added. 714 Message Type (of PDU) 716 An 'X-Mms-Message-Type:' header SHOULD be used in accordance with 717 the specific MMS interface (e.g., MM1, MM4). 719 Transaction ID 721 An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with 722 the specific MMS interface (e.g., MM1, MM4). 724 Message ID 726 The 'Message-Id:' header MUST be retained. If not present it MUST 727 be created, with a unique value. If the 'Message-Id:' header does 728 not exist, but the SMTP envelop contains an ENVID value (as 729 specified in [DSN-SMTP]), it MAY be used to construct the value. 731 Recipient(s) address 733 'To:' and 'Cc:' headers MUST be retained. 735 Each recipient contained in the SMTP envelope (RCPT TO values) MUST 736 be considered a recipient of the message. Recipients who appear in 737 address headers but not the SMTP envelope MUST be ignored. 738 Recipients who appear in the [SMTP] envelope but do not appear in 739 headers are considered "blind" (Bcc) recipients; such recipients 740 MUST NOT be added to message headers (including address and trace 741 headers) unless there is only one recipient total. 743 Sender address 745 The 'From:' header MUST be retained. 747 Content type 749 The complete 'Content-Type:' header (including any parameters) 750 SHOULD be preserved. 752 Message class 754 Gellens [Page 17] Expires October 2005 755 An X-Mms-Message-Class: personal' header SHOULD be created for all 756 received messages with a non-null return path (MAIL FROM value in 757 the SMTP envelope). An X-Mms-Message-Class: auto' header MAY be 758 created for messages with a null return path. 760 Time of Expiry 762 An 'x-Mms-Expiry:' header SHOULD be created if the message contains 763 a relative time to expiration in the DELIVER-BY extension, as 764 specified in [Deliver-By]. 766 Earliest delivery time 768 An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. If a 769 message arrives via ESMTP relay containing an earliest time of 770 delivery in the AFTER extension, it MAY be rejected. If a message 771 is submitted via Message Submission [Submission] containing an 772 earliest time of delivery in the AFTER extension, it MUST either be 773 retained until the delivery time arrives, or it may be immediately 774 rejected. It MUST NOT be delivered or further relayed prior to the 775 delivery time. 777 Delivery report request 779 An 'X-Mms-Delivery-Report:' header SHOULD be created for messages 780 which request 'success' or 'none' delivery status notification by 781 use of the DSN extension as specified in [DSN-SMTP]. Requests for 782 'delay' notifications or non-default actions, such as that only the 783 message headers should be returned, cannot be mapped onto MMS 784 headers and thus SHOULD be ignored. 786 Priority 788 An 'X-Priority:' or 'Importance:' header, if present, SHOULD be 789 replaced with an 'X-Mms-Priority:' header. Suggested mappings: 791 2.1.3.3.1 Table 4: Priority Mappings (Internet Message to MMS) 793 -------------------------------|---------------------- 794 'X-Priority: 1 (highest)' |'X-Mms-Priority: High' 795 -------------------------------|---------------------- 796 'X-Priority: 2 (high)' |'X-Mms-Priority: High' 797 -------------------------------|---------------------- 798 'Importance: High' |'X-Mms-Priority: High' 799 -------------------------------|---------------------- 800 'X-Priority: 3 (normal)' | [omitted] 801 -------------------------------|---------------------- 802 'Importance: Normal' | [omitted] 803 -------------------------------|---------------------- 805 Gellens [Page 18] Expires October 2005 806 'X-Priority: 4 (low)' |'X-Mms-Priority: Low' 807 -------------------------------|---------------------- 808 'Importance: Low' |'X-Mms-Priority: Low' 809 -------------------------------|---------------------- 810 'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low' 811 -------------------------------|---------------------- 813 Normal priority messages SHOULD omit the 'X-Mms-Priority:' header. 815 Sender visibility 817 Support for sender address hiding is not currently supported. 819 Read reply request 821 A request for a read reply contained in a 822 'Disposition-Notification-To:' header as specified in [MDN] SHOULD 823 be replaced with an 'X-Mms-Read-Reply:' header. 825 Subject 827 The 'Subject:' header MUST be preserved. 829 Resending/Forwarding 831 One or more sets of 'Resent-' headers, if present, SHOULD be mapped 832 to 'To:', 'From:', 'Date:', and 'X-Mms-Previously-Sent-' headers. 834 'Received:' Headers 836 Each system that processes a message SHOULD add a 'Received:' header 837 as per [SMTP]. A message MAY be rejected if the number of 838 'Received:' headers exceeds a locally-defined maximum, which MUST 839 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 841 Sensitivity 843 The 'Sensitivity:' header field (value = "personal" or "private") 844 [VPIM] indicates the desire of a voice message originator to send 845 the message contents to the original recipient list with assurance 846 that the message will not be forwarded further by either the 847 messaging system or the actual message recipient(s). Since 848 sensitivity is not an MMS feature, any messages which contain a 849 'Sensitivity:' header SHOULD NOT be sent to an MMS system. An 850 appropriate extended error response code [RESP] SHOULD be used in 851 the associated negative delivery status report. 853 Gellens [Page 19] Expires October 2005 854 Content 856 The message content appears in the message body. 858 2.1.4 Report Generation and Conversion 860 Internet Message systems use the multipart/report MIME type for 861 delivery and disposition reports (often called "read reports") as 862 specified in [Report-Fmt]. This format is a two- or three-part MIME 863 message; one part is a structured format describing the event being 864 reported in an easy-to-parse format. Specific reports have a format 865 which is built on [Report-Fmt]. Delivery reports are specified in 866 [DSN-Msg]. Message disposition reports, which include read reports, 867 are specified in [MDN]. 869 By contrast, MMS reports are plain text, with no defined structure 870 specified. This makes it difficult to convert from an MMS report to 871 a standard Internet report. 873 An MMS Relay/Server supporting Internet Message exchange using MM3 874 MUST convert reports received from one side (MMS or Internet mail) 875 destined for the other. In addition, reports MUST be generated as 876 appropriate for messages received from either side of the MM3 877 interface. For example, if an MM to be sent via MM3 is not 878 deliverable, a delivery status MM shall be generated. Likewise, if 879 an Internet message is received via MM3 that cannot be further 880 relayed or delivered, a delivery status report [DSN-Msg] MUST be 881 generated. 883 When creating delivery or disposition reports from MMS reports, the 884 MMS report should be parsed to determine the reported event and 885 time, status, and the headers of the referenced (original) message. 886 These elements, once determined, are used to populate the subparts 887 of the delivery or disposition report. The first subpart is of type 888 text/plain, and contains a human-readable explanation of the event. 889 This text may include a statement that the report was synthesized 890 based on an MMS report. The second subpart is of type 891 report/delivery-status (for delivery reports) or 892 report/disposition-notification (for disposition reports). This 893 second part contains a structured itemization of the event. The 894 third subpart is of type message/rfc822 and includes the headers and 895 optionally the body of the referenced (original) message. 897 2.1.4.1 Delivery Report Mapping from MMS to Internet Message 899 Gellens [Page 20] Expires October 2005 900 The following table maps information elements from MMS delivery 901 reports to the format specified in [DSN-Msg]. 903 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message) 905 ======================|============|=================================== 906 Information Element |MMS Delivery|[DSN-Msg] Element 907 |Report Elem | 908 ======================|============|=================================== 909 ID of message whose |Message-Id: |'Original-Envelope-ID' field of 910 delivery status is | |per-message fields (use value of 911 being reported | |ENVID from ESMTP envelope if avail- 912 | |able, 'Message-ID:' otherwise). 913 ----------------------|------------|----------------------------------- 914 Recipient address of |From: |'Final-Recipient' field of the 915 the original message | |per-recipient section 916 (object of delivery | | 917 report) | | 918 ----------------------|------------|----------------------------------- 919 Destination address of|To: |'To:' header field value of top- 920 report | |level. 921 | | 922 | |Value taken from [SMTP] envelope 923 | |return-path of message being 924 | |reported, not its 'From:' header 925 | |field. 926 ----------------------|------------|----------------------------------- 927 Date and time the |Date: |'Date:' header field value of top- 928 message was handled | |level 929 ======================|============|=================================== 931 Gellens [Page 21] Expires October 2005 932 ======================|============|=================================== 933 Information Element |MMS Delivery|[DSN-Msg] Element 934 |Report Elem | 935 ======================|============|===================================Delivery status of |X-Mms- |Action and Status fields of 936 original message | Status: |per-recipient section. 937 | | 938 | |The 'Action' field indicates if the 939 | |message was delivered. 940 | | 941 | |For failed delivery an appropriate 942 | |'Status' value shall be included 943 | |per [DSN-Msg]. 944 | | 945 | |The Action field is set to one of 946 | |the following values: 947 | | 948 | |* delivered (used for MMS status 949 | |values 'retrieved' and 'rejected', 950 | |depending on 'Status' code). 951 | | 952 | |* failed (used for MMS status 953 | |values 'expired' and 'unreachable') 954 | | 955 | |* delayed MAY be used for MMS 956 | |status value 'deferred' 957 | | 958 | |* relayed (used for MMS status 959 | |value 'indeterminate') 960 | | 961 | |* expanded (SHOULD NOT be used) 962 ----------------------|------------|----------------------------------- 963 Status Text | |Text in first part (human-readable 964 | |part) 965 ----------------------|------------|----------------------------------- 967 When an MMS Relay/Server generates a [DSN-Msg] in response to a 968 message received using [SMTP] on MM3: 970 * Top-level header field 'To:' SHOULD be the [SMTP] return-path of 971 the message whose status is being reported. 973 * Top-level header field 'From:' SHOULD be the address of the 974 recipient that the delivery-report concerns. 976 * The first part of the [DSN-Msg] SHOULD include the MM Status Text 977 field that would have been generated for an MM1 delivery-report. 979 Gellens [Page 22] Expires October 2005 980 2.1.4.2 Delivery Report Mapping from Internet Message to MMS 982 The following table maps information elements from a delivery report 983 as specified in [DSN-Msg] to the format of an MMS delivery report. 985 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS) 987 ===================|==================|================================ 988 Information Element|MMS Delivery |[DSN=Msg] Element 989 |Report Element | 990 ===================|==================|================================ 991 ID of the original |Message-Id: |'Original-Envelope-ID' field of 992 message (object of | |per-message fields. If not 993 delivery report) | |available, the 'Message-ID' 994 | |header field of the message 995 | |being reported, if included in 996 | |the third part, may be 997 | |substituted. 998 -------------------|------------------|-------------------------------- 999 Recipient address |From: |If available, the 'Original 1000 of the original | |-Recipient' field of the per- 1001 message (object of | |recipient section should be 1002 delivery report) | |used; otherwise the 'Final- 1003 | |Recipient' field of the per- 1004 | |recipient section is used 1005 -------------------|------------------|-------------------------------- 1006 Destination address|To: |'To:' header field value of 1007 of report | |top-level. 1008 | | 1009 | |Value taken from [SMTP] envelope 1010 | |return-path of message being 1011 | |reported, not its 'From:' header 1012 | |field. 1013 ===================|==================|=================================== 1015 Gellens [Page 23] Expires October 2005 1016 ===================|==================|================================ 1017 Information Element|MMS Delivery |[DSN=Msg] Element 1018 |Report Element | 1019 ===================|==================|================================ 1020 Date and time the |Date: |'Date:' header field value of 1021 message was handled| |top-level 1022 -------------------|------------------|-------------------------------- 1023 Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of 1024 original message | |per-recipient section 1025 |Set to one of the | 1026 |following values: | 1027 | | 1028 |'retrieved' (used | 1029 |for 'Action' value| 1030 |'delivered'). | 1031 | | 1032 |'unreachable' | 1033 |(used for 'Action'| 1034 |value 'failed') | 1035 | | 1036 |'forwarded' (used | 1037 |for 'Action' value| 1038 |'relayed') | 1039 | | 1040 |'deferred' MUST | 1041 |NOT be used | 1042 |(ignore DSNs with | 1043 |'Action' value | 1044 |'delayed') | 1045 -------------------|------------------|-------------------------------- 1046 Status Text | |Text in first part (human- 1047 | |readable part) 1048 ===================|==================|================================ 1050 Gellens [Page 24] Expires October 2005 1051 2.1.4.3 Read Report Mapping from MMS to Internet Message 1053 The following table maps information elements from MMS read reports 1054 to the format specified in [MDN]. 1056 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 1058 ======================|============|=================================== 1059 Information Element |MMS Delivery|[DSN-Msg] Element 1060 |Report Elem | 1061 ======================|============|=================================== 1062 ID of the original |Message-Id: |'Original-Envelope-ID' field (use 1063 message (object of | |value of ENVID from ESMTP envelope 1064 read report) | |if available, 'Message-ID:' 1065 | |otherwise). 1066 ----------------------|------------|----------------------------------- 1067 Recipient address of |From: |'Final-Recipient' field 1068 the original message | | 1069 ----------------------|------------|----------------------------------- 1070 Destination address of|To: |'To:' header field value of top- 1071 report | |level. 1072 | | 1073 | |Value taken from 'Disposition- 1074 | |Notification-To:' header field of 1075 | |message being reported, not its 1076 | |'From:' header field. 1077 ----------------------|------------|----------------------------------- 1078 Date and time the |Date: |'Date:' header field value of top- 1079 message was handled | |level 1080 ----------------------|------------|----------------------------------- 1081 Disposition of message|X-Mms-Read- |Disposition-field 1082 being reported | Status: | 1083 | |For MMS-Read-Status value 'read', 1084 | |use 'disposition-type' value 1085 | |'displayed'; for MMS-Read-Status 1086 | |value 'Deleted without being read', 1087 | |use 'disposition-type' value 1088 | |'deleted') 1089 ----------------------|------------|----------------------------------- 1090 Status Text | |Text in first part (human-readable 1091 | |part) 1092 ======================|============|=================================== 1094 When an MMS Relay/Server generates an [MDN] in response to a message 1095 received using ESMTP on MM3: 1097 Gellens [Page 25] Expires October 2005 1098 * Top-level header field 'To:' SHOULD be the value of the 1099 'Disposition-Notification-To:' header field of the message whose 1100 disposition is being reported . 1102 * Top-level header field 'From:' SHOULD be the address of the 1103 recipient that the read report concerns. 1105 2.1.4.4 Disposition Report Mapping from Internet Message to MMS 1107 The following table maps information elements from a disposition 1108 report as specified in [MDN] to the format of an MMS read report. 1110 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet Message to 1111 MMS) 1113 ===================|==================|================================ 1114 Information Element|MMS Read Report |[DSN=Msg] Element 1115 |Element | 1116 ===================|==================|================================ 1117 ID of the original |Message-Id: |'Original-Envelope-ID' field 1118 message (object of | | 1119 disposition report)| | 1120 -------------------|------------------|-------------------------------- 1121 Recipient address |From: |'Final-Recipient' field 1122 of the original | | 1123 message | | 1124 -------------------|------------------|-------------------------------- 1125 Destination address|To: |'To:' header field value of 1126 of report | |top-level. 1127 | | 1128 | |Value taken from 'Disposition- 1129 | |Notification-To:' header field 1130 | |of message being reported, not 1131 | |its 'From:' header field. 1132 -------------------|------------------|-------------------------------- 1133 Date and time the |Date: |'Date:' header field value of 1134 message was handled| |top-level 1135 ===================|==================|================================ 1137 Gellens [Page 26] Expires October 2005 1138 ===================|==================|================================ 1139 Information Element|MMS Read Report |[DSN=Msg] Element 1140 |Element | 1141 ===================|==================|================================Disposition of |X-Mms-Read-Status:|disposition-field 1142 message being | | 1143 reported |Set to one of the | 1144 |following values: | 1145 | | 1146 |'read' (used for | 1147 |disposition-type | 1148 |value 'displayed')| 1149 | | 1150 |'Deleted without | 1151 |being read' (used | 1152 |for disposition- | 1153 |types 'deleted', | 1154 |'denied' and | 1155 |'failed' when | 1156 |action-mode is | 1157 |'automatic- | 1158 |action') | 1159 -------------------|------------------|-------------------------------- 1160 Status Text | |Text in first part (human- 1161 | |readable part) 1162 ===================|==================|================================ 1164 2.1.5 Message Delivery 1166 Within Internet mail, when ESMTP is used and delivery reports are 1167 requested [DSN-SMTP], delivery is considered to be acceptance of a 1168 message by the final server, that is, the server closest to the 1169 recipient. When an MMS Relay/Server receives a message using ESMTP 1170 and a delivery report is requested, the MMS Relay/Server MAY 1171 consider the message delivered when it has been sent to the MMS User 1172 Agent. 1174 3 Security Considerations 1176 Data contained within messages should not be automatically trusted. 1177 Even within a carrier's network, and certainly within the Internet, 1178 various deliberate and accidental attacks or corruptions are 1179 possible. For example, routers may contain vulnerabilities which 1180 may be exploited, IP traffic may be intercepted and/or modified, 1181 etc. 1183 Gellens [Page 27] Expires October 2005 1184 The following messaging-related security threats can be identified: 1186 * Misidentification of message source. 1188 * Message interception (unauthorized disclosure of contents). 1190 * Unauthorized disclosure of message sender or recipient. 1192 * Message modification (by adversary). 1194 * Message replay. 1196 * Traffic analysis (determining who is communicating with whom). 1198 There are existing mechanisms which can be used to protect email 1199 traffic against some of these threats, such as: 1201 * Use of SSL/TLS (via [StartTLS]) to address disclosure and 1202 modification in transit between adjacent servers. 1204 * SMTP Authentication [Auth] to protect against misidentification of 1205 message source. 1207 * Use of end-to-end security mechanisms such as [PGP] or S/MIME 1208 [SMIME] to protect message contents. 1210 * Use of [IPSec] to protect against disclosure or modification in 1211 transit between servers. 1213 Use of these mechanisms is encouraged. When a message uses 1214 end-to-end security mechanisms such as [PGP] or S/MIME [SMIME], 1215 servers MUST be careful not to accidently destroy the integrity of 1216 the protected content (for example, by altering any text within the 1217 region covered by a signature while mapping between MMS and email). 1219 Since MMS does not include a clear separation between in-transit 1220 envelope and message content, there are increased risks of 1221 unauthorized disclosure of information, and additional challenges in 1222 protecting data. For example, Bcc recipients do not normally appear 1223 in the message content, only in the envelope; care MUST be taken in 1224 the gateway function to ensure that Bcc recipients which do appear 1225 are deleted from the message content. 1227 Some MMS features contain inherently more risk than others. For 1228 example, reply charging and sender address hiding. The reply 1229 charging mechanism requires a high degree of trust between entities 1230 with little technical basis. Deliberate or accidental abuse of this 1231 trust can result in unexpected or unauthorized charges. For 1232 example, a sender may be charged for unauthorized replies, or a 1234 Gellens [Page 28] Expires October 2005 1235 sender may be charged for a reply which the author thought would be 1236 paid for by the recipient. A sender's identity may be disclosed in 1237 violation of a request for this to be blocked. The identity of 1238 recipients may be disclosed to other recipients (or even 1239 non-recipients) for a message in which the sender intended for the 1240 recipients not to be disclosed. 1242 It is possible to hide the sender's identity from non-recipients 1243 using anonymous remailers. It is hard to hide the sender's identity 1244 from recipients when the mail is cryptographically signed. In view 1245 of anti-spam measures it may be undesirable to hide the sender's 1246 identity. 1248 Additional mechanisms can be developed to protect against various 1249 threats, however, these are not included in this version of this 1250 specification. It is strongly RECOMMENDED that features such as 1251 reply charging and sender identity hiding not be used across carrier 1252 domains, and be used within carrier domains only with full 1253 understanding of the risks involved. 1255 4 Normative References 1257 IETF: 1259 [DSN-Msg] "An Extensible Message Format for Delivery Status 1260 Notifications", Moore, Vaudreuil, RFC 3464, January 2003. 1262 [DSN-SMTP] "SMTP Service Extension for Delivery Status 1263 Notifications", Moore, RFC 3461, January 2003. 1265 [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: 1266 Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, 1267 November 1996. 1269 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 1270 Requirement Levels", RFC 2119, Harvard University, March 1997. 1272 [MDN] "An Extensible Message Format for Message Disposition 1273 Notifications", Fajman, RFC 2298, March 1998. 1275 [Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001. 1277 [Report-Fmt] "The Multipart/Report Content Type for the Reporting of 1278 Mail System Administrative Messages", Vaudreuil, RFC 3462, January 1279 2003 1281 Gellens [Page 29] Expires October 2005 1283 [RESP] Enhanced Mail System Status Codes, Vaudreuil, RFC 1893, 1284 January 1996. 1286 [SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April 1287 2001. 1289 5 Informative References 1291 IETF: 1293 [Auth] "SMTP Service Extension for Authentication", Myers, RFC 2554, 1294 March 1999 1296 [BINARY] SMTP Service Extensions for Transmission of Large and 1297 Binary MIME Messages", Vaudreuil, Parsons, RFC 3030, December 2000. 1299 [Codes] "SMTP Service Extension for Returning Enhanced Error Codes", 1300 Freed, RFC 2034, October 1996. 1302 [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, 1303 June 2000. 1305 [Msg-Encap] "Proposed Standard for Message Encapsulation", Rose, 1306 Stefferud, RFC 934, January 1985. 1308 [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, 1309 February 1997. 1311 [IPSec] "Security Architecture for the Internet Protocol", Kent, 1312 Atkinson, RFC 2401, November 1998 1314 [PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, 1315 Roessler, RFC 3156, August 2001 1317 [SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC 1318 2633, June 1999 1320 [StartTLS] "SMTP Service Extension for Secure SMTP over Transport 1321 Layer Security", Hoffman, RFC 3207, February 2002 1323 [Submission] "Message Submission", Gellens, Klensin, RFC 2476, 1324 December 1998. 1326 [VPIM] "Voice Profile Internet Mail �- Version 2", Vaudreuil, 1327 Parsons, RFC 2421, September 1998. 1329 Gellens [Page 30] Expires October 2005 1330 OMA: 1332 OMA specifications are available at the OMA web site 1333 . 1335 [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C 1337 3GPP2 and 3GPP: 1339 3GPP2 specifications are available at the 3GPP2 (Third 1340 Generation Partnership Project 2) web site 1341 . 1343 3GPP specifications are available at the 3GPP (Third Generation 1344 Partnership Project) web site 1346 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310 1348 "MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340 1350 "Multimedia Messaging Service: Functional description; Stage 2", TS 1351 23.140 Release 5. 1353 [Formats] "Multimedia Messaging Service (MMS) Media Format and 1354 Codecs for cdma2000 Spread Spectrum Systems�, C.S0045 1356 [Overview] "Multimedia Messaging Services (MMS) Overview", 1357 X.S0016-000 1359 [Stage_1] "Multimedia Messaging Services (MMS); Stage 1", 1360 Requirements, October 2002, S.R0064-0. 1362 [Stage_2] �Multimedia Messaging Service (MMS); Stage 2", Functional 1363 Specification, April 2003, X.S0016-200. 1365 "Multimedia Messaging Service; Media formats and codecs", 1366 TS26.140Release 5. 1368 6 Author's Address 1370 Randall Gellens 1371 QUALCOMM Incorporated 1372 5775 Morehouse Drive 1373 San Diego, CA 92121 1374 USA 1375 randy@qualcomm.com 1377 Gellens [Page 31] Expires October 2005 1378 Intellectual Property Statement 1380 The IETF takes no position regarding the validity or scope of any 1381 intellectual property or other rights that might be claimed to 1382 pertain to the implementation or use of the technology described in 1383 this document or the extent to which any license under such rights 1384 might or might not be available; neither does it represent that it 1385 has made any effort to identify any such rights. Information on the 1386 IETF's procedures with respect to rights in standards-track and 1387 standards-related documentation can be found in BCP-11. Copies of 1388 claims of rights made available for publication and any assurances 1389 of licenses to be made available, or the result of an attempt made 1390 to obtain a general license or permission for the use of such 1391 proprietary rights by implementors or users of this specification 1392 can be obtained from the IETF Secretariat. 1394 The IETF invites any interested party to bring to its attention any 1395 copyrights, patents or patent applications, or other proprietary 1396 rights which may cover technology that may be required to practice 1397 this standard. Please address the information to the IETF Executive 1398 Director. 1400 Full Copyright Statement 1402 Copyright (C) The Internet Society (2004). 1404 This document is subject to the rights, licenses and restrictions 1405 contained in BCP 78, and except as set forth therein, the authors 1406 retain all their rights. 1408 Disclaimer 1410 This document and the information contained herein are provided on 1411 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1412 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1413 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1414 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1415 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1416 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1418 Gellens [Page 32] Expires October 2005