idnits 2.17.1 draft-ietf-lemonade-mms-mapping-01.txt: -(403): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(404): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(871): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1303): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1305): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1378): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1390): 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 1444. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1430), 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 13 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 2 instances of too long lines in the document, the longest one being 55 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 (October 2004) is 7132 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 1324, but no explicit reference was found in the text == Unused Reference: 'Codes' is defined on line 1327, but no explicit reference was found in the text == Unused Reference: 'Hdrs' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: 'Formats' is defined on line 1381, 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-01.txt Qualcomm 4 Expires: April 2005 October 2004 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 April 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 April 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 19 71 2.1.4 Report Generation and Conversion . . . . . . . . . . 20 72 2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 21 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 23 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 April 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. Sender address hiding may be used but is not recommended 127 without security assurances which are beyond the scope of this 128 specification (see Section 3). 130 1.2 Conventions Used in this Document 132 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 133 NOT", and "MAY" in this document are to be interpreted as described 134 in "Key words for use in RFCs to Indicate Requirement Levels" 135 [KEYWORDS]. 137 Note that in the text of this document, a distinction is made 138 between use of "SMTP" or "Simple Mail Transfer Protocol", and 139 "ESMTP" or "Extended Simple Mail Transfer Protocol": when the term 140 "ESMTP" or "Extended" is used, it indicates use of extended features 141 of SMTP; that is, those beyond the facilities of RFC 821. (These 142 extended facilities may be in RFC 2821 or in other RFCs, as 143 indicated by the specific RFC reference used; note that the name of 144 the RFC 2821 reference is "SMTP" because that is the official title 145 of the RFC.) 147 Gellens [Page 4] Expires April 2005 148 1.3 Definitions 150 --------------------|---------------------------------------------- 151 Anonymous Remailer |A service which accepts messages and resends 152 |them to their intended recipient, masking 153 |information about the original sender. 154 --------------------|---------------------------------------------- 155 Body |The portion of an SMTP message's Content 156 |following the Header (that is, following the 157 |first blank line). The Body may contain 158 |structured parts and sub-parts, each of which 159 |may have their own Header and Body. The Body 160 |contains information intended for the message 161 |recipient (human or software). 162 --------------------|---------------------------------------------- 163 Content |The portion of an SMTP message that is 164 |delivered. The Content consists of a Header 165 |and a Body. 166 --------------------|---------------------------------------------- 167 Disposition Report |Feedback information to an originator User 168 |Agent by a recipient User Agent about 169 Message Disposition |handling of an original message. This may 170 Notification |include notification that the message was or 171 |was not read, was deleted unread, etc. 172 --------------------|---------------------------------------------- 173 Envelope |The portion of an SMTP message not included in 174 |the Content; that is, not in the Header nor in 175 |the Body. Envelope information only exists 176 |while the message is in transit, and contains 177 |information used by SMTP agents (MTAs). 178 --------------------|---------------------------------------------- 179 Header |The first part of an SMTP message's Content. 180 |The Header is separated from the Body by a 181 |blank line. The Header consists of Fields 182 |(such as "To:"), also known as Header Fields 183 |or Headers. The message Header contains 184 |information used by User Agents. 185 --------------------|---------------------------------------------- 186 Gateway Function |An agent which acts as both MMSC and MTA 187 |and/or MSA. 188 --------------------|---------------------------------------------- 189 User Agent |An MMS or Email user agent 190 --------------------|---------------------------------------------- 192 Gellens [Page 5] Expires April 2005 193 1.4 Abbreviations 195 --------|---------------------------------------------------------- 196 ESMTP |Extended Simple Mail Transfer Protocol. The use of 197 |features and capabilities added to SMTP since RFC 821. 198 --------|---------------------------------------------------------- 199 MSA |Message Submission Agent. A server which accepts messages 200 |from User Agents and processes them; either delivering 201 |them locally or relaying to an MTA. 202 --------|---------------------------------------------------------- 203 MTA |Mail Transfer Agent. A server which implements [SMTP]. 204 --------|---------------------------------------------------------- 206 1.5 Assumptions 208 It is assumed that the reader is already familiar with the contents 209 of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 210 (requirements) [Stage_1] and Stage 2 (architecture and abstract 211 messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] 212 documents. It is also assumed that the reader is familiar with 213 Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt]. 215 2 Mapping Between MMS and Internet Mail 217 This section defines the interworking between MMS Relay/Servers and 218 External Servers using native ESMTP. That is, information elements 219 are exchanged using standard Internet Message [Msg-Fmt] header 220 fields and standard [SMTP] elements. 222 SMTP and Internet mail extensions are used for features such as 223 delivery reports, message expiration, discovery of server support 224 for optional features, etc. 226 2.1 Mapping Specification 228 2.1.1 MMS to Internet Mail 230 When sending a message to an Internet mail system the MMS 231 Relay/Server MUST convert the MM if required, and MUST comply with 232 the requirements of [SMTP] (for example, use of a null return-path 233 for automatically-generated messages). 235 The MMS Relay/Server SHOULD use the information elements associated 236 with the MM to define the control information (Internet Message 237 header fields and ESMTP values) needed for the transfer protocol. 239 Gellens [Page 6] Expires April 2005 240 Section 2.1.3 lists the mappings between X-Mms-* headers and 241 Internet Message header fields and ESMTP values. 243 Delivery and read report MMs SHOULD be converted to standard 244 Internet Message report format (multipart/report). In addition to 245 converting Internet Message reports, the MMS Relay/Server MUST 246 generate delivery and read report MMs for received messages as 247 appropriate. See section 2.1.4 for more information. 249 2.1.2 Internet Mail to MMS 251 When receiving a message from an Internet mail system the MMS 252 Relay/Server MAY convert incoming messages to the MM format used 253 within the receiving system. 255 The MMS Relay/Server MAY convert control information received from 256 the Internet mail server into appropriate information elements of an 257 MM. 259 Section 2.1.3 lists the mappings between X-Mms-* headers and 260 Internet Message header fields and ESMTP values. 262 Standard Internet Message report format (multipart/report) messages 263 MAY be converted to delivery or read report MMs, as appropriate. In 264 addition to converting report MMs, the MMS Relay/Server MUST 265 generate standard Internet Message delivery and disposition reports 266 for received Internet messages as appropriate. See section 2.1.4 267 for more information. 269 Gellens [Page 7] Expires April 2005 270 2.1.3 MMS Information Element Mappings 272 The mappings between MMS elements and ESMTP/Internet Message 273 elements (either [SMTP] parameters, [Msg-Fmt] headers, or both) are 274 summarized in the table below, and detailed in subsequent sections. 275 The "MMS Headers" are from [OMA-MMS]. Note that only information 276 elements which need to be mapped are listed. [Msg-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 in | 305 |("<>") for all |anonymous mes- | 306 |automatically- |sages when | 307 |generated MMs |receiving sys- | 308 | |tem does not | 309 | |support anony- | 310 | |mous messages) | 311 _________________|_________________|________________|______________ 312 Content type |N/A |Content-Type: |Content-type: 313 | | | 314 | |For voice mes- | 315 | |sages compliant | 316 | |to [VPIM], see | 317 | |Note 2 | 318 =================|=================|================|============== 320 Gellens [Page 8] Expires April 2005 321 =================|=================|================|============== 322 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 323 =================|=================|================|============== 324 Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- 325 |MUST set MAIL | dence: bulk' | Class: 326 |FROM to null |on class=auto | 327 |("<>"). | | 328 _________________|_________________|________________|______________ 329 Date and time |N/A |Date: |Date: 330 of submission | | | 331 _________________|_________________|________________|______________ 332 Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry: 333 |[Deliver-By] | | 334 _________________|_________________|________________|______________ 335 Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery 336 ery time |sion; not relay) | | -Time: 337 _________________|_________________|________________|______________ 338 Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery 339 request |SHOULD also | | -Report: 340 |specify recip- | | 341 |ient address as | | 342 |ORCPT; SHOULD | | 343 |also specify | | 344 |ENVID | | 345 _________________|_________________|________________|______________ 346 Importance (a/k/a|N/A |Importance: |X-Mms- 347 "priority") | |X-Priority: | Priority: 348 | | | 349 | | | 350 _________________|_________________|________________|______________ 351 Sender visib- |X-ANONYMOUS (see |N/A |X-Mms-Sender- 352 ility |text below) | | Visibility: 353 _________________|_________________|________________|______________ 354 Read reply |N/A |Disposition- |X-Mms-Read- 355 request | | Notification | Reply: 356 | | -To: [MDN] | 357 _________________|_________________|________________|______________ 358 Reply-charging |(not currently |(not currently |X-Mms-Reply- 359 permission |supported) |supported) | Charging: 360 _________________|_________________|________________|______________ 361 Reply-charging |(not currently |(not currently |X-Mms-Reply- 362 permission |supported) |supported) | Charging- 363 deadline | | | Deadline: 364 _________________|_________________|________________|______________ 365 Reply-charging |(not currently |(not currently |X-Mms-Reply- 366 permission |supported) |supported) | Charging- 367 limitation | | | Size: 368 =================|=================|================|============== 370 Gellens [Page 9] Expires April 2005 371 =================|=================|================|============== 372 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 373 =================|=================|================|============== 374 Reply-charging |(not currently |(not currently |X-Mms-Reply- 375 usage request |supported) |supported) | Charging- 376 | | | Id: 377 _________________|_________________|________________|______________ 378 Reply-charging |(not currently |(not currently |X-Mms-Reply- 379 usage reference |supported) |supported) | Charging: 380 _________________|_________________|________________|______________ 381 Subject |N/A |Subject: |Subject: 382 _________________|_________________|________________|______________ 383 Forward counter |N/A |Resent-Count: |(Not sup- 384 | | |ported) 385 _________________|_________________|________________|______________ 386 Previously-sent- |N/A |Resent-From: |X-Mms-Previous 387 by | | | ly-Sent-By: 388 _________________|_________________|________________|______________ 389 Previously-sent- |N/A |Resent-Date: |X-Mms- 390 date and-time | | | Previously- 391 | | | Sent-Date: 392 _________________|_________________|________________|______________ 393 Hop/host trace |N/A |Received: |(Not sup- 394 | | |ported) 395 _________________|_________________|________________|______________ 396 Sensitivity |N/A |Sensitivity: see|N/A 397 | |Note 1 | 398 _________________|_________________|________________|______________ 399 Content |N/A | | 400 =================|=================|================|============== 402 Note 1: The [VPIM] 'Sensitivity' header element indicates the 403 privacy requested by the message originator (values are �personal� 404 or �private�); a message recipient MUST NOT forward a message with a 405 'Sensitivity' header. 407 Note 2: A MIME-Version header with a comment of �Voice 2.0� 408 indicates that the voice message conforms to [VPIM]. 410 2.1.3.2 Conversion of messages from MMS to Internet format 412 3GPP MMS Version 414 The 'X-Mms-Version:' header, if present, SHOULD be removed. 416 Gellens [Page 10] Expires April 2005 417 Message Type (of PDU) 419 The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. 421 Transaction ID 423 The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. 425 Message ID 427 An 'X-Mms-Message-Id:' header, if present, SHOULD be retained. 429 The 'Message-Id:' header MUST be retained. If not present it MUST 430 be created, with a unique value. If an 'X-Mms-Message-Id:' header 431 is present and a 'Message-Id:' header is not, the value of the 432 'X-Mms-Message-Id:' header MAY be used in creating the 'Message-Id:' 433 header. 435 The message ID SHOULD be transmitted in the ESMTP envelope as the 436 ENVID parameter, as specified in [DSN-SMTP]. 438 Recipient(s) address 440 The address of each recipient MUST be transmitted in the SMTP 441 envelope as a RCPT TO value. All disclosed recipients SHOULD also 442 appear in a 'To:' or 'Cc:' header. At least one 'To:' or 'Cc:' 443 header MUST be present. If all recipients are undisclosed, a 'To:' 444 header MAY be created that contains a comment, for example 'To: 445 (undisclosed recipients)'. The 'To:' header SHOULD NOT appear more 446 than once. The 'Cc:' header SHOULD NOT appear more than once. 448 Each recipient address MUST obey the length restrictions per [SMTP]. 450 Current Internet message format requires that only 7-bit US-ASCII 451 characters be present in addresses. Other characters (for example, 452 non-7-bit characters in a phrase part of an address header) MUST be 453 encoded according to [Hdr-Enc]. Note that it would be possible to 454 define an SMTP extension to permit transmission of unencoded 8-bit 455 characters, but in the absence of such an extension [Hdr-Enc] MUST 456 be used. 458 Sender address 460 The address of the message sender SHOULD appear in the 'From:' 461 header, unless address hiding has been requested. If address hiding 462 has been requested, the 'From:' header MAY contain a comment to this 463 effect, for example, 'From: (anonymous sender)'. 465 Gellens [Page 11] Expires April 2005 466 The address of the message sender for all user-generated messages 467 ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the SMTP 468 envelope as the MAIL FROM value unless address hiding has been 469 requested and the receiving server is not known and trusted to 470 support address hiding. 472 The 'From:' header and the MAIL FROM value MAY be set to a 473 locally-generated value to hide the sender identity in anonymous 474 messages when the receiving system does not support anonymous 475 messages. Locally generated addresses MAY be internally mapped to 476 the actual address to allow replies to anonymous messages, but such 477 mapping is beyond the scope of this specification. 479 Because of the risk of mail loops, it is critical that the MAIL FROM 480 be set to null ("<>") for all automatically-generated MMs (such as 481 'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to 482 null for all automatically-generated messages. This includes 483 reports, "out-of-office" replies, etc. 485 Current Internet message format requires that only 7-bit US-ASCII 486 characters be present in addresses. Other characters (for example, 487 non-7-bit characters in a phrase part of an address header) MUST be 488 encoded according to [Hdr-Enc]. Note that it would be possible to 489 define an SMTP extension to permit transmission of unencoded 8-bit 490 characters, but in the absence of such an extension [Hdr-Enc] MUST 491 be used. 493 The sender address MUST obey the length restrictions of [SMTP]. 495 Content type 497 The 'Content-Type:' header SHOULD be preserved. Content types not 498 in widespread use in the Internet MAY be converted into those that 499 are, when such conversion can be done without significant loss of 500 content. For example, SMIL messages MAY be converted into 501 widely-supported multipart/related with multipart/html. When such 502 conversion is done, the 'Content-Type:' header MUST be updated if it 503 is no longer correct. 505 Message class 507 The 'X-Mms-Message-Class:' header MAY be retained. A 'Precedence: 508 bulk' header MAY be inserted for class=auto or class=advertisement. 509 See 'Sender Address' above. (Class=personal and class=informational 510 do not require special handling.) 512 Gellens [Page 12] Expires April 2005 513 Time of Expiry 515 The 'X-Mms-Expiry:' header, if present, SHOULD be removed. 517 The remaining time until the message is considered expired SHOULD be 518 transmitted in the ESMTP envelope by using the DELIVER-BY extension, 519 as specified in [Deliver-By]. 521 Note that the ESMTP DELIVER-BY extension carries time remaining 522 until expiration; each server decrements the value by the amount of 523 time it has possessed the message. The 'X-Mms-Expiry:' header may 524 contain either the absolute time at which the message is considered 525 expired or the relative time until the message is considered 526 expired. 528 Earliest delivery time 530 The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed. 532 Future delivery is a message submission, not message relay feature. 534 Delivery report request 536 Requests for delivery status notifications (DSNs) SHOULD be 537 transmitted in the ESMTP envelope by using the DSN extension as 538 specified in [DSN-SMTP] to request "success" or "none" notification 539 (depending on the value of the 'X-Mms-Delivery-Report' header). 540 When the NOTIFY extension is used, the unaltered recipient address 541 SHOULD be transmitted as the ORCPT value, and the original message 542 ID SHOULD be transmitted as the ENVID value. 544 The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed. 546 Importance 548 The message sender's importance value (also called "priority", 549 although this can be confused with class-of-service values) SHOULD 550 be transmitted using an 'Importance:' header (although currently not 551 all Internet mail clients support this header). 553 An 'X-Priority:' header MAY be used in addition. Although not 554 standardized, most email applications support the 'X-Priority:' 555 header, and use an 'X-Priority' value of 3 for messages with 556 "normal" priority. More important messages have lower values and 557 less important message have higher values. In most cases, urgent 558 messages have an X-Priority value of 1. 560 Gellens [Page 13] Expires April 2005 561 Suggested mappings: 563 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message) 565 ---------------------------|------------------ 566 'X-Mms-Priority: High' |'Importance: High' 567 ---------------------------|------------------ 568 'X-Mms-Priority: Normal' |[omit] 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 Requests for sender address hiding may be transmitted in the ESMTP 592 envelope by using the X-ANONYMOUS extension. The request is made by 593 adding "X-ANONYMOUS" to the MAIL FROM command. Servers which 594 support address hiding may advertise this by including X-ANONYMOUS 595 in their EHLO response. 597 Note that even if servers claim to support address hiding, there is 598 no technical guarantee that it will be properly honored; servers 599 MUST NOT trust other servers to support this without a basis which 600 is beyond the scope of this specification (such as business 601 relationships). 603 The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be 604 removed. 606 Read reply request 608 Gellens [Page 14] Expires April 2005 609 A request for a read reply SHOULD be transmitted using a 610 'Disposition-Notification-To:' header as specified in [MDN]. 612 The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed. 614 Reply-charging 616 Reply charging permission and acceptance are complex issues 617 requiring both user agent and server support. Misapplied reply 618 charging may cause incorrect billing. Until the security issues 619 have been properly addressed, reply charging SHOULD NOT be honored 620 when using this interface. 622 The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 623 'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers 624 MAY be removed. Messages containing a reply-charging usage request 625 ('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or 626 'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be 627 rejected. 629 Subject 631 The 'Subject:' header MUST be preserved. Current Internet message 632 format requires that only 7-bit US-ASCII characters be present. 633 Other characters must be encoded according to [Hdr-Enc]. Note that 634 it would be possible to define an SMTP extension to permit 635 transmission of unencoded 8-bit characters, but in the absence of 636 such an extension [Hdr-Enc] must be used. 638 Resending/Forwarding 640 In MMS a message may be resent or forwarded, the difference being 641 that if the message has been downloaded then sending it to another 642 address is considered forwarding, while sending a message that has 643 not been downloaded is considered to be resending. 645 In Internet mail there are two primary ways of sending a previously 646 received message to a new recipient: forwarding and resending. 647 Forwarding is when a user creates a new message containing the 648 original message, either simply embedded within the text, or 649 delineated. Embedded messages generally have each original line 650 preceded by a quote symbol ('>'), surround the original text with a 651 preceding and trailing line which starts with hyphens as per 652 [Msg-Encap], such as '--- begin forwarded text' and '--- end 653 forwarded text', or encapsulate the original message as a 654 'message/rfc822' content type, perhaps within a 'multipart/mixed' 655 message. (This last method offers more robust delineation.) 656 Resending is when the original message is unaltered except for the 657 addition of 'Resent-' headers to explain the resending to the new 659 Gellens [Page 15] Expires April 2005 660 recipient. 662 A message may be resent more than once; each time new 'Resent-' 663 headers SHOULD be added at the top of the message. Thus, if more 664 than one series of 'Resent-' headers are present, the original 665 series is the last; the most recent is the first. 667 Forward counter 669 The 'Resent-Count:' header MAY be used to track the number of times 670 the message has been resent. Note that loop control is often done 671 by counting 'Received' headers, which are more general than 672 'Resent-' headers. 674 Previously-sent Information 676 A 'Resent-From:' header MAY be added to indicate the address of the 677 user who directed the message to be resent. 679 A 'Resent-Date:' header SHOULD be added to indicate the time and 680 date that the message was resent. 682 Any 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date' 683 headers, if present, SHOULD be removed. The information contained 684 in them SHOULD be translated into 'From:', 'Resent-To:', 685 'Resent-From:', 'Resent-Date:', and 'Resent-Count:' headers. The 686 original sender of the message SHOULD appear in the 'From:' header; 687 the original recipient(s) SHOULD appear in the 'To:' header; the 688 time and date the message was originally sent SHOULD appear in the 689 'Date:' header. The most recent sender SHOULD appear in the 690 top-most 'Resent-From:' header; the most recent recipient(s) SHOULD 691 appear in the top-most 'Resent-To:' header; the time and date the 692 message was most recently sent SHOULD appear in the top-most 693 'Resent-Date:' header. 695 'Received:' Headers 697 Each system that processes a message SHOULD add a 'Received:' header 698 as per [SMTP]. A message MAY be rejected if the number of 699 'Received:' headers exceeds a locally-defined maximum, which MUST 700 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 702 Privacy 704 Note that MMS systems do not currently support the 'Privacy' header 705 field as described by [VPIM]. 707 Gellens [Page 16] Expires April 2005 708 Content 710 The message content appears in the message body. Note that Internet 711 message format requires that line-endings be encoded as CR LF, thus 712 charset encodings that do not have this property cannot be used in 713 text/* body parts. (They MAY be used in other body parts, but only 714 when they are suitable encoded or when binary transmission has been 715 negotiated.) In particular, MMS allows UTF-16, while Internet 716 message format does not. UTF-16 encoding MUST be translated to 717 UTF-8 or another charset and encoding which is suitable for use in 718 Internet message format/protocols. 720 2.1.3.3 Conversion of messages from Internet to MMS format 722 3GPP MMS Version 724 An 'X-Mms-Mms-Version:' header SHOULD be added. 726 Message Type (of PDU) 728 An 'X-Mms-Message-Type:' header SHOULD be used in accordance with 729 the specific MMS interface (e.g., MM1, MM4). 731 Transaction ID 733 An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with 734 the specific MMS interface (e.g., MM1, MM4). 736 Message ID 738 The 'Message-Id:' header MUST be retained. If not present it MUST 739 be created, with a unique value. If the 'Message-Id:' header does 740 not exist, but the SMTP envelop contains an ENVID value (as 741 specified in [DSN-SMTP]), it MAY be used to construct the value. 743 Recipient(s) address 745 'To:' and 'Cc:' headers MUST be retained. 747 Each recipient contained in the SMTP envelope (RCPT TO values) MUST 748 be considered a recipient of the message. Recipients who appear in 749 address headers but not the SMTP envelope MUST be ignored. 750 Recipients who appear in the [SMTP] envelope but do not appear in 751 headers are considered "blind" (Bcc) recipients; such recipients 752 MUST NOT be added to message headers (including address and trace 753 headers) unless there is only one recipient total. 755 Gellens [Page 17] Expires April 2005 756 Sender address 758 The 'From:' header MUST be retained. 760 If address hiding has been requested, the 'From:' header MAY contain 761 a comment to this effect, for example, 'From: (anonymous sender)'. 763 Content type 765 The complete 'Content-Type:' header (including any parameters) 766 SHOULD be preserved. 768 Message class 770 An X-Mms-Message-Class: personal' header SHOULD be created for all 771 received messages with a non-null return path (MAIL FROM value in 772 the SMTP envelope). An X-Mms-Message-Class: auto' header MAY be 773 created for messages with a null return path. 775 Time of Expiry 777 An 'x-Mms-Expiry:' header SHOULD be created if the message contains 778 a relative time to expiration in the DELIVER-BY extension, as 779 specified in [Deliver-By]. 781 Earliest delivery time 783 An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. If a 784 message arrives via ESMTP relay containing an earliest time of 785 delivery in the AFTER extension, it MAY be rejected. If a message 786 is submitted via Message Submission [Submission] containing an 787 earliest time of delivery in the AFTER extension, it MUST either be 788 retained until the delivery time arrives, or it may be immediately 789 rejected. It MUST NOT be delivered or further relayed prior to the 790 delivery time. 792 Delivery report request 794 An 'X-Mms-Delivery-Report:' header SHOULD be created for messages 795 which request 'success' or 'none' delivery status notification by 796 use of the DSN extension as specified in [DSN-SMTP]. Requests for 797 'delay' notifications or non-default actions, such as that only the 798 message headers should be returned, cannot be mapped onto MMS 799 headers and thus SHOULD be ignored. 801 Priority 803 Gellens [Page 18] Expires April 2005 804 An 'X-Priority:' or 'Importance:' header, if present, SHOULD be 805 replaced with an 'X-Mms-Priority:' header. Suggested mappings: 807 2.1.3.3.1 Table 4: Priority Mappings (Internet Message to MMS) 809 -------------------------------|---------------------- 810 'X-Priority: 1 (highest)' |'X-Mms-Priority: High' 811 -------------------------------|---------------------- 812 'X-Priority: 2 (high)' |'X-Mms-Priority: High' 813 -------------------------------|---------------------- 814 'Importance: High' |'X-Mms-Priority: High' 815 -------------------------------|---------------------- 816 'X-Priority: 3 (normal)' | [omitted] 817 -------------------------------|---------------------- 818 'Importance: Normal' | [omitted] 819 -------------------------------|---------------------- 820 'X-Priority: 4 (low)' |'X-Mms-Priority: Low' 821 -------------------------------|---------------------- 822 'Importance: Low' |'X-Mms-Priority: Low' 823 -------------------------------|---------------------- 824 'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low' 825 -------------------------------|---------------------- 827 Normal priority messages SHOULD omit the 'X-Mms-Priority:' header. 829 Sender visibility 831 Requests for sender address hiding MAY be received in the SMTP 832 envelope by the X-ANONYMOUS extension. Servers which support 833 address hiding MAY advertise this by including X-ANONYMOUS in their 834 EHLO response. A message received which includes X-ANONYMOUS in the 835 MAIL FROM command has requested address hiding. 837 Note that even if servers claim to support address hiding, there is 838 no technical guarantee that it will be properly honored; servers 839 SHOULD NOT trust other servers to support this without a basis which 840 is beyond the scope of this specification (such as business 841 relationships). 843 Requests for sender address hiding MAY be reflected in the created 844 MM by adding an 'X-Mms-Sender-Visibility:' header. 846 Read reply request 848 A request for a read reply contained in a 849 'Disposition-Notification-To:' header as specified in [MDN] SHOULD 850 be replaced with an 'X-Mms-Read-Reply:' header. 852 Gellens [Page 19] Expires April 2005 853 Subject 855 The 'Subject:' header MUST be preserved. 857 Resending/Forwarding 859 One or more sets of 'Resent-' headers, if present, SHOULD be mapped 860 to 'To:', 'From:', 'Date:', and 'X-Mms-Previously-Sent-' headers. 862 'Received:' Headers 864 Each system that processes a message SHOULD add a 'Received:' header 865 as per [SMTP]. A message MAY be rejected if the number of 866 'Received:' headers exceeds a locally-defined maximum, which MUST 867 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 869 Sensitivity 871 The 'Sensitivity:' header field (value = �personal� or �private�) 872 [VPIM] indicates the desire of a voice message originator to send 873 the message contents to the original recipient list with assurance 874 that the message will not be forwarded further by either the 875 messaging system or the actual message recipient(s). Since 876 sensitivity is not an MMS feature, any messages which contain a 877 'Sensitivity:' header SHOULD NOT be sent to an MMS system. An 878 appropriate extended error response code [RESP] SHOULD be used in 879 the associated negative delivery status report. 881 Content 883 The message content appears in the message body. 885 2.1.4 Report Generation and Conversion 887 Internet Message systems use the multipart/report MIME type for 888 delivery and disposition reports (often called "read reports") as 889 specified in [Report-Fmt]. This format is a two- or three-part MIME 890 message; one part is a structured format describing the event being 891 reported in an easy-to-parse format. Specific reports have a format 892 which is built on [Report-Fmt]. Delivery reports are specified in 893 [DSN-Msg]. Message disposition reports, which include read reports, 894 are specified in [MDN]. 896 By contrast, MMS reports are plain text, with no defined structure 897 specified. This makes it difficult to convert from an MMS report to 898 a standard Internet report. 900 Gellens [Page 20] Expires April 2005 901 An MMS Relay/Server supporting Internet Message exchange using MM3 902 MUST convert reports received from one side (MMS or Internet mail) 903 destined for the other. In addition, reports MUST be generated as 904 appropriate for messages received from either side of the MM3 905 interface. For example, if an MM to be sent via MM3 is not 906 deliverable, a delivery status MM shall be generated. Likewise, if 907 an Internet message is received via MM3 that cannot be further 908 relayed or delivered, a delivery status report [DSN-Msg] MUST be 909 generated. 911 When creating delivery or disposition reports from MMS reports, the 912 MMS report should be parsed to determine the reported event and 913 time, status, and the headers of the referenced (original) message. 914 These elements, once determined, are used to populate the subparts 915 of the delivery or disposition report. The first subpart is of type 916 text/plain, and contains a human-readable explanation of the event. 917 This text may include a statement that the report was synthesized 918 based on an MMS report. The second subpart is of type 919 report/delivery-status (for delivery reports) or 920 report/disposition-notification (for disposition reports). This 921 second part contains a structured itemization of the event. The 922 third subpart is of type message/rfc822 and includes the headers and 923 optionally the body of the referenced (original) message. 925 2.1.4.1 Delivery Report Mapping from MMS to Internet Message 927 The following table maps information elements from MMS delivery 928 reports to the format specified in [DSN-Msg]. 930 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message) 932 ======================|============|=================================== 933 Information Element |MMS Delivery|[DSN-Msg] Element 934 |Report Elem | 935 ======================|============|=================================== 936 ID of message whose |Message-Id: |'Original-Envelope-ID' field of 937 delivery status is | |per-message fields (use value of 938 being reported | |ENVID from ESMTP envelope if avail- 939 | |able, 'Message-ID:' otherwise). 940 ----------------------|------------|----------------------------------- 941 Recipient address of |From: |'Final-Recipient' field of the 942 the original message | |per-recipient section 943 (object of delivery | | 944 report) | | 945 ======================|============|=================================== 947 Gellens [Page 21] Expires April 2005 948 ======================|============|=================================== 949 Information Element |MMS Delivery|[DSN-Msg] Element 950 |Report Elem | 951 ======================|============|=================================== 952 Destination address of|To: |'To:' header field value of top- 953 report | |level. 954 | | 955 | |Value taken from [SMTP] envelope 956 | |return-path of message being 957 | |reported, not its 'From:' header 958 | |field. 959 ----------------------|------------|----------------------------------- 960 Date and time the |Date: |'Date:' header field value of top- 961 message was handled | |level 962 ----------------------|------------|----------------------------------- 963 Delivery status of |X-Mms- |Action and Status fields of 964 original message | Status: |per-recipient section. 965 | | 966 | |The 'Action' field indicates if the 967 | |message was delivered. 968 | | 969 | |For failed delivery an appropriate 970 | |'Status' value shall be included 971 | |per [DSN-Msg]. 972 | | 973 | |The Action field is set to one of 974 | |the following values: 975 | | 976 | |* delivered (used for MMS status 977 | |values 'retrieved' and 'rejected', 978 | |depending on 'Status' code). 979 | | 980 | |* failed (used for MMS status 981 | |values 'expired' and 'unreachable') 982 | | 983 | |* delayed MAY be used for MMS 984 | |status value 'deferred' 985 | | 986 | |* relayed (used for MMS status 987 | |value 'indeterminate') 988 | | 989 | |* expanded (SHOULD NOT be used) 990 ----------------------|------------|----------------------------------- 991 Status Text | |Text in first part (human-readable 992 | |part) 993 ----------------------|------------|----------------------------------- 995 Gellens [Page 22] Expires April 2005 996 When an MMS Relay/Server generates a [DSN-Msg] in response to a 997 message received using [SMTP] on MM3: 999 * Top-level header field 'To:' SHOULD be the [SMTP] return-path of 1000 the message whose status is being reported. 1002 * Top-level header field 'From:' SHOULD be the address of the 1003 recipient that the delivery-report concerns. 1005 * The first part of the [DSN-Msg] SHOULD include the MM Status Text 1006 field that would have been generated for an MM1 delivery-report. 1008 2.1.4.2 Delivery Report Mapping from Internet Message to MMS 1010 The following table maps information elements from a delivery report 1011 as specified in [DSN-Msg] to the format of an MMS delivery report. 1013 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS) 1015 ===================|==================|================================ 1016 Information Element|MMS Delivery |[DSN=Msg] Element 1017 |Report Element | 1018 ===================|==================|================================ 1019 ID of the original |Message-Id: |'Original-Envelope-ID' field of 1020 message (object of | |per-message fields. If not 1021 delivery report) | |available, the 'Message-ID' 1022 | |header field of the message 1023 | |being reported, if included in 1024 | |the third part, may be 1025 | |substituted. 1026 -------------------|------------------|-------------------------------- 1027 Recipient address |From: |If available, the 'Original 1028 of the original | |-Recipient' field of the per- 1029 message (object of | |recipient section should be 1030 delivery report) | |used; otherwise the 'Final- 1031 | |Recipient' field of the per- 1032 | |recipient section is used 1033 -------------------|------------------|-------------------------------- 1034 Destination address|To: |'To:' header field value of 1035 of report | |top-level. 1036 | | 1037 | |Value taken from [SMTP] envelope 1038 | |return-path of message being 1039 | |reported, not its 'From:' header 1040 | |field. 1041 ===================|==================|=================================== 1043 Gellens [Page 23] Expires April 2005 1044 ===================|==================|================================ 1045 Information Element|MMS Delivery |[DSN=Msg] Element 1046 |Report Element | 1047 ===================|==================|================================ 1048 Date and time the |Date: |'Date:' header field value of 1049 message was handled| |top-level 1050 -------------------|------------------|-------------------------------- 1051 Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of 1052 original message | |per-recipient section 1053 |Set to one of the | 1054 |following values: | 1055 | | 1056 |'retrieved' (used | 1057 |for 'Action' value| 1058 |'delivered'). | 1059 | | 1060 |'unreachable' | 1061 |(used for 'Action'| 1062 |value 'failed') | 1063 | | 1064 |'forwarded' (used | 1065 |for 'Action' value| 1066 |'relayed') | 1067 | | 1068 |'deferred' MUST | 1069 |NOT be used | 1070 |(ignore DSNs with | 1071 |'Action' value | 1072 |'delayed') | 1073 -------------------|------------------|-------------------------------- 1074 Status Text | |Text in first part (human- 1075 | |readable part) 1076 ===================|==================|================================ 1078 Gellens [Page 24] Expires April 2005 1079 2.1.4.3 Read Report Mapping from MMS to Internet Message 1081 The following table maps information elements from MMS read reports 1082 to the format specified in [MDN]. 1084 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 1086 ======================|============|=================================== 1087 Information Element |MMS Delivery|[DSN-Msg] Element 1088 |Report Elem | 1089 ======================|============|=================================== 1090 ID of the original |Message-Id: |'Original-Envelope-ID' field (use 1091 message (object of | |value of ENVID from ESMTP envelope 1092 read report) | |if available, 'Message-ID:' 1093 | |otherwise). 1094 ----------------------|------------|----------------------------------- 1095 Recipient address of |From: |'Final-Recipient' field 1096 the original message | | 1097 ----------------------|------------|----------------------------------- 1098 Destination address of|To: |'To:' header field value of top- 1099 report | |level. 1100 | | 1101 | |Value taken from 'Disposition- 1102 | |Notification-To:' header field of 1103 | |message being reported, not its 1104 | |'From:' header field. 1105 ----------------------|------------|----------------------------------- 1106 Date and time the |Date: |'Date:' header field value of top- 1107 message was handled | |level 1108 ----------------------|------------|----------------------------------- 1109 Disposition of message|X-Mms-Read- |Disposition-field 1110 being reported | Status: | 1111 | |For MMS-Read-Status value 'read', 1112 | |use 'disposition-type' value 1113 | |'displayed'; for MMS-Read-Status 1114 | |value 'Deleted without being read', 1115 | |use 'disposition-type' value 1116 | |'deleted') 1117 ----------------------|------------|----------------------------------- 1118 Status Text | |Text in first part (human-readable 1119 | |part) 1120 ======================|============|=================================== 1122 When an MMS Relay/Server generates an [MDN] in response to a message 1123 received using ESMTP on MM3: 1125 Gellens [Page 25] Expires April 2005 1126 * Top-level header field 'To:' SHOULD be the value of the 1127 'Disposition-Notification-To:' header field of the message whose 1128 disposition is being reported . 1130 * Top-level header field 'From:' SHOULD be the address of the 1131 recipient that the read report concerns. 1133 2.1.4.4 Disposition Report Mapping from Internet Message to MMS 1135 The following table maps information elements from a disposition 1136 report as specified in [MDN] to the format of an MMS read report. 1138 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet Message to 1139 MMS) 1141 ===================|==================|================================ 1142 Information Element|MMS Read Report |[DSN=Msg] Element 1143 |Element | 1144 ===================|==================|================================ 1145 ID of the original |Message-Id: |'Original-Envelope-ID' field 1146 message (object of | | 1147 disposition report)| | 1148 -------------------|------------------|-------------------------------- 1149 Recipient address |From: |'Final-Recipient' field 1150 of the original | | 1151 message | | 1152 -------------------|------------------|-------------------------------- 1153 Destination address|To: |'To:' header field value of 1154 of report | |top-level. 1155 | | 1156 | |Value taken from 'Disposition- 1157 | |Notification-To:' header field 1158 | |of message being reported, not 1159 | |its 'From:' header field. 1160 -------------------|------------------|-------------------------------- 1161 Date and time the |Date: |'Date:' header field value of 1162 message was handled| |top-level 1163 ===================|==================|================================ 1165 Gellens [Page 26] Expires April 2005 1166 ===================|==================|================================ 1167 Information Element|MMS Read Report |[DSN=Msg] Element 1168 |Element | 1169 ===================|==================|================================Disposition of |X-Mms-Read-Status:|disposition-field 1170 message being | | 1171 reported |Set to one of the | 1172 |following values: | 1173 | | 1174 |'read' (used for | 1175 |disposition-type | 1176 |value 'displayed')| 1177 | | 1178 |'Deleted without | 1179 |being read' (used | 1180 |for disposition- | 1181 |types 'deleted', | 1182 |'denied' and | 1183 |'failed' when | 1184 |action-mode is | 1185 |'automatic- | 1186 |action') | 1187 -------------------|------------------|-------------------------------- 1188 Status Text | |Text in first part (human- 1189 | |readable part) 1190 ===================|==================|================================ 1192 2.1.5 Message Delivery 1194 Within Internet mail, when ESMTP is used and delivery reports are 1195 requested [DSN-SMTP], delivery is considered to be acceptance of a 1196 message by the final server, that is, the server closest to the 1197 recipient. When an MMS Relay/Server receives a message using ESMTP 1198 and a delivery report is requested, the MMS Relay/Server MAY 1199 consider the message delivered when it has been sent to the MMS User 1200 Agent. 1202 3 Security Considerations 1204 Data contained within messages should not be automatically trusted. 1205 Even within a carrier's network, and certainly within the Internet, 1206 various deliberate and accidental attacks or corruptions are 1207 possible. For example, routers may contain vulnerabilities which 1208 may be exploited, IP traffic may be intercepted and/or modified, 1209 etc. 1211 Gellens [Page 27] Expires April 2005 1212 The following messaging-related security threats can be identified: 1214 * Misidentification of message source. 1216 * Message interception (unauthorized disclosure of contents). 1218 * Unauthorized disclosure of message sender or recipient. 1220 * Message modification (by adversary). 1222 * Message replay. 1224 * Traffic analysis (determining who is communicating with whom). 1226 There are existing mechanisms used to protect email traffic against 1227 some of these threats, such as: 1229 * Use of SSL/TLS (via [StartTLS]) to address disclosure and 1230 modification in transit between adjacent servers. 1232 * SMTP Authentication [Auth] to protect against misidentification of 1233 message source. 1235 * Use of end-to-end security mechanisms such as [PGP] or S/MIME 1236 [SMIME] to protect message contents. 1238 * Use of [IPSec] to protect against disclosure or modification in 1239 transit between servers. 1241 These mechanisms SHOULD be employed whenever the required 1242 infrastructure is available, e.g., a certificate infrastructure is 1243 necessary to support S/MIME, or user agent support for PGP is 1244 available. Enabling SMTP Authentication [Auth] and STARTTLS 1245 [StartTLS] are easy measures to deploy and SHOULD be used. 1247 Since MMS does not include a clear separation between in-transit 1248 envelope and message content, there are increased risks of 1249 unauthorized disclosure of information, and additional challenges in 1250 protecting data. For example, Bcc recipients do not normally appear 1251 in the message content, only in the envelope; care MUST be taken in 1252 the gateway function to ensure that Bcc recipients which do appear 1253 are deleted from the message content. 1255 Some MMS features contain inherently more risk than others. For 1256 example, reply charging and sender address hiding. The reply 1257 charging mechanism requires a high degree of trust between entities 1258 with little technical basis. Deliberate or accidental abuse of this 1259 trust can result in unexpected or unauthorized charges. For 1260 example, a sender may be charged for unauthorized replies, or a 1262 Gellens [Page 28] Expires April 2005 1263 sender may be charged for a reply which the author thought would be 1264 paid for by the recipient. A sender's identity may be disclosed in 1265 violation of a request for this to be blocked. The identity of 1266 recipients may be disclosed to other recipients (or even 1267 non-recipients) for a message in which the sender intended for the 1268 recipients not to be disclosed. 1270 It is possible to hide the sender's identity from non-recipients 1271 using anonymous remailers. It is hard to hide the sender's identity 1272 from recipients when the mail is cryptographically signed. In view 1273 of anti-spam measures it may be undesirable to hide the sender's 1274 identity. 1276 Additional mechanisms can be developed to protect against various 1277 threats, however, these are not included in this version of this 1278 specification. It is strongly RECOMMENDED that features such as 1279 reply charging and sender identity hiding not be used across carrier 1280 domains, and be used within carrier domains only with full 1281 understanding of the risks involved. 1283 4 Normative References 1285 IETF: 1287 [DSN-Msg] "An Extensible Message Format for Delivery Status 1288 Notifications", Moore, Vaudreuil, RFC 3464, January 2003. 1290 [DSN-SMTP] "SMTP Service Extension for Delivery Status 1291 Notifications", Moore, RFC 3461, January 2003. 1293 [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: 1294 Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, 1295 November 1996. 1297 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 1298 Requirement Levels", RFC 2119, Harvard University, March 1997. 1300 [MDN] "An Extensible Message Format for Message Disposition 1301 Notifications", Fajman, RFC 2298, March 1998. 1303 [Msg-Fmt] �Internet Message Format�, Resnick, RFC 2822, April 2001. 1305 [Report-Fmt] �The Multipart/Report Content Type for the Reporting of 1306 Mail System Administrative Messages�, Vaudreuil, RFC 3462, January 1307 2003 1309 Gellens [Page 29] Expires April 2005 1311 [RESP] Enhanced Mail System Status Codes, Vaudreuil, RFC 1893, 1312 January 1996. 1314 [SMTP] �Simple Mail Transfer Protocol�, Klensin, RFC 2821, April 1315 2001. 1317 5 Informative References 1319 IETF: 1321 [Auth] "SMTP Service Extension for Authentication", Myers, RFC 2554, 1322 March 1999 1324 [BINARY] SMTP Service Extensions for Transmission of Large and 1325 Binary MIME Messages", Vaudreuil, Parsons, RFC 3030, December 2000. 1327 [Codes] "SMTP Service Extension for Returning Enhanced Error Codes", 1328 Freed, RFC 2034, October 1996. 1330 [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, 1331 June 2000. 1333 [Msg-Encap] "Proposed Standard for Message Encapsulation", Rose, 1334 Stefferud, RFC 934, January 1985. 1336 [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, 1337 February 1997. 1339 [IPSec] "Security Architecture for the Internet Protocol", Kent, 1340 Atkinson, RFC 2401, November 1998 1342 [PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, 1343 Roessler, RFC 3156, August 2001 1345 [SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC 1346 2633, June 1999 1348 [StartTLS] "SMTP Service Extension for Secure SMTP over Transport 1349 Layer Security", Hoffman, RFC 3207, February 2002 1351 [Submission] �Message Submission�, Gellens, Klensin, RFC 2476, 1352 December 1998. 1354 [VPIM] �Voice Profile Internet Mail �- Version 2�, Vaudreuil, 1355 Parsons, RFC 2421, September 1998. 1357 Gellens [Page 30] Expires April 2005 1358 OMA: 1360 OMA specifications are available at the OMA web site 1361 . 1363 [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C 1365 3GPP2 and 3GPP: 1367 3GPP2 specifications are available at the 3GPP2 (Third 1368 Generation Partnership Project 2) web site 1369 . 1371 3GPP specifications are available at the 3GPP (Third Generation 1372 Partnership Project) web site 1374 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310 1376 "MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340 1378 �Multimedia Messaging Service: Functional description; Stage 2�, TS 1379 23.140 Release 5. 1381 [Formats] "Multimedia Messaging Service (MMS) Media Format and 1382 Codecs for cdma2000 Spread Spectrum Systems�, C.S0045 1384 [Overview] "Multimedia Messaging Services (MMS) Overview", 1385 X.S0016-000 1387 [Stage_1] "Multimedia Messaging Services (MMS); Stage 1", 1388 Requirements, October 2002, S.R0064-0. 1390 [Stage_2] �Multimedia Messaging Service (MMS); Stage 2", Functional 1391 Specification, April 2003, X.S0016-200. 1393 "Multimedia Messaging Service; Media formats and codecs", 1394 TS26.140Release 5. 1396 6 Author's Address 1398 Randall Gellens 1399 QUALCOMM Incorporated 1400 5775 Morehouse Drive 1401 San Diego, CA 92121 1402 USA 1403 randy@qualcomm.com 1405 Gellens [Page 31] Expires April 2005 1406 Intellectual Property Statement 1408 The IETF takes no position regarding the validity or scope of any 1409 intellectual property or other rights that might be claimed to 1410 pertain to the implementation or use of the technology described in 1411 this document or the extent to which any license under such rights 1412 might or might not be available; neither does it represent that it 1413 has made any effort to identify any such rights. Information on the 1414 IETF's procedures with respect to rights in standards-track and 1415 standards-related documentation can be found in BCP-11. Copies of 1416 claims of rights made available for publication and any assurances 1417 of licenses to be made available, or the result of an attempt made 1418 to obtain a general license or permission for the use of such 1419 proprietary rights by implementors or users of this specification 1420 can be obtained from the IETF Secretariat. 1422 The IETF invites any interested party to bring to its attention any 1423 copyrights, patents or patent applications, or other proprietary 1424 rights which may cover technology that may be required to practice 1425 this standard. Please address the information to the IETF Executive 1426 Director. 1428 Full Copyright Statement 1430 Copyright (C) The Internet Society (2004). 1432 This document is subject to the rights, licenses and restrictions 1433 contained in BCP 78, and except as set forth therein, the authors 1434 retain all their rights. 1436 Disclaimer 1438 This document and the information contained herein are provided on 1439 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1440 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1441 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1442 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1443 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1444 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1446 Gellens [Page 32] Expires April 2005