idnits 2.17.1 draft-ietf-lemonade-mms-mapping-02.txt: -(1371): 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 1426. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1412), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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? 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1798 lines 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 3 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 (November 2004) is 7101 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 1305, but no explicit reference was found in the text == Unused Reference: 'Codes' is defined on line 1308, but no explicit reference was found in the text == Unused Reference: 'Hdrs' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'Formats' is defined on line 1362, 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 (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: Mapping Between MMS and Internet Mail R. Gellens 2 Document: draft-ietf-lemonade-mms-mapping-02.txt Qualcomm 3 Expires: May 2005 November 2004 5 Mapping Between the Multimedia Messaging Service (MMS) 6 and Internet Mail 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed 12 and any of which I become aware will be disclosed, in accordance 13 with RFC 3668 (BCP 79). 15 By submitting this Internet-Draft, I accept the provisions of 16 Section 3 of RFC 3667 (BCP 78). 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt The list of 30 Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 The cellular telephone industry has defined a service known as the 40 Multimedia Messaging Service (MMS). This service uses formats and 41 protocols which are similar to, but differ in key ways from those 42 used in Internet mail. 44 Gellens [Page 1] Expires May 2005 45 This document specifies how to exchange messages between these two 46 services, including mapping information elements as used in MMS 47 X-Mms-* headers as well as delivery and disposition reports, to and 48 from that used in ESMTP and Internet message headers. 50 Gellens [Page 2] Expires May 2005 51 Table of Contents 53 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Conventions Used in this Document . . . . . . . . . . . . 4 56 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 58 1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 59 2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6 60 2.1 Mapping Specification . . . . . . . . . . . . . . . . . . 6 61 2.1.1 MMS to Internet Mail . . . . . . . . . . . . . . . . . 6 62 2.1.2 Internet Mail to MMS . . . . . . . . . . . . . . . . 7 63 2.1.3 MMS Information Element Mappings . . . . . . . . . . . 7 64 2.1.3.1 Table 1: MM3 Mappings . . . . . . . . . . . . . . 8 65 2.1.3.2 Conversion of messages from MMS to Internet format 10 66 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet 14 67 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet 14 68 2.1.3.3 Conversion of messages from Internet to MMS format 17 69 2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 18 70 2.1.4 Report Generation and Conversion . . . . . . . . . . 20 71 2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 20 72 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Inte 21 73 2.1.4.2 Delivery Report Mapping from Internet Message to M 22 74 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Me 23 75 2.1.4.3 Read Report Mapping from MMS to Internet Message . 24 76 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet 25 77 2.1.4.4 Disposition Report Mapping from Internet Message t 26 78 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet 26 79 2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . . 27 80 3 Security Considerations . . . . . . . . . . . . . . . . . . . 27 81 4 Normative References . . . . . . . . . . . . . . . . . . . . . 29 82 5 Informative References . . . . . . . . . . . . . . . . . . . 30 83 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 84 Intellectual Property Statement . . . . . . . . . . . . . . . 31 85 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32 86 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 32 88 1 Introduction 90 1.1 Scope 92 This document describes how to exchange messages with Internet mail 93 systems. This includes translation between MMS (as defined by 94 3GPP/3GPP2/OMA) and Internet Mail messages using Extended Simple 95 Mail Transfer Protocol [SMTP] and Internet message format [Msg-Fmt]. 96 This also includes translation between delivery and disposition 97 reports as used in MMS and in Internet mail ([DSN-Msg] and [MDN]). 99 Gellens [Page 3] Expires May 2005 100 The MMS architecture [Stage_2] and specifications [Stage_3] refer to 101 interfaces as reference points named MMx. For example, MM1 is the 102 client-server interface, MM4 is the server-server interface, and MM3 103 is an interface to "external" or non-MMS systems. The specification 104 in this document can be used for message exchange between any system 105 which uses Internet Message formats and protocols and an MMS system; 106 from the perspective of the MMS system, reference point MM3 is used. 108 This document includes support for voice messages specified by the 109 Voice Profile for Internet Mail [VPIM]. The VPIM specification 110 allows voice messages to be exchanged between voice mail systems 111 using Internet mail format [Msg-Fmt] and transported via Extended 112 Simple Mail Transfer Protocol [SMTP]. Thus, the MMS MM3 interface 113 supports the ability to exchange voice messages between an MMS 114 system and a voice mail system. Note that such use is distinct from 115 voice media being part of a user-composed multimedia message. 117 Note that MM3 can also be used for interworking with "external" 118 (non-MMS) systems other than Internet mail, such as Short Messaging 119 Service (SMS) and access to external mail stores (such as a voice 120 mail system). This specification does not address these other uses 121 or sub-interfaces of MM3; it is only concerned with Internet mail 122 interworking and specifically exchange of messages. 124 All MM3 Stage 2 [Stage_2] functions are supported except for reply 125 charging and sender address hiding, which may be addressed in future 126 extensions. 128 1.2 Conventions Used in this Document 130 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 131 NOT", and 132 "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 May 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 May 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 May 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 May 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. [Ms 276 g-Fmt] headers not 277 listed here SHOULD be passed unaltered 279 2.1.3.1 Table 1: MM3 Mappings 281 =================|=================|================|============== 282 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 283 =================|=================|================|============== 284 3GPP MMS Version |N/A |N/A |X-Mms-Version: 285 | | | 286 _________________|_________________|________________|______________ 287 Message Type |N/A |N/A |X-Mms-Message- 288 (of PDU) | | | Type: 289 _________________|_________________|________________|______________ 290 Transaction ID |N/A |N/A |X-Mms-Transact 291 | | | ion-Id: 292 _________________|_________________|________________|______________ 293 Message ID |ENVID [DSN-SMTP] |Message-ID: |X-Mms-Message- 294 | | | Id: 295 | | |Message-ID: 296 _________________|_________________|________________|______________ 297 Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc: 298 address(es) |address(es) |omitted (Bcc) | 299 _________________|_________________|________________|______________ 300 Sender's address |MAIL FROM |From: (MAY set |From: 301 |address if |to locally-gen- | 302 |user-originated; |erated value | 303 |MUST set MAIL |to hide sender | 304 |FROM to null |identity) | 305 |("<>") for all | | 306 |automatically- | | 307 |generated MMs | | 308 _________________|_________________|________________|______________ 309 Content type |N/A |Content-Type: |Content-type: 310 | | | 311 | |For voice mes- | 312 | |sages compliant | 313 | |to [VPIM], see | 314 | |Note 2 | 315 =================|=================|================|============== 317 Gellens [Page 8] Expires May 2005 318 =================|=================|================|============== 319 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 320 =================|=================|================|============== 321 Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- 322 |MUST set MAIL | dence: bulk' | Class: 323 |FROM to null |on class=auto | 324 |("<>"). | | 325 _________________|_________________|________________|______________ 326 Date and time |N/A |Date: |Date: 327 of submission | | | 328 _________________|_________________|________________|______________ 329 Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry: 330 |[Deliver-By] | | 331 _________________|_________________|________________|______________ 332 Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery 333 ery time |sion; not relay) | | -Time: 334 _________________|_________________|________________|______________ 335 Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery 336 request |SHOULD also | | -Report: 337 |specify recip- | | 338 |ient address as | | 339 |ORCPT; SHOULD | | 340 |also specify | | 341 |ENVID | | 342 _________________|_________________|________________|______________ 343 Importance (a/k/a|N/A |Importance: |X-Mms- 344 "priority") | |X-Priority: | Priority: 345 | | | 346 | | | 347 _________________|_________________|________________|______________ 348 Sender visib- |N/A |N/A |X-Mms-Sender- 349 ility | | | Visibility: 350 _________________|_________________|________________|______________ 351 Read reply |N/A |Disposition- |X-Mms-Read- 352 request | | Notification | Reply: 353 | | -To: [MDN] | 354 _________________|_________________|________________|______________ 355 Reply-charging |(not currently |(not currently |X-Mms-Reply- 356 permission |supported) |supported) | Charging: 357 _________________|_________________|________________|______________ 358 Reply-charging |(not currently |(not currently |X-Mms-Reply- 359 permission |supported) |supported) | Charging- 360 deadline | | | Deadline: 361 _________________|_________________|________________|______________ 362 Reply-charging |(not currently |(not currently |X-Mms-Reply- 363 permission |supported) |supported) | Charging- 364 limitation | | | Size: 365 =================|=================|================|============== 367 Gellens [Page 9] Expires May 2005 368 =================|=================|================|============== 369 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 370 =================|=================|================|============== 371 Reply-charging |(not currently |(not currently |X-Mms-Reply- 372 usage request |supported) |supported) | Charging- 373 | | | Id: 374 _________________|_________________|________________|______________ 375 Reply-charging |(not currently |(not currently |X-Mms-Reply- 376 usage reference |supported) |supported) | Charging: 377 _________________|_________________|________________|______________ 378 Subject |N/A |Subject: |Subject: 379 _________________|_________________|________________|______________ 380 Forward counter |N/A |Resent-Count: |(Not sup- 381 | | |ported) 382 _________________|_________________|________________|______________ 383 Previously-sent- |N/A |Resent-From: |X-Mms-Previous 384 by | | | ly-Sent-By: 385 _________________|_________________|________________|______________ 386 Previously-sent- |N/A |Resent-Date: |X-Mms- 387 date and-time | | | Previously- 388 | | | Sent-Date: 389 _________________|_________________|________________|______________ 390 Hop/host trace |N/A |Received: |(Not sup- 391 | | |ported) 392 _________________|_________________|________________|______________ 393 Sensitivity |N/A |Sensitivity: see|N/A 394 | |Note 1 | 395 _________________|_________________|________________|______________ 396 Content |N/A | | 397 =================|=================|================|============== 399 Note 1: The [VPIM] 'Sensitivity' header element i 400 ndicates the 401 privacy requested by the message originator (values are "personal" 402 or "private"); a message recipient MUST NOT forward a message with a 403 'Sensitivity' header. 405 Note 2: A MIME-Version header with a comment of "Voice 2.0" 406 indicates that the voice message conforms to [VPIM]. 408 2.1.3.2 Conversion of messages from MMS to Internet format 410 3GPP MMS Version 412 The 'X-Mms-Version:' header, if present, SHOULD be removed. 414 Gellens [Page 10] Expires May 2005 415 Message Type (of PDU) 417 The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. 419 Transaction ID 421 The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. 423 Message ID 425 An 'X-Mms-Message-Id:' header, if present, SHOULD be retained. 427 The 'Message-Id:' header MUST be retained. If not present it MUST 428 be created, with a unique value. If an 'X-Mms-Message-Id:' header 429 is present and a 'Message-Id:' header is not, the value of the 430 'X-Mms-Message-Id:' header MAY be used in creating the 'Message-Id:' 431 header. 433 The message ID SHOULD be transmitted in the ESMTP envelope as the 434 ENVID parameter, as specified in [DSN-SMTP]. 436 Recipient(s) address 438 The address of each recipient MUST be transmitted in the SMTP 439 envelope as a RCPT TO value. All disclosed recipients SHOULD also 440 appear in a 'To:' or 'Cc:' header. At least one 'To:' or 'Cc:' 441 header MUST be present. If all recipients are undisclosed, a 'To:' 442 header MAY be created that contains a comment, for example 'To: 443 (undisclosed recipients)'. The 'To:' header SHOULD NOT appear more 444 than once. The 'Cc:' header SHOULD NOT appear more than once. 446 Each recipient address MUST obey the length restrictions per [SMTP]. 448 Current Internet message format requires that only 7-bit US-ASCII 449 characters be present in addresses. Other characters (for example, 450 non-7-bit characters in a phrase part of an address header) MUST be 451 encoded according to [Hdr-Enc]. Note that it would be possible to 452 define an SMTP extension to permit transmission of unencoded 8-bit 453 characters, but in the absence of such an extension [Hdr-Enc] MUST 454 be used. 456 Sender address 458 The address of the message sender SHOULD appear in the 'From:' 459 header, unless address hiding has been requested. If address hiding 460 has been requested, the 'From:' header MAY contain a comment to this 461 effect, for example, 'From: (anonymous sender)'. 463 Gellens [Page 11] Expires May 2005 464 The address of the message sender for all user-generated messages 465 ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the SMTP 466 envelope as the MAIL FROM value unless address hiding has been 467 requested and the receiving server is not known and trusted to 468 support address hiding. 470 The 'From:' header and the MAIL FROM value MAY be set to a 471 locally-generated value to hide the sender identity in anonymous 472 messages when the receiving system does not support anonymous 473 messages. Locally generated addresses MAY be internally mapped to 474 the actual address to allow replies to anonymous messages, but such 475 mapping is beyond the scope of this specification, as is a mechanism 476 for discovering and requesting support for anonymous messages. 478 Because of the risk of mail loops, it is critical that the MAIL FROM 479 be set to null ("<>") for all automatically-generated MMs (such as 480 'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to 481 null for all automatically-generated messages. This includes 482 reports, "out-of-office" replies, etc. 484 Current Internet message format requires that only 7-bit US-ASCII 485 characters be present in addresses. Other characters (for example, 486 non-7-bit characters in a phrase part of an address header) MUST be 487 encoded according to [Hdr-Enc]. Note that it would be possible to 488 define an SMTP extension to permit transmission of unencoded 8-bit 489 characters, but in the absence of such an extension [Hdr-Enc] MUST 490 be used. 492 The sender address MUST obey the length restrictions of [SMTP]. 494 Content type 496 The 'Content-Type:' header SHOULD be preserved. Content types not 497 in widespread use in the Internet MAY be converted into those that 498 are, when such conversion can be done without significant loss of 499 content. For example, SMIL messages MAY be converted into 500 widely-supported multipart/related with multipart/html. When such 501 conversion is done, the 'Content-Type:' header MUST be updated if it 502 is no longer correct. 504 Message class 506 The 'X-Mms-Message-Class:' header MAY be retained. A 'Precedence: 507 bulk' header MAY be inserted for class=auto or class=advertisement. 508 See 'Sender Address' above. (Class=personal and class=informational 509 do not require special handling.) 511 Gellens [Page 12] Expires May 2005 512 Time of Expiry 514 The 'X-Mms-Expiry:' header, if present, SHOULD be removed. 516 The remaining time until the message is considered expired SHOULD be 517 transmitted in the ESMTP envelope by using the DELIVER-BY extension, 518 as specified in [Deliver-By]. 520 Note that the ESMTP DELIVER-BY extension carries time remaining 521 until expiration; each server decrements the value by the amount of 522 time it has possessed the message. The 'X-Mms-Expiry:' header may 523 contain either the absolute time at which the message is considered 524 expired or the relative time until the message is considered 525 expired. 527 Earliest delivery time 529 The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed. 531 Future delivery is a message submission, not message relay feature. 533 Delivery report request 535 Requests for delivery status notifications (DSNs) SHOULD be 536 transmitted in the ESMTP envelope by using the DSN extension as 537 specified in [DSN-SMTP] to request "success" or "none" notification 538 (depending on the value of the 'X-Mms-Delivery-Report' header). 539 When the NOTIFY extension is used, the unaltered recipient address 540 SHOULD be transmitted as the ORCPT value, and the original message 541 ID SHOULD be transmitted as the ENVID value. 543 The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed. 545 Importance 547 The message sender's importance value (also called "priority", 548 although this can be confused with class-of-service values) SHOULD 549 be transmitted using an 'Importance:' header (although currently not 550 all Internet mail clients support this header). 552 An 'X-Priority:' header MAY be used in addition. Although not 553 standardized, most email applications support the 'X-Priority:' 554 header, and use an 'X-Priority' value of 3 for messages with 555 "normal" priority. More important messages have lower values and 556 less important message have higher values. In most cases, urgent 557 messages have an X-Priority value of 1. 559 Gellens [Page 13] Expires May 2005 560 Suggested mappings: 562 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message) 564 ---------------------------|------------------ 565 'X-Mms-Priority: High' |'Importance: High' 566 ---------------------------|------------------ 567 'X-Mms-Priority: Normal' |[omit] 568 ---------------------------|----------------- 569 - 570 'X-Mms-Priority: Low' |'Importance: Low' 571 ---------------------------|------------------ 573 Normal priority messages should omit the 'Importance:' header. 575 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet Message) 577 ---------------------------|---------------------- 578 'X-Mms-Priority: High' |'X-Priority: 2 (high)' 579 ---------------------------|---------------------- 580 'X-Mms-Priority: Normal |[omit] 581 ---------------------------|---------------------- 582 'X-Mms-Priority: Low |'X-Priority: 4 (low)' 583 ---------------------------|---------------------- 585 Normal priority messages SHOULD omit the 'X-Priority:' header. 587 The 'X-Mms-Priority:' header, if present, SHOULD be removed. 589 Sender visibility 591 Support for sender address hiding is not included in this version of 592 the mapping document. 594 The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be 595 removed. 597 Read reply request 599 A request for a read reply SHOULD be transmitted using a 600 'Disposition-Notification-To:' header as specified in [MDN]. 602 The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed. 604 Reply-charging 606 Reply charging permission and acceptance are complex issues 607 requiring both user agent and server support. Misapplied reply 608 charging may cause incorrect billing. Until the security issues 609 have been properly addressed, reply charging SHOULD NOT be honored 611 Gellens [Page 14] Expires May 2005 612 when using this interface. 614 The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 615 'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers 616 MAY be removed. Messages containing a reply-charging usage request 617 ('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or 618 'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be 619 rejected. 621 Subject 623 The 'Subject:' header MUST be preserved. Current Internet message 624 format requires that only 7-bit US-ASCII characters be present. 625 Other characters must be encoded according to [Hdr-Enc]. Note that 626 it would be possible to define an SMTP extension to permit 627 transmission of unencoded 8-bit characters, but in the absence of 628 such an extension [Hdr-Enc] must be used. 630 Resending/Forwarding 632 In MMS a message may be resent or forwarded, the difference being 633 that if the message has been downloaded then sending it to another 634 address is considered forwarding, while sending a message that has 635 not been downloaded is considered to be resending. 637 In Internet mail there are two primary ways of sending a previously 638 received message to a new recipient: forwarding and resending. 639 Forwarding is when a user creates a new message containing the 640 original message, either simply embedded within the text, or 641 delineated. Embedded messages generally have each original line 642 preceded by a quote symbol ('>'), surround the original text with a 643 preceding and trailing line which starts with hyphens as per 644 [Msg-Encap], such as '--- begin forwarded text' and '--- end 645 forwarded text', or encapsulate the original message as a 646 'message/rfc822' content type, perhaps within a 'multipart/mixed' 647 message. (This last method offers more robust delineation.) 648 Resending is when the original message is unaltered except for the 649 addition of 'Resent-' headers to explain the resending to the new 650 recipient. 652 A message may be resent more than once; each time new 'Resent-' 653 headers SHOULD be added at the top of the message. Thus, if more 654 than one series of 'Resent-' headers are present, the original 655 series is the last; the most recent is the first. 657 Forward counter 659 Gellens [Page 15] Expires May 2005 660 The 'Resent-Count:' header MAY be used to track the number of times 661 the message has been resent. Note that loop control is often done 662 by counting 'Received' headers, which are more general than 663 'Resent-' headers. 665 Previously-sent Information 667 A 'Resent-From:' header MAY be added to indicate the address of the 668 user who directed the message to be resent. 670 A 'Resent-Date:' header SHOULD be added to indicate the time and 671 date that the message was resent. 673 Any 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date' 674 headers, if present, SHOULD be removed. The information contained 675 in them SHOULD be translated into 'From:', 'Resent-To:', 676 'Resent-From:', 'Resent-Date:', and 'Resent-Count:' headers. The 677 original sender of the message SHOULD appear in the 'From:' header; 678 the original recipient(s) SHOULD appear in the 'To:' header; the 679 time and date the message was originally sent SHOULD appear in the 680 'Date:' header. The most recent sender SHOULD appear in the 681 top-most 'Resent-From:' header; the most recent recipient(s) SHOULD 682 appear in the top-most 'Resent-To:' header; the time and date the 683 message was most recently sent SHOULD appear in the top-most 684 'Resent-Date:' header. 686 'Received:' Headers 688 Each system that processes a message SHOULD add a 'Received:' header 689 as per [SMTP]. A message MAY be rejected if the number of 690 'Received:' headers exceeds a locally-defined maximum, which MUST 691 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 693 Privacy 695 Note that MMS systems do not currently support the 'Privacy' header 696 field as described by [VPIM]. 698 Content 700 The message content appears in the message body. Note that Internet 701 message format requires that line-endings be encoded as CR LF, thus 702 charset encodings that do not have this property cannot be used in 703 text/* body parts. (They MAY be used in other body parts, but only 704 when they are suitable encoded or when binary transmission has been 705 negotiated.) In particular, MMS allows UTF-16, while Internet 706 message format does not. UTF-16 encoding MUST be translated to 707 UTF-8 or another charset and encoding which is suitable for use in 708 Internet message format/protocols. 710 Gellens [Page 16] Expires May 2005 711 2.1.3.3 Conversion of messages from Internet to MMS format 713 3GPP MMS Version 715 An 'X-Mms-Mms-Version:' header SHOULD be added. 717 Message Type (of PDU) 719 An 'X-Mms-Message-Type:' header SHOULD be used in accordance with 720 the specific MMS interface (e.g., MM1, MM4). 722 Transaction ID 724 An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with 725 the specific MMS interface (e.g., MM1, MM4). 727 Message ID 729 The 'Message-Id:' header MUST be retained. If not present it MUST 730 be created, with a unique value. If the 'Message-Id:' header does 731 not exist, but the SMTP envelop contains an ENVID value (as 732 specified in [DSN-SMTP]), it MAY be used to construct the value. 734 Recipient(s) address 736 'To:' and 'Cc:' headers MUST be retained. 738 Each recipient contained in the SMTP envelope (RCPT TO values) MUST 739 be considered a recipient of the message. Recipients who appear in 740 address headers but not the SMTP envelope MUST be ignored. 741 Recipients who appear in the [SMTP] envelope but do not appear in 742 headers are considered "blind" (Bcc) recipients; such recipients 743 MUST NOT be added to message headers (including address and trace 744 headers) unless there is only one recipient total. 746 Sender address 748 The 'From:' header MUST be retained. 750 Content type 752 The complete 'Content-Type:' header (including any parameters) 753 SHOULD be preserved. 755 Message class 757 Gellens [Page 17] Expires May 2005 758 An X-Mms-Message-Class: personal' header SHOULD be created for all 759 received messages with a non-null return path (MAIL FROM value in 760 the SMTP envelope). An X-Mms-Message-Class: auto' header MAY be 761 created for messages with a null return path. 763 Time of Expiry 765 An 'x-Mms-Expiry:' header SHOULD be created if the message contains 766 a relative time to expiration in the DELIVER-BY extension, as 767 specified in [Deliver-By]. 769 Earliest delivery time 771 An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. If a 772 message arrives via ESMTP relay containing an earliest time of 773 delivery in the AFTER extension, it MAY be rejected. If a message 774 is submitted via Message Submission [Submission] containing an 775 earliest time of delivery in the AFTER extension, it MUST either be 776 retained until the delivery time arrives, or it may be immediately 777 rejected. It MUST NOT be delivered or further relayed prior to the 778 delivery time. 780 Delivery report request 782 An 'X-Mms-Delivery-Report:' header SHOULD be created for messages 783 which request 'success' or 'none' delivery status notification by 784 use of the DSN extension as specified in [DSN-SMTP]. Requests for 785 'delay' notifications or non-default actions, such as that only the 786 message headers should be returned, cannot be mapped onto MMS 787 headers and thus SHOULD be ignored. 789 Priority 791 An 'X-Priority:' or 'Importance:' header, if present, SHOULD be 792 replaced with an 'X-Mms-Priority:' header. Suggested mappings: 794 2.1.3.3.1 Table 4: Priority Mappings (Internet Message to MMS) 796 -------------------------------|---------------------- 797 'X-Priority: 1 (highest)' |'X-Mms-Priority: High' 798 -------------------------------|---------------------- 799 'X-Priority: 2 (high)' |'X-Mms-Priority: High' 800 -------------------------------|---------------------- 801 'Importance: High' |'X-Mms-Priority: High' 802 -------------------------------|---------------------- 803 'X-Priority: 3 (normal)' | [omitted] 804 -------------------------------|---------------------- 805 'Importance: Normal' | [omitted] 806 -------------------------------|---------------------- 808 Gellens [Page 18] Expires May 2005 809 'X-Priority: 4 (low)' |'X-Mms-Priority: Low' 810 -------------------------------|---------------------- 811 'Importance: Low' |'X-Mms-Priority: Low' 812 -------------------------------|---------------------- 813 'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low' 814 -------------------------------|---------------------- 816 Normal priority messages SHOULD omit the 'X-Mms-Priority:' header. 818 Sender visibility 820 Support for sender address hiding is not currently supported. 822 Read reply request 824 A request for a read reply contained in a 825 'Disposition-Notification-To:' header as specified in [MDN] SHOULD 826 be replaced with an 'X-Mms-Read-Reply:' header. 828 Subject 830 The 'Subject:' header MUST be preserved. 832 Resending/Forwarding 834 One or more sets of 'Resent-' headers, if present, SHOULD be mapped 835 to 'To:', 'From:', 'Date:', and 'X-Mms-Previously-Sent-' headers. 837 'Received:' Headers 839 Each system that processes a message SHOULD add a 'Received:' header 840 as per [SMTP]. A message MAY be rejected if the number of 841 'Received:' headers exceeds a locally-defined maximum, which MUST 842 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 844 Sensitivity 846 The 'Sensitivity:' header field (value = "personal" or "private") 847 [VPIM] indicates the desire of a voice message originator to send 848 the message contents to the original recipient list with assurance 849 that the message will not be forwarded further by either the 850 messaging system or the actual message recipient(s). Since 851 sensitivity is not an MMS feature, any messages which contain a 852 'Sensitivity:' header SHOULD NOT be sent to an MMS system. An 853 appropriate extended error response code [RESP] SHOULD be used in 854 the associated negative delivery status report. 856 Gellens [Page 19] Expires May 2005 857 Content 859 The message content appears in the message body. 861 2.1.4 Report Generation and Conversion 863 Internet Message systems use the multipart/report MIME type for 864 delivery and disposition reports (often called "read reports") as 865 specified in [Report-Fmt]. This format is a two- or three-part MIME 866 message; one part is a structured format describing the event being 867 reported in an easy-to-parse format. Specific reports have a format 868 which is built on [Report-Fmt]. Delivery reports are specified in 869 [DSN-Msg]. Message disposition reports, which include read reports, 870 are specified in [MDN]. 872 By contrast, MMS reports are plain text, with no defined structure 873 specified. This makes it difficult to convert from an MMS report to 874 a standard Internet report. 876 An MMS Relay/Server supporting Internet Message exchange using MM3 877 MUST convert reports received from one side (MMS or Internet mail) 878 destined for the other. In addition, reports MUST be generated as 879 appropriate for messages received from either side of the MM3 880 interface. For example, if an MM to be sent via MM3 is not 881 deliverable, a delivery status MM shall be generated. Likewise, if 882 an Internet message is received via MM3 that cannot be further 883 relayed or delivered, a delivery status report [DSN-Msg] MUST be 884 generated. 886 When creating delivery or disposition reports from MMS reports, the 887 MMS report should be parsed to determine the reported event and 888 time, status, and the headers of the referenced (original) message. 889 These elements, once determined, are used to populate the subparts 890 of the delivery or disposition report. The first subpart is of type 891 text/plain, and contains a human-readable explanation of the event. 892 This text may include a statement that the report was synthesized 893 based on an MMS report. The second subpart is of type 894 report/delivery-status (for delivery reports) or 895 report/disposition-notification (for disposition reports). This 896 second part contains a structured itemization of the event. The 897 third subpart is of type message/rfc822 and includes the headers and 898 optionally the body of the referenced (original) message. 900 2.1.4.1 Delivery Report Mapping from MMS to Internet Message 902 Gellens [Page 20] Expires May 2005 903 The following table maps information elements from MMS delivery 904 reports to the format specified in [DSN-Msg]. 906 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message) 908 ======================|============|=================================== 909 Information Element |MMS Delivery|[DSN-Msg] Element 910 |Report Elem | 911 ======================|============|=================================== 912 ID of message whose |Message-Id: |'Original-Envelope-ID' field of 913 delivery status is | |per-message fields ( 914 use value of 915 being reported | |ENVID from ESMTP envelope if avail- 916 | |able, 'Message-ID:' otherwise). 917 ----------------------|------------|----------------------------------- 918 Recipient address of |From: |'Final-Recipient' field of the 919 the original message | |per-recipient section 920 (object of delivery | | 921 report) | | 922 ----------------------|------------|----------------------------------- 923 Destination address of|To: |'To:' header field value of top- 924 report | |level. 925 | | 926 | |Value taken from [SMTP] envelope 927 | |return-path of message being 928 | |reported, not its 'From:' header 929 | |field. 930 ----------------------|------------|----------------------------------- 931 Date and time the |Date: |'Date:' header field value of top- 932 message was handled | |level 933 ======================|============|=================================== 935 Gellens [Page 21] Expires May 2005 936 ======================|============|=================================== 937 Information Element |MMS Delivery|[DSN-Msg] Element 938 |Report Elem | 939 ======================|============|===================================Delivery status of |X-Mms- |Action and Status fields of 940 original message | Status: |per-recipient section. 941 | | 942 | |The 'Action' field indicates if the 943 | |message was delivered. 944 | | 945 | |For failed delivery an appropriate 946 | |'Status' value shall be included 947 | |per [DSN-Msg]. 948 | | 949 | |The Action field is set to one of 950 | |the following values: 951 | | 952 | |* delivered (used for MMS status 953 | |values 'retrieved' and 'rejected', 954 | |depending on 'Status' code). 955 | | 956 | |* failed (used for MMS status 957 | |values 'expired' and 'unreachable') 958 | | 959 | |* delayed MAY be used for MMS 960 | |status value 'deferred' 961 | | 962 | |* relayed (used for MMS status 963 | |value 'indeterminate') 964 | | 965 | |* expanded (SHOULD NOT be used) 966 ----------------------|------------|----------------------------------- 967 Status Text | |Text in first part (human-readable 968 | |part) 969 ----------------------|------------|----------------------------------- 971 When an MMS Relay/Server generates a [DSN-Msg] in response to a 972 message received using [SMTP] on MM3: 974 * Top-level header field 'To:' SHOULD be the [SMTP] return-path of 975 the message whose status is being reported. 977 * Top-level header field 'From:' SHOULD be the address of the 978 recipient that the delivery-report concerns. 980 * The first part of the [DSN-Msg] SHOULD include the MM Status Text 981 field that would have been generated for an MM1 delivery-report. 983 Gellens [Page 22] Expires May 2005 984 2.1.4.2 Delivery Report Mapping from Internet Message to MMS 986 The following table maps information elements from a delivery report 987 as specified in [DSN-Msg] to the format of an MMS delivery report. 989 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS) 991 ===================|==================|================================ 992 Information Element|MMS Delivery |[DSN=Msg] Element 993 |Report Element | 994 ===================|==================|================================ 995 ID of the original |Message-Id: |'Original-Envelope-ID' field of 996 message (object of | |per-message fields. If not 997 delivery report) | |available, the 'Message-ID' 998 | |header field of the message 999 | |being reported, if included in 1000 | |the third part, may be 1001 | |substituted. 1002 -------------------|------------------|-------------------------------- 1003 Recipient address |From: |If available, the 'Original 1004 of the original | |-Recipient' field of the per- 1005 message (object of | |recipient section should be 1006 delivery report) | |used; otherwise the 'Final- 1007 | |Recipient' field of the per- 1008 | |recipient section is used 1009 -------------------|------------------|-------------------------------- 1010 Destination address|To: |'To:' header field value of 1011 of report | |top-level. 1012 | | 1013 | |Value taken from [SMTP] envelope 1014 | |return-path of message being 1015 | |reported, not its 'From:' header 1016 | |field. 1017 ===================|==================|=================================== 1019 Gellens [Page 23] Expires May 2005 1020 ===================|==================|================================ 1021 Information Element|MMS Delivery |[DSN=Msg] Element 1022 |Report Element | 1023 ===================|==================|================================ 1024 Date and time the |Date: |'Date:' header field value of 1025 message was handled| |top-level 1026 -------------------|------------------|-------------------------------- 1027 Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of 1028 original message | |per-recipient section 1029 |Set to one of the | 1030 |following values: | 1031 | | 1032 |'retrieved' (used | 1033 |for 'Action' value| 1034 |'delivered'). | 1035 | | 1036 |'unreachable' | 1037 |(used for 'Action'| 1038 |value 'failed') | 1039 | | 1040 |'forwarded' (used | 1041 |for 'Action' value| 1042 |'relayed') | 1043 | | 1044 |'deferred' MUST | 1045 |NOT be used | 1046 |(ignore DSNs with | 1047 |'Action' value | 1048 |'delayed') | 1049 -------------------|------------------|-------------------------------- 1050 Status Text | |Text in first part (human- 1051 | |readable part) 1052 ===================|==================|================================ 1054 Gellens [Page 24] Expires May 2005 1056 Internet Draft Mapping Between MMS an 1057 d Internet Mail November 2004 1059 2.1.4.3 Read Report Mapping from MMS to Internet Message 1061 The following table maps information elements from MMS read reports 1062 to the format specified in [MDN]. 1064 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 1066 ======================|============|=================================== 1067 Information Element |MMS Delivery|[DSN-Msg] Element 1068 |Report Elem | 1069 ======================|============|=================================== 1070 ID of the original |Message-Id: |'Original-Envelope-ID' field (use 1071 message (object of | |value of ENVID from ESMTP envelope 1072 read report) | |if available, 'Message-ID:' 1073 | |otherwise). 1074 ----------------------|------------|----------------------------------- 1075 Recipient address of |From: |'Final-Recipient' field 1076 the original message | | 1077 ----------------------|------------|----------------------------------- 1078 Destination address of|To: |'To:' header field value of top- 1079 report | |level. 1080 | | 1081 | |Value taken from 'Disposition- 1082 | |Notification-To:' header field of 1083 | |message being reported, not its 1084 | |'From:' header field. 1085 ----------------------|------------|----------------------------------- 1086 Date and time the |Date: |'Date:' header field value of top- 1087 message was handled | |level 1088 ----------------------|------------|----------------------------------- 1089 Disposition of message|X-Mms-Read- |Disposition-field 1090 being reported | Status: | 1091 | |For MMS-Read-Status value 'read', 1092 | |use 'disposition-type' value 1093 | |'displayed'; for MMS-Read-Status 1094 | |value 'Deleted without being read', 1095 | |use 'disposition-type' value 1096 | |'deleted') 1097 ----------------------|------------|----------------------------------- 1098 Status Text | |Text in first part (human-readable 1099 | |part) 1100 ======================|============|=================================== 1102 When an MMS Relay/Server generates an [MDN] in response to a message 1103 received using ESMTP on MM3: 1105 Gellens [Page 25] Expires May 2005 1106 * Top-level header field 'To:' SHOULD be the value of the 1107 'Disposition-Notification-To:' header field of the message whose 1108 disposition is being reported . 1110 * Top-level header field 'From:' SHOULD be the address of the 1111 recipient that the read report concerns. 1113 2.1.4.4 Disposition Report Mapping from Internet Message to MMS 1115 The following table maps information elements from a disposition 1116 report as specified in [MDN] to the format of an MMS read report. 1118 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet Message to 1119 MMS) 1121 ===================|==================|================================ 1122 Information Element|MMS Read Report |[DSN=Msg] Element 1123 |Element | 1124 ===================|==================|================================ 1125 ID of the original |Message-Id: |'Original-Envelope-ID' field 1126 message (object of | | 1127 disposition report)| | 1128 -------------------|------------------|-------------------------------- 1129 Recipient address |From: |'Final-Recipient' field 1130 of the original | | 1131 message | | 1132 -------------------|------------------|-------------------------------- 1133 Destination address|To: |'To:' header field value of 1134 of report | |top-level. 1135 | | 1136 | |Value taken from 'Disposition- 1137 | |Notification-To:' header field 1138 | |of message being reported, not 1139 | |its 'From:' header field. 1140 -------------------|------------------|-------------------------------- 1141 Date and time the |Date: |'Date:' header field value of 1142 message was handled| |top-level 1143 ===================|==================|================================ 1145 Gellens [Page 26] Expires May 2005 1146 ===================|==================|================================ 1147 Information Element|MMS Read Report |[DSN=Msg] Element 1148 |Element | 1149 ===================|==================|================================Disposition of |X-Mms-Read-Status:|disposition-field 1150 message being | | 1151 reported |Set to one of the | 1152 |following values: | 1153 | | 1154 |'read' (used for | 1155 |disposition-type | 1156 |value 'displayed')| 1157 | | 1158 |'Deleted without | 1159 |being read' (used | 1160 |for disposition- | 1161 |types 'deleted', | 1162 |'denied' and | 1163 |'failed' when | 1164 |action-mode is | 1165 |'automatic- | 1166 |action') | 1167 -------------------|------------------|-------------------------------- 1168 Status Text | |Text in first part (human- 1169 | |readable part) 1170 ===================|==================|================================ 1172 2.1.5 Message Delivery 1174 Within Internet mail, when ESMTP is used and delivery reports are 1175 requested [DSN-SMTP], delivery is considered to be acceptance of a 1176 message by the final server, that is, the server closest to the 1177 recipient. When an MMS Relay/Server receives a message using ESMTP 1178 and a delivery report is requested, the MMS Relay/Server MAY 1179 consider the message delivered when it has been sent to the MMS User 1180 Agent. 1182 3 Security Considerations 1184 Data contained within messages should not be automatically trusted. 1185 Even within a carrier's network, and certainly within the Internet, 1186 various deliberate and accidental attacks or corruptions are 1187 possible. For example, routers may contain vulnerabilities which 1188 may be exploited, IP traffic may be intercepted and/or modified, 1189 etc. 1191 Gellens [Page 27] Expires May 2005 1192 The following messaging-related security threats can be identified: 1194 * Misidentification of message source. 1196 * Message interception (unauthorized disclosure of contents). 1198 * Unauthorized disclosure of message sender or recipient. 1200 * Message modification (by adversary). 1202 * Message replay. 1204 * Traffic analysis (determining who is communicating with whom). 1206 There are existing mechanisms used to protect email traffic against 1207 some of these threats, such as: 1209 * Use of SSL/TLS (via [StartTLS]) to address disclosure and 1210 modification in transit between adjacent servers. 1212 * SMTP Authentication [Auth] to protect against misidentification of 1213 message source. 1215 * Use of end-to-end security mechanisms such as [PGP] or S/MIME 1216 [SMIME] to protect message contents. 1218 * Use of [IPSec] to protect against disclosure or mod 1219 ification in 1220 transit between servers. 1222 These mechanisms SHOULD be employed whenever the required 1223 infrastructure is available, e.g., a certificate infrastructure is 1224 necessary to support S/MIME, or user agent support for PGP is 1225 available. Enabling SMTP Authentication [Auth] and STARTTLS 1226 [StartTLS] are easy measures to deploy and SHOULD be used. 1228 Since MMS does not include a clear separation between in-transit 1229 envelope and message content, there are increased risks of 1230 unauthorized disclosure of information, and additional challenges in 1231 protecting data. For example, Bcc recipients do not normally appear 1232 in the message content, only in the envelope; care MUST be taken in 1233 the gateway function to ensure that Bcc recipients which do appear 1234 are deleted from the message content. 1236 Some MMS features contain inherently more risk than others. For 1237 example, reply charging and sender address hiding. The reply 1238 charging mechanism requires a high degree of trust between entities 1239 with little technical basis. Deliberate or accidental abuse of this 1240 trust can result in unexpected or unauthorized charges. For 1241 example, a sender may be charged for unauthorized replies, or a 1243 Gellens [Page 28] Expires May 2005 1244 sender may be charged for a reply which the author thought would be 1245 paid for by the recipient. A sender's identity may be disclosed in 1246 violation of a request for this to be blocked. The identity of 1247 recipients may be disclosed to other recipients (or even 1248 non-recipients) for a message in which the sender intended for the 1249 recipients not to be disclosed. 1251 It is possible to hide the sender's identity from non-recipients 1252 using anonymous remailers. It is hard to hide the sender's identity 1253 from recipients when the mail is cryptographically signed. In view 1254 of anti-spam measures it may be undesirable to hide the sender's 1255 identity. 1257 Additional mechanisms can be developed to protect against various 1258 threats, however, these are not included in this version of this 1259 specification. It is strongly RECOMMENDED that features such as 1260 reply charging and sender identity hiding not be used across carrier 1261 domains, and be used within carrier domains only with full 1262 understanding of the risks involved. 1264 4 Normative References 1266 IETF: 1268 [DSN-Msg] "An Extensible Message Format for Delivery Status 1269 Notifications", Moore, Vaudreuil, RFC 3464, January 2003. 1271 [DSN-SMTP] "SMTP Service Extension for Delivery Status 1272 Notifications", Moore, RFC 3461, January 2003. 1274 [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: 1275 Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, 1276 November 1996. 1278 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 1279 Requirement Levels", RFC 2119, Harvard University, March 1997. 1281 [MDN] "An Extensible Message Format for Message Disposition 1282 Notifications", Fajman, RFC 2298, March 1998. 1284 [Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001. 1286 [Report-Fmt] "The Multipart/Report Content Type for the Reporting of 1287 Mail System Administrative Messages", Vaudreuil, RFC 3462, January 1288 2003 1290 Gellens [Page 29] Expires May 2005 1292 [RESP] Enhanced Mail System Status Codes, Vaudreuil, RFC 1893, 1293 January 1996. 1295 [SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April 1296 2001. 1298 5 Informative References 1300 IETF: 1302 [Auth] "SMTP Service Extension for Authentication", Myers, RFC 2554, 1303 March 1999 1305 [BINARY] SMTP Service Extensions for Transmission of Large and 1306 Binary MIME Messages", Vaudreuil, Parsons, RFC 3030, December 2000. 1308 [Codes] "SMTP Service Extension for Returning Enhanced Error Codes", 1309 Freed, RFC 2034, October 1996. 1311 [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, 1312 June 2000. 1314 [Msg-Encap] "Proposed Standard for Message Encapsulation", Rose, 1315 Stefferud, RFC 934, January 1985. 1317 [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, 1318 February 1997. 1320 [IPSec] "Security Architecture for the Internet Protocol", Kent, 1321 Atkinson, RFC 2401, November 1998 1323 [PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, 1324 Roessler, RFC 3156, August 2001 1326 [SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC 1327 2633, June 1999 1329 [StartTLS] "SMTP Service Extension for Secure SMTP over Transport 1330 Layer Security", Hoffman, RFC 3207, February 2002 1332 [Submission] "Message Submission", Gellens, Klensin, RFC 2476, 1333 December 1998. 1335 [VPIM] "Voice Profile Internet Mail �- Version 2", Vaudreuil, 1336 Parsons, RFC 2421, September 1998. 1338 Gellens [Page 30] Expires May 2005 1339 OMA: 1341 OMA specifications are available at the OMA web site 1342 . 1344 [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C 1346 3GPP2 and 3GPP: 1348 3GPP2 specifications are available at the 3GPP2 (Third 1349 Generation Partnership Project 2) web site 1350 . 1352 3GPP specifications are available at the 3GPP (Third Generation 1353 Partnership Project) web site 1355 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310 1357 "MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340 1359 "Multimedia Messaging Service: Functional description; Stage 2", TS 1360 23.140 Release 5. 1362 [Formats] "Multimedia Messaging Service (MMS) Media Format and 1363 Codecs for cdma2000 Spread Spectrum Systems�, C.S0045 1365 [Overview] "Multimedia Messaging Services (MMS) Overview", 1366 X.S0016-000 1368 [Stage_1] "Multimedia Messaging Services (MMS); Stage 1", 1369 Requirements, October 2002, S.R0064-0. 1371 [Stage_2] �Multimedia Messaging Service (MMS); Stage 2", Functional 1372 Specification, April 2003, X.S0016-200. 1374 "Multimedia Messaging Service; Media formats and codecs", 1375 TS26.140Release 5. 1377 6 Author's Address 1379 Randall Gellens 1380 QUALCOMM Incorporated 1381 5775 Morehouse Drive 1382 San Diego, CA 92121 1383 USA 1384 randy@qualcomm.com 1386 Gellens [Page 31] Expires May 2005 1387 Intellectual Property Statement 1389 The IETF takes no position regarding the validity or scope of any 1390 intellectual property or other rights that might be claimed to 1391 pertain to the implementation or use of the technology described in 1392 this document or the extent to which any license under such rights 1393 might or might not be available; neither does it represent that it 1394 has made any effort to identify any such rights. Information on the 1395 IETF's procedures with respect to rights in standards-track and 1396 standards-related documentation can be found in BCP-11. Copies of 1397 claims of rights made available for publication and any assurances 1398 of licenses to be made available, or the result of an attempt made 1399 to obtain a general license or permission for the use of such 1400 proprietary rights by implementors or users of this specification 1401 can be obtained from the IETF Secretariat. 1403 The IETF invites any interested party to bring to its attention any 1404 copyrights, patents or patent applications, or other proprietary 1405 rights which may cover technology that may be re 1406 quired to practice 1407 this standard. Please address the information to the IETF Executive 1408 Director. 1410 Full Copyright Statement 1412 Copyright (C) The Internet Society (2004). 1414 This document is subject to the rights, licenses and restrictions 1415 contained in BCP 78, and except as set forth therein, the authors 1416 retain all their rights. 1418 Disclaimer 1420 This document and the information contained herein are provided on 1421 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1422 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1423 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1424 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1425 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1426 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1428 Gellens [Page 32] Expires May 2005