idnits 2.17.1 draft-ietf-lemonade-mms-mapping-00.txt: -(1252): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1317): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1328): 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 1382. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1368), 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 8 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.) 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 (July 2004) is 7215 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: 'Codes' is defined on line 1268, but no explicit reference was found in the text == Unused Reference: 'Hdrs' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'Formats' is defined on line 1320, 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 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) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 8 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-00.txt Qualcomm 4 Expires: January 2005 July 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 January 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 January 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 . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 6 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 13 68 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet 13 69 2.1.3.3 Conversion of messages from Internet to MMS format 16 70 2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 18 71 2.1.4 Report Generation and Conversion . . . . . . . . . . 19 72 2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 20 73 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Inte 20 74 2.1.4.2 Delivery Report Mapping from Internet Message to M 22 75 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Me 22 76 2.1.4.3 Read Report Mapping from MMS to Internet Message . 23 77 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet 23 78 2.1.4.4 Disposition Report Mapping from Internet Message t 24 79 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet 24 80 2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . . 25 81 3 Security Considerations . . . . . . . . . . . . . . . . . . . 25 82 4 Normative References . . . . . . . . . . . . . . . . . . . . . 27 83 5 Informative References . . . . . . . . . . . . . . . . . . . 28 84 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 29 85 Intellectual Property Statement . . . . . . . . . . . . . . . 29 86 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 87 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 1 Introduction 91 1.1 Scope 93 This specification describes how to exchange messages with Internet 94 mail 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 January 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 Note that MM3 can also be used for interworking with "external" 110 (non-MMS) systems other than Internet mail, such as Short Messaging 111 Service (SMS) and access to external mail stores (such as a voice 112 mail system). This specification does not address these other uses 113 or sub-interfaces of MM3; it is only concerned with Internet mail 114 interworking and specifically exchange of messages. 116 All MM3 Stage 2 [Stage_2] functions are supported except for reply 117 charging. Sender address hiding may be used but is not recommended 118 without security assurances which are beyond the scope of this 119 specification (see Section 3). 121 1.2 Conventions Used in this Document 123 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 124 NOT", and "MAY" in this document are to be interpreted as described 125 in "Key words for use in RFCs to Indicate Requirement Levels" 126 [KEYWORDS]. 128 Note that in the text of this document, a distinction is made 129 between use of "SMTP" or "Simple Mail Transfer Protocol", and 130 "ESMTP" or "Extended Simple Mail Transfer Protocol": when the term 131 "ESMTP" or "Extended" is used, it indicates use of extended features 132 of SMTP; that is, those beyond the facilities of RFC 821. (These 133 extended facilities may be in RFC 2821 or in other RFCs, as 134 indicated by the specific RFC reference used; note that the name of 135 the RFC 2821 reference is "SMTP" because that is the official title 136 of the RFC.) 138 1.3 Definitions 140 --------------------|---------------------------------------------- 141 Anonymous Remailer |A service which accepts messages and resends 142 |them to their intended recipient, masking 143 |information about the original sender. 144 --------------------|---------------------------------------------- 145 Body |The portion of an SMTP message's Content 146 |following the Header (that is, following the 147 |first blank line). The Body may contain 149 Gellens [Page 4] Expires January 2005 150 |structured parts and sub-parts, each of which 151 |may have their own Header and Body. The Body 152 |contains information intended for the message 153 |recipient (human or software). 154 --------------------|---------------------------------------------- 155 Content |The portion of an SMTP message that is 156 |delivered. The Content consists of a Header 157 |and a Body. 158 --------------------|---------------------------------------------- 159 Disposition Report |Feedback information to an originator User 160 |Agent by a recipient User Agent about 161 Message Disposition |handling of an original message. This may 162 Notification |include notification that the message was or 163 |was not read, was deleted unread, etc. 164 --------------------|---------------------------------------------- 165 Envelope |The portion of an SMTP message not included in 166 |the Content; that is, not in the Header nor in 167 |the Body. Envelope information only exists 168 |while the message is in transit, and contains 169 |information used by SMTP agents (MTAs). 170 --------------------|---------------------------------------------- 171 Header |The first part of an SMTP message's Content. 172 |The Header is separated from the Body by a 173 |blank line. The Header consists of Fields 174 |(such as "To:"), also known as Header Fields 175 |or Headers. The message Header contains 176 |information used by User Agents. 177 --------------------|---------------------------------------------- 178 Gateway Function |An agent which acts as both MMSC and MTA 179 |and/or MSA. 180 --------------------|---------------------------------------------- 181 User Agent |An MMS or Email user agent 182 --------------------|---------------------------------------------- 184 1.4 Abbreviations 186 --------|---------------------------------------------------------- 187 ESMTP |Extended Simple Mail Transfer Protocol. The use of 188 |features and capabilities added to SMTP since RFC 821. 189 --------|---------------------------------------------------------- 190 MSA |Message Submission Agent. A server which accepts messages 191 |from User Agents and processes them; either delivering 192 |them locally or relaying to an MTA. 193 --------|---------------------------------------------------------- 194 MTA |Mail Transfer Agent. A server which implements [SMTP]. 195 --------|---------------------------------------------------------- 197 Gellens [Page 5] Expires January 2005 198 1.5 Assumptions 200 It is assumed that the reader is already familiar with the contents 201 of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 202 (requirements) [Stage_1] and Stage 2 (architecture and abstract 203 messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] 204 documents. It is also assumed that the reader is familiar with 205 Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt]. 207 2 Mapping Between MMS and Internet Mail 209 This section defines the interworking between MMS Relay/Servers and 210 External Servers using native ESMTP. That is, information elements 211 are exchanged using standard Internet Message [Msg-Fmt] header 212 fields and standard [SMTP] elements. 214 SMTP and Internet mail extensions are used for features such as 215 delivery reports, message expiration, discovery of server support 216 for optional features, etc. 218 2.1 Mapping Specification 220 2.1.1 MMS to Internet Mail 222 When sending a message to an Internet mail system the MMS 223 Relay/Server MUST convert the MM if required, and MUST comply with 224 the requirements of [SMTP] (for example, use of a null return-path 225 for automatically-generated messages). 227 The MMS Relay/Server SHOULD use the information elements associated 228 with the MM to define the control information (Internet Message 229 header fields and ESMTP values) needed for the transfer protocol. 231 Section 2.1.3 lists the mappings between X-Mms-* headers and 232 Internet Message header fields and ESMTP values. 234 Delivery and read report MMs SHOULD be converted to standard 235 Internet Message report format (multipart/report). In addition to 236 converting Internet Message reports, the MMS Relay/Server MUST 237 generate delivery and read report MMs for received messages as 238 appropriate. See section 2.1.4 for more information. 240 2.1.2 Internet Mail to MMS 242 Gellens [Page 6] Expires January 2005 243 When receiving a message from an Internet mail system the MMS 244 Relay/Server MAY convert incoming messages to the MM format used 245 within the receiving system. 247 The MMS Relay/Server MAY convert control information received from 248 the Internet mail server into appropriate information elements of an 249 MM. 251 Section 2.1.3 lists the mappings between X-Mms-* headers and 252 Internet Message header fields and ESMTP values. 254 Standard Internet Message report format (multipart/report) messages 255 MAY be converted to delivery or read report MMs, as appropriate. In 256 addition to converting report MMs, the MMS Relay/Server MUST 257 generate standard Internet Message delivery and disposition reports 258 for received Internet messages as appropriate. See section 2.1.4 259 for more information. 261 Gellens [Page 7] Expires January 2005 262 2.1.3 MMS Information Element Mappings 264 The mappings between MMS elements and ESMTP/Internet Message 265 elements (either [SMTP] parameters, [Msg-Fmt] headers, or both) are 266 summarized in the table below, and detailed in subsequent sections. 267 The "MMS Headers" are from [OMA-MMS]. Note that only information 268 elements which need to be mapped are listed. [Msg-Fmt] headers not 269 listed here SHOULD be passed unaltered 271 2.1.3.1 Table 1: MM3 Mappings 273 =================|=================|================|============== 274 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 275 =================|=================|================|============== 276 3GPP MMS Version |N/A |N/A |X-Mms-Version: 277 | | | 278 _________________|_________________|________________|______________ 279 Message Type |N/A |N/A |X-Mms-Message- 280 (of PDU) | | | Type: 281 _________________|_________________|________________|______________ 282 Transaction ID |N/A |N/A |X-Mms-Transact 283 | | | ion-Id: 284 _________________|_________________|________________|______________ 285 Message ID |ENVID [DSN-SMTP] |Message-ID: |X-Mms-Message- 286 | | | Id: 287 | | |Message-ID: 288 _________________|_________________|________________|______________ 289 Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc: 290 address(es) |address(es) |omitted (Bcc) | 291 _________________|_________________|________________|______________ 292 Sender's address |MAIL FROM |From: (MAY set |From: 293 |address if |to locally-gen- | 294 |user-originated; |erated value | 295 |MUST set MAIL |to hide sender | 296 |FROM to null |identity in | 297 |("<>") for all |anonymous mes- | 298 |automatically- |sages when | 299 |generated MMs |receiving sys- | 300 | |tem does not | 301 | |support anony- | 302 | |mous messages) | 303 _________________|_________________|________________|______________ 304 Content type |N/A |Content-Type: |Content-type: 305 _________________|_________________|________________|______________ 306 Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- 307 |MUST set MAIL | dence: bulk' | Class: 308 |FROM to null |on class=auto | 309 |("<>"). | | 310 =================|=================|================|============== 312 Gellens [Page 8] Expires January 2005 313 =================|=================|================|============== 314 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 315 =================|=================|================|============== 316 Date and time |N/A |Date: |Date: 317 of submission | | | 318 _________________|_________________|________________|______________ 319 Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry: 320 |[Deliver-By] | | 321 _________________|_________________|________________|______________ 322 Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery 323 ery time |sion; not relay) | | -Time: 324 _________________|_________________|________________|______________ 325 Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery 326 request |SHOULD also | | -Report: 327 |specify recip- | | 328 |ient address as | | 329 |ORCPT; SHOULD | | 330 |also specify | | 331 |ENVID | | 332 _________________|_________________|________________|______________ 333 Importance (a/k/a|N/A |Importance: |X-Mms- 334 "priority") | |X-Priority: | Priority: 335 | | | 336 | | | 337 _________________|_________________|________________|______________ 338 Sender visib- |X-ANONYMOUS (see |N/A |X-Mms-Sender- 339 ility |text below) | | Visibility: 340 _________________|_________________|________________|______________ 341 Read reply |N/A |Disposition- |X-Mms-Read- 342 request | | Notification | Reply: 343 | | -To: [MDN] | 344 _________________|_________________|________________|______________ 345 Reply-charging |(not currently |(not currently |X-Mms-Reply- 346 permission |supported) |supported) | Charging: 347 _________________|_________________|________________|______________ 348 Reply-charging |(not currently |(not currently |X-Mms-Reply- 349 permission |supported) |supported) | Charging- 350 deadline | | | Deadline: 351 _________________|_________________|________________|______________ 352 Reply-charging |(not currently |(not currently |X-Mms-Reply- 353 permission |supported) |supported) | Charging- 354 limitation | | | Size: 355 _________________|_________________|________________|______________ 356 Reply-charging |(not currently |(not currently |X-Mms-Reply- 357 usage request |supported) |supported) | Charging- 358 | | | Id: 359 =================|=================|================|============== 361 Gellens [Page 9] Expires January 2005 362 =================|=================|================|============== 363 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 364 =================|=================|================|============== 365 Reply-charging |(not currently |(not currently |X-Mms-Reply- 366 usage reference |supported) |supported) | Charging: 367 _________________|_________________|________________|______________ 368 Subject |N/A |Subject: |Subject: 369 _________________|_________________|________________|______________ 370 Forward counter |N/A |Resent-Count: |(Not sup- 371 | | |ported) 372 _________________|_________________|________________|______________ 373 Previously-sent- |N/A |Resent-From: |X-Mms-Previous 374 by | | | ly-Sent-By: 375 _________________|_________________|________________|______________ 376 Previously-sent- |N/A |Resent-Date: |X-Mms- 377 date and-time | | | Previously- 378 | | | Sent-Date: 379 _________________|_________________|________________|______________ 380 Hop/host trace |N/A |Received: |(Not sup- 381 | | |ported) 382 _________________|_________________|________________|______________ 383 Content |N/A | | 384 =================|=================|================|============== 386 2.1.3.2 Conversion of messages from MMS to Internet format 388 3GPP MMS Version 390 The 'X-Mms-Version:' header, if present, SHOULD be removed. 392 Message Type (of PDU) 394 The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. 396 Transaction ID 398 The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. 400 Message ID 402 An 'X-Mms-Message-Id:' header, if present, SHOULD be retained. 404 The 'Message-Id:' header MUST be retained. If not present it MUST 405 be created, with a unique value. If an 'X-Mms-Message-Id:' header 406 is present and a 'Message-Id:' header is not, the value of the 407 'X-Mms-Message-Id:' header MAY be used in creating the 'Message-Id:' 408 header. 410 Gellens [Page 10] Expires January 2005 411 The message ID SHOULD be transmitted in the ESMTP envelope as the 412 ENVID parameter, as specified in [DSN-SMTP]. 414 Recipient(s) address 416 The address of each recipient MUST be transmitted in the SMTP 417 envelope as a RCPT TO value. All disclosed recipients SHOULD also 418 appear in a 'To:' or 'Cc:' header. At least one 'To:' or 'Cc:' 419 header MUST be present. If all recipients are undisclosed, a 'To:' 420 header MAY be created that contains a comment, for example 'To: 421 (undisclosed recipients)'. The 'To:' header SHOULD NOT appear more 422 than once. The 'Cc:' header SHOULD NOT appear more than once. 424 Each recipient address MUST obey the length restrictions per [SMTP]. 426 Current Internet message format requires that only 7-bit US-ASCII 427 characters be present in addresses. Other characters (for example, 428 non-7-bit characters in a phrase part of an address header) MUST be 429 encoded according to [Hdr-Enc]. Note that it would be possible to 430 define an SMTP extension to permit transmission of unencoded 8-bit 431 characters, but in the absence of such an extension [Hdr-Enc] MUST 432 be used. 434 Sender address 436 The address of the message sender SHOULD appear in the 'From:' 437 header, unless address hiding has been requested. If address hiding 438 has been requested, the 'From:' header MAY contain a comment to this 439 effect, for example, 'From: (anonymous sender)'. 441 The address of the message sender for all user-generated messages 442 ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the SMTP 443 envelope as the MAIL FROM value unless address hiding has been 444 requested and the receiving server is not known and trusted to 445 support address hiding. 447 The 'From:' header and the MAIL FROM value MAY be set to a 448 locally-generated value to hide the sender identity in anonymous 449 messages when the receiving system does not support anonymous 450 messages. Locally generated addresses MAY be internally mapped to 451 the actual address to allow replies to anonymous messages, but such 452 mapping is beyond the scope of this specification. 454 Because of the risk of mail loops, it is critical that the MAIL FROM 455 be set to null ("<>") for all automatically-generated MMs (such as 456 'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to 457 null for all automatically-generated messages. This includes 458 reports, "out-of-office" replies, etc. 460 Gellens [Page 11] Expires January 2005 461 Current Internet message format requires that only 7-bit US-ASCII 462 characters be present in addresses. Other characters (for example, 463 non-7-bit characters in a phrase part of an address header) MUST be 464 encoded according to [Hdr-Enc]. Note that it would be possible to 465 define an SMTP extension to permit transmission of unencoded 8-bit 466 characters, but in the absence of such an extension [Hdr-Enc] MUST 467 be used. 469 The sender address MUST obey the length restrictions of [SMTP]. 471 Content type 473 The 'Content-Type:' header SHOULD be preserved. Content types not 474 in widespread use in the Internet MAY be converted into those that 475 are, when such conversion can be done without significant loss of 476 content. For example, SMIL messages MAY be converted into 477 widely-supported multipart/related with multipart/html. 479 Message class 481 The 'X-Mms-Message-Class:' header MAY be retained. A 'Precedence: 482 bulk' header MAY be inserted for class=auto or class=advertisement. 483 See 'Sender Address' above. (Class=personal and class=informational 484 do not require special handling.) 486 Time of Expiry 488 The 'X-Mms-Expiry:' header, if present, SHOULD be removed. 490 The remaining time until the message is considered expired SHOULD be 491 transmitted in the ESMTP envelope by using the DELIVER-BY extension, 492 as specified in [Deliver-By]. 494 Note that the ESMTP DELIVER-BY extension carries time remaining 495 until expiration; each server decrements the value by the amount of 496 time it has possessed the message. The 'X-Mms-Expiry:' header may 497 contain either the absolute time at which the message is considered 498 expired or the relative time until the message is considered 499 expired. 501 Earliest delivery time 503 The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed. 505 Future delivery is a message submission, not message relay feature. 507 Gellens [Page 12] Expires January 2005 508 Delivery report request 510 Requests for delivery status notifications (DSNs) SHOULD be 511 transmitted in the ESMTP envelope by using the DSN extension as 512 specified in [DSN-SMTP] to request "success" or "none" notification 513 (depending on the value of the 'X-Mms-Delivery-Report' header). 514 When the NOTIFY extension is used, the unaltered recipient address 515 SHOULD be transmitted as the ORCPT value, and the original message 516 ID SHOULD be transmitted as the ENVID value. 518 The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed. 520 Importance 522 The message sender's importance value (also called "priority", 523 although this can be confused with class-of-service values) SHOULD 524 be transmitted using an 'Importance:' header (although currently not 525 all Internet mail clients support this header). 527 An 'X-Priority:' header MAY be used in addition. Although not 528 standardized, most email applications support the 'X-Priority:' 529 header, and use an 'X-Priority' value of 3 for messages with 530 "normal" priority. More important messages have lower values and 531 less important message have higher values. In most cases, urgent 532 messages have an X-Priority value of 1. 534 Suggested mappings: 536 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message) 538 ---------------------------|------------------ 539 'X-Mms-Priority: High' |'Importance: High' 540 ---------------------------|------------------ 541 'X-Mms-Priority: Normal' |[omit] 542 ---------------------------|------------------ 543 'X-Mms-Priority: Low' |'Importance: Low' 544 ---------------------------|------------------ 546 Normal priority messages should omit the 'Importance:' header. 548 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet Message) 550 ---------------------------|---------------------- 551 'X-Mms-Priority: High' |'X-Priority: 2 (high)' 552 ---------------------------|---------------------- 553 'X-Mms-Priority: Normal |[omit] 554 ---------------------------|---------------------- 555 'X-Mms-Priority: Low |'X-Priority: 4 (low)' 556 ---------------------------|---------------------- 558 Gellens [Page 13] Expires January 2005 559 Normal priority messages SHOULD omit the 'X-Priority:' header. 561 The 'X-Mms-Priority:' header, if present, SHOULD be removed. 563 Sender visibility 565 Requests for sender address hiding may be transmitted in the ESMTP 566 envelope by using the X-ANONYMOUS extension. The request is made by 567 adding "X-ANONYMOUS" to the MAIL FROM command. Servers which 568 support address hiding may advertise this by including X-ANONYMOUS 569 in their EHLO response. 571 Note that even if servers claim to support address hiding, there is 572 no technical guarantee that it will be properly honored; servers 573 MUST NOT trust other servers to support this without a basis which 574 is beyond the scope of this specification (such as business 575 relationships). 577 The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be 578 removed. 580 Read reply request 582 A request for a read reply SHOULD be transmitted using a 583 'Disposition-Notification-To:' header as specified in [MDN]. 585 The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed. 587 Reply-charging 589 Reply charging permission and acceptance are complex issues 590 requiring both user agent and server support. Misapplied reply 591 charging may cause incorrect billing. Until the security issues 592 have been properly addressed, reply charging SHOULD NOT be honored 593 when using this interface. 595 The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 596 'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers 597 MAY be removed. Messages containing a reply-charging usage request 598 ('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or 599 'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be 600 rejected. 602 Subject 604 The 'Subject:' header MUST be preserved. Current Internet message 605 format requires that only 7-bit US-ASCII characters be present. 606 Other characters must be encoded according to [Hdr-Enc]. Note that 607 it would be possible to define an SMTP extension to permit 609 Gellens [Page 14] Expires January 2005 610 transmission of unencoded 8-bit characters, but in the absence of 611 such an extension [Hdr-Enc] must be used. 613 Resending/Forwarding 615 In MMS a message may be resent or forwarded, the difference being 616 that if the message has been downloaded then sending it to another 617 address is considered forwarding, while sending a message that has 618 not been downloaded is considered to be resending. 620 In Internet mail there are two primary ways of sending a previously 621 received message to a new recipient: forwarding and resending. 622 Forwarding is when a user creates a new message containing the 623 original message, either simply embedded within the text, or 624 delineated. Embedded messages generally have each original line 625 preceded by a quote symbol ('>'), surround the original text with a 626 preceding and trailing line which starts with hyphens as per 627 [Msg-Encap], such as '--- begin forwarded text' and '--- end 628 forwarded text', or encapsulate the original message as a 629 'message/rfc822' content type, perhaps within a 'multipart/mixed' 630 message. (This last method offers more robust delineation.) 631 Resending is when the original message is unaltered except for the 632 addition of 'Resent-' headers to explain the resending to the new 633 recipient. 635 A message may be resent more than once; each time new 'Resent-' 636 headers SHOULD be added at the top of the message. Thus, if more 637 than one series of 'Resent-' headers are present, the original 638 series is the last; the most recent is the first. 640 Forward counter 642 The 'Resent-Count:' header MAY be used to track the number of times 643 the message has been resent. Note that loop control is often done 644 by counting 'Received' headers, which are more general than 645 'Resent-' headers. 647 Previously-sent Information 649 A 'Resent-From:' header MAY be added to indicate the address of the 650 user who directed the message to be resent. 652 A 'Resent-Date:' header SHOULD be added to indicate the time and 653 date that the message was resent. 655 Any 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date' 656 headers, if present, SHOULD be removed. The information contained 657 in them SHOULD be translated into 'From:', 'Resent-To:', 658 'Resent-From:', 'Resent-Date:', and 'Resent-Count:' headers. The 660 Gellens [Page 15] Expires January 2005 661 original sender of the message SHOULD appear in the 'From:' header; 662 the original recipient(s) SHOULD appear in the 'To:' header; the 663 time and date the message was originally sent SHOULD appear in the 664 'Date:' header. The most recent sender SHOULD appear in the 665 top-most 'Resent-From:' header; the most recent recipient(s) SHOULD 666 appear in the top-most 'Resent-To:' header; the time and date the 667 message was most recently sent SHOULD appear in the top-most 668 'Resent-Date:' header. 670 'Received:' Headers 672 Each system that processes a message SHOULD add a 'Received:' header 673 as per [SMTP]. A message MAY be rejected if the number of 674 'Received:' headers exceeds a locally-defined maximum, which MUST 675 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 677 Content 679 The message content appears in the message body. Note that Internet 680 message format requires that line-endings be encoded as CR LF, thus 681 charset encodings that do not have this property cannot be used in 682 text/* body parts. (They MAY be used in other body parts, but only 683 when they are suitable encoded or when binary transmission has been 684 negotiated.) In particular, MMS allows UTF-16, while Internet 685 message format does not. UTF-16 encoding MUST be transcoded to 686 UTF-8 or another charset and encoding which is suitable for use in 687 Internet message format/protocols. 689 2.1.3.3 Conversion of messages from Internet to MMS format 691 3GPP MMS Version 693 An 'X-Mms-Mms-Version:' header SHOULD be added. 695 Message Type (of PDU) 697 An 'X-Mms-Message-Type:' header SHOULD be used in accordance with 698 the specific MMS interface (e.g., MM1, MM4). 700 Transaction ID 702 An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with 703 the specific MMS interface (e.g., MM1, MM4). 705 Message ID 707 Gellens [Page 16] Expires January 2005 708 The 'Message-Id:' header MUST be retained. If not present it MUST 709 be created, with a unique value. If the 'Message-Id:' header does 710 not exist, but the SMTP envelop contains an ENVID value (as 711 specified in [DSN-SMTP]), it MAY be used to construct the value. 713 Recipient(s) address 715 'To:' and 'Cc:' headers MUST be retained. 717 Each recipient contained in the SMTP envelope (RCPT TO values) MUST 718 be considered a recipient of the message. Recipients who appear in 719 address headers but not the SMTP envelope MUST be ignored. 720 Recipients who appear in the [SMTP] envelope but do not appear in 721 headers are considered "blind" (Bcc) recipients; such recipients 722 MUST NOT be added to message headers (including address and trace 723 headers) unless there is only one recipient total. 725 Sender address 727 The 'From:' header MUST be retained. 729 If address hiding has been requested, the 'From:' header MAY contain 730 a comment to this effect, for example, 'From: (anonymous sender)'. 732 Content type 734 The complete 'Content-Type:' header (including any parameters) 735 SHOULD be preserved. 737 Message class 739 An X-Mms-Message-Class: personal' header SHOULD be created for all 740 received messages with a non-null return path (MAIL FROM value in 741 the SMTP envelope). An X-Mms-Message-Class: auto' header MAY be 742 created for messages with a null return path. 744 Time of Expiry 746 An 'x-Mms-Expiry:' header SHOULD be created if the message contains 747 a relative time to expiration in the DELIVER-BY extension, as 748 specified in [Deliver-By]. 750 Earliest delivery time 752 An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. If a 753 message arrives via ESMTP relay containing an earliest time of 754 delivery in the AFTER extension, it MAY be rejected. If a message 755 is submitted via Message Submission [Submission] containing an 756 earliest time of delivery in the AFTER extension, it MUST either be 758 Gellens [Page 17] Expires January 2005 759 retained until the delivery time arrives, or it may be immediately 760 rejected. It MUST NOT be delivered or further relayed prior to the 761 delivery time. 763 Delivery report request 765 An 'X-Mms-Delivery-Report:' header SHOULD be created for messages 766 which request 'success' or 'none' delivery status notification by 767 use of the DSN extension as specified in [DSN-SMTP]. Requests for 768 'delay' notifications or non-default actions, such as that only the 769 message headers should be returned, cannot be mapped onto MMS 770 headers and thus SHOULD be ignored. 772 Priority 774 An 'X-Priority:' or 'Importance:' header, if present, SHOULD be 775 replaced with an 'X-Mms-Priority:' header. Suggested mappings: 777 2.1.3.3.1 Table 4: Priority Mappings (Internet Message to MMS) 779 -------------------------------|---------------------- 780 'X-Priority: 1 (highest)' |'X-Mms-Priority: High' 781 -------------------------------|---------------------- 782 'X-Priority: 2 (high)' |'X-Mms-Priority: High' 783 -------------------------------|---------------------- 784 'Importance: High' |'X-Mms-Priority: High' 785 -------------------------------|---------------------- 786 'X-Priority: 3 (normal)' | [omitted] 787 -------------------------------|---------------------- 788 'Importance: Normal' | [omitted] 789 -------------------------------|---------------------- 790 'X-Priority: 4 (low)' |'X-Mms-Priority: Low' 791 -------------------------------|---------------------- 792 'Importance: Low' |'X-Mms-Priority: Low' 793 -------------------------------|---------------------- 794 'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low' 795 -------------------------------|---------------------- 797 Normal priority messages SHOULD omit the 'X-Mms-Priority:' header. 799 Sender visibility 801 Requests for sender address hiding MAY be received in the SMTP 802 envelope by the X-ANONYMOUS extension. Servers which support 803 address hiding MAY advertise this by including X-ANONYMOUS in their 804 EHLO response. A message received which includes X-ANONYMOUS in the 805 MAIL FROM command has requested address hiding. 807 Gellens [Page 18] Expires January 2005 808 Note that even if servers claim to support address hiding, there is 809 no technical guarantee that it will be properly honored; servers 810 SHOULD NOT trust other servers to support this without a basis which 811 is beyond the scope of this specification (such as business 812 relationships). 814 Requests for sender address hiding MAY be reflected in the created 815 MM by adding an 'X-Mms-Sender-Visibility:' header. 817 Read reply request 819 A request for a read reply contained in a 820 'Disposition-Notification-To:' header as specified in [MDN] SHOULD 821 be replaced with an 'X-Mms-Read-Reply:' header. 823 Subject 825 The 'Subject:' header MUST be preserved. 827 Resending/Forwarding 829 One or more sets of 'Resent-' headers, if present, SHOULD be mapped 830 to 'To:', 'From:', 'Date:', and 'X-Mms-Previously-Sent-' headers. 832 'Received:' Headers 834 Each system that processes a message SHOULD add a 'Received:' header 835 as per [SMTP]. A message MAY be rejected if the number of 836 'Received:' headers exceeds a locally-defined maximum, which MUST 837 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 839 Content 841 The message content appears in the message body. 843 2.1.4 Report Generation and Conversion 845 Internet Message systems use the multipart/report MIME type for 846 delivery and disposition reports (often called "read reports") as 847 specified in [Report-Fmt]. This format is a two- or three-part MIME 848 message; one part is a structured format describing the event being 849 reported in an easy-to-parse format. Specific reports have a format 850 which is built on [Report-Fmt]. Delivery reports are specified in 851 [DSN-Msg]. Message disposition reports, which include read reports, 852 are specified in [MDN]. 854 Gellens [Page 19] Expires January 2005 855 By contrast, MMS reports are plain text, with no defined structure 856 specified. This makes it difficult to convert from an MMS report to 857 a standard Internet report. 859 An MMS Relay/Server supporting Internet Message exchange using MM3 860 MUST convert reports received from one side (MMS or Internet mail) 861 destined for the other. In addition, reports MUST be generated as 862 appropriate for messages received from either side of the MM3 863 interface. For example, if an MM to be sent via MM3 is not 864 deliverable, a delivery status MM shall be generated. Likewise, if 865 an Internet message is received via MM3 that cannot be further 866 relayed or delivered, a delivery status report [DSN-Msg] MUST be 867 generated. 869 When creating delivery or disposition reports from MMS reports, the 870 MMS report should be parsed to determine the reported event and 871 time, status, and the headers of the referenced (original) message. 872 These elements, once determined, are used to populate the subparts 873 of the delivery or disposition report. The first subpart is of type 874 text/plain, and contains a human-readable explanation of the event. 875 This text may include a statement that the report was synthesized 876 based on an MMS report. The second subpart is of type 877 report/delivery-status (for delivery reports) or 878 report/disposition-notification (for disposition reports). This 879 second part contains a structured itemization of the event. The 880 third subpart is of type message/rfc822 and includes the headers and 881 optionally the body of the referenced (original) message. 883 2.1.4.1 Delivery Report Mapping from MMS to Internet Message 885 The following table maps information elements from MMS delivery 886 reports to the format specified in [DSN-Msg]. 888 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message) 890 ======================|============|=================================== 891 Information Element |MMS Delivery|[DSN-Msg] Element 892 |Report Elem | 893 ======================|============|=================================== 894 ID of message whose |Message-Id: |'Original-Envelope-ID' field of 895 delivery status is | |per-message fields (use value of 896 being reported | |ENVID from ESMTP envelope if avail- 897 | |able, 'Message-ID:' otherwise). 898 ----------------------|------------|----------------------------------- 899 Recipient address of |From: |'Final-Recipient' field of the 900 the original message | |per-recipient section 901 (object of delivery | | 902 report) | | 904 Gellens [Page 20] Expires January 2005 905 ----------------------|------------|----------------------------------- 906 Destination address of|To: |'To:' header field value of top- 907 report | |level. 908 | | 909 | |Value taken from [SMTP] envelope 910 | |return-path of message being 911 | |reported, not its 'From:' header 912 | |field. 913 ----------------------|------------|----------------------------------- 914 Date and time the |Date: |'Date:' header field value of top- 915 message was handled | |level 916 ----------------------|------------|----------------------------------- 917 Delivery status of |X-Mms- |Action and Status fields of 918 original message | Status: |per-recipient section. 919 | | 920 | |The 'Action' field indicates if the 921 | |message was delivered. 922 | | 923 | |For failed delivery an appropriate 924 | |'Status' value shall be included 925 | |per [DSN-Msg]. 926 | | 927 | |The Action field is set to one of 928 | |the following values: 929 | | 930 | |* delivered (used for MMS status 931 | |values 'retrieved' and 'rejected', 932 | |depending on 'Status' code). 933 | | 934 | |* failed (used for MMS status 935 | |values 'expired' and 'unreachable') 936 | | 937 | |* delayed MAY be used for MMS 938 | |status value 'deferred' 939 | | 940 | |* relayed (used for MMS status 941 | |value 'indeterminate') 942 | | 943 | |* expanded (SHOULD NOT be used) 944 ----------------------|------------|----------------------------------- 945 Status Text | |Text in first part (human-readable 946 | |part) 947 ----------------------|------------|----------------------------------- 949 When an MMS Relay/Server generates a [DSN-Msg] in response to a 950 message received using [SMTP] on MM3: 952 Gellens [Page 21] Expires January 2005 953 * Top-level header field 'To:' SHOULD be the [SMTP] return-path of 954 the message whose status is being reported. 956 * Top-level header field 'From:' SHOULD be the address of the 957 recipient that the delivery-report concerns. 959 * The first part of the [DSN-Msg] SHOULD include the MM Status Text 960 field that would have been generated for an MM1 delivery-report. 962 2.1.4.2 Delivery Report Mapping from Internet Message to MMS 964 The following table maps information elements from a delivery report 965 as specified in [DSN-Msg] to the format of an MMS delivery report. 967 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS) 969 ===================|==================|================================ 970 Information Element|MMS Delivery |[DSN=Msg] Element 971 |Report Element | 972 ===================|==================|================================ 973 ID of the original |Message-Id: |'Original-Envelope-ID' field of 974 message (object of | |per-message fields. If not 975 delivery report) | |available, the 'Message-ID' 976 | |header field of the message 977 | |being reported, if included in 978 | |the third part, may be 979 | |substituted. 980 -------------------|------------------|-------------------------------- 981 Recipient address |From: |If available, the 'Original 982 of the original | |-Recipient' field of the per- 983 message (object of | |recipient section should be 984 delivery report) | |used; otherwise the 'Final- 985 | |Recipient' field of the per- 986 | |recipient section is used 987 -------------------|------------------|-------------------------------- 988 Destination address|To: |'To:' header field value of 989 of report | |top-level. 990 | | 991 | |Value taken from [SMTP] envelope 992 | |return-path of message being 993 | |reported, not its 'From:' header 994 | |field. 995 -------------------|------------------|-------------------------------- 996 Date and time the |Date: |'Date:' header field value of 997 message was handled| |top-level 998 -------------------|------------------|-------------------------------- 999 Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of 1000 original message | |per-recipient section 1002 Gellens [Page 22] Expires January 2005 1003 |Set to one of the | 1004 |following values: | 1005 | | 1006 |'retrieved' (used | 1007 |for 'Action' value| 1008 |'delivered'). | 1009 | | 1010 |'unreachable' | 1011 |(used for 'Action'| 1012 |value 'failed') | 1013 | | 1014 |'forwarded' (used | 1015 |for 'Action' value| 1016 |'relayed') | 1017 | | 1018 |'deferred' MUST | 1019 |NOT be used | 1020 |(ignore DSNs with | 1021 |'Action' value | 1022 |'delayed') | 1023 -------------------|------------------|-------------------------------- 1024 Status Text | |Text in first part (human- 1025 | |readable part) 1026 ===================|==================|================================ 1028 2.1.4.3 Read Report Mapping from MMS to Internet Message 1030 The following table maps information elements from MMS read reports 1031 to the format specified in [MDN]. 1033 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 1035 ======================|============|=================================== 1036 Information Element |MMS Delivery|[DSN-Msg] Element 1037 |Report Elem | 1038 ======================|============|=================================== 1039 ID of the original |Message-Id: |'Original-Envelope-ID' field (use 1040 message (object of | |value of ENVID from ESMTP envelope 1041 read report) | |if available, 'Message-ID:' 1042 | |otherwise). 1043 ----------------------|------------|----------------------------------- 1044 Recipient address of |From: |'Final-Recipient' field 1045 the original message | | 1046 ----------------------|------------|----------------------------------- 1047 Destination address of|To: |'To:' header field value of top- 1048 report | |level. 1049 | | 1050 | |Value taken from 'Disposition- 1052 Gellens [Page 23] Expires January 2005 1053 | |Notification-To:' header field of 1054 | |message being reported, not its 1055 | |'From:' header field. 1056 ----------------------|------------|----------------------------------- 1057 Date and time the |Date: |'Date:' header field value of top- 1058 message was handled | |level 1059 ----------------------|------------|----------------------------------- 1060 Disposition of message|X-Mms-Read- |Disposition-field 1061 being reported | Status: | 1062 | |For MMS-Read-Status value 'read', 1063 | |use 'disposition-type' value 1064 | |'displayed'; for MMS-Read-Status 1065 | |value 'Deleted without being read', 1066 | |use 'disposition-type' value 1067 | |'deleted') 1068 ----------------------|------------|----------------------------------- 1069 Status Text | |Text in first part (human-readable 1070 | |part) 1071 ======================|============|=================================== 1073 When an MMS Relay/Server generates an [MDN] in response to a message 1074 received using ESMTP on MM3: 1076 * Top-level header field 'To:' SHOULD be the value of the 1077 'Disposition-Notification-To:' header field of the message whose 1078 disposition is being reported . 1080 * Top-level header field 'From:' SHOULD be the address of the 1081 recipient that the read report concerns. 1083 2.1.4.4 Disposition Report Mapping from Internet Message to MMS 1085 The following table maps information elements from a disposition 1086 report as specified in [MDN] to the format of an MMS read report. 1088 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet Message to 1089 MMS) 1091 ===================|==================|================================ 1092 Information Element|MMS Read Report |[DSN=Msg] Element 1093 |Element | 1094 ===================|==================|================================ 1095 ID of the original |Message-Id: |'Original-Envelope-ID' field 1096 message (object of | | 1097 disposition report)| | 1098 -------------------|------------------|-------------------------------- 1099 Recipient address |From: |'Final-Recipient' field 1100 of the original | | 1102 Gellens [Page 24] Expires January 2005 1103 message | | 1104 -------------------|------------------|-------------------------------- 1105 Destination address|To: |'To:' header field value of 1106 of report | |top-level. 1107 | | 1108 | |Value taken from 'Disposition- 1109 | |Notification-To:' header field 1110 | |of message being reported, not 1111 | |its 'From:' header field. 1112 -------------------|------------------|-------------------------------- 1113 Date and time the |Date: |'Date:' header field value of 1114 message was handled| |top-level 1115 -------------------|------------------|-------------------------------- 1116 Disposition of |X-Mms-Read-Status:|disposition-field 1117 message being | | 1118 reported |Set to one of the | 1119 |following values: | 1120 | | 1121 |'read' (used for | 1122 |disposition-type | 1123 |value 'displayed')| 1124 | | 1125 |'Deleted without | 1126 |being read' (used | 1127 |for disposition- | 1128 |types 'deleted', | 1129 |'denied' and | 1130 |'failed' when | 1131 |action-mode is | 1132 |'automatic- | 1133 |action') | 1134 -------------------|------------------|-------------------------------- 1135 Status Text | |Text in first part (human- 1136 | |readable part) 1137 ===================|==================|================================ 1139 2.1.5 Message Delivery 1141 Within Internet mail, when ESMTP is used and delivery reports are 1142 requested [DSN-SMTP], delivery is considered to be acceptance of a 1143 message by the final server, that is, the server closest to the 1144 recipient. When an MMS Relay/Server receives a message using ESMTP 1145 and a delivery report is requested, the MMS Relay/Server MAY 1146 consider the message delivered when it has been sent to the MMS User 1147 Agent. 1149 Gellens [Page 25] Expires January 2005 1150 3 Security Considerations 1152 Data contained within messages should not be automatically trusted. 1153 Even within a carrier's network, and certainly within the Internet, 1154 various deliberate and accidental attacks or corruptions are 1155 possible. For example, routers may contain vulnerabilities which 1156 may be exploited, IP traffic may be intercepted and/or modified, 1157 etc. 1159 The following messaging-related security threats can be identified: 1161 * Misidentification of message source. 1163 * Message interception (unauthorized disclosure of contents). 1165 * Unauthorized disclosure of message sender or recipient. 1167 * Message modification (by adversary). 1169 * Message replay. 1171 * Traffic analysis (determining who is communicating with whom). 1173 There are existing mechanisms used to protect email traffic against 1174 some of these threats, such as: 1176 * Use of SSL/TLS (via [StartTLS]) to address disclosure and 1177 modification in transit between adjacent servers. 1179 * SMTP Authentication [Auth] to protect against misidentification of 1180 message source. 1182 * Use of end-to-end security mechanisms such as [PGP] or S/MIME 1183 [SMIME] to protect message contents. 1185 * Use of [IPSec] to protect against disclosure or modification in 1186 transit between servers. 1188 These mechanisms SHOULD be employed whenever the required 1189 infrastructure is available, e.g., a certificate infrastructure is 1190 necessary to support S/MIME, or user agent support for PGP is 1191 available. Enabling SMTP Authentication [Auth] and STARTTLS 1192 [StartTLS] are easy measures to deploy and SHOULD be used. 1194 Since MMS does not include a clear separation between in-transit 1195 envelope and message content, there are increased risks of 1196 unauthorized disclosure of information, and additional challenges in 1197 protecting data. For example, Bcc recipients do not normally appear 1198 in the message content, only in the envelope; care MUST be taken in 1200 Gellens [Page 26] Expires January 2005 1201 the gateway function to ensure that Bcc recipients which do appear 1202 are deleted from the message content. 1204 Some MMS features contain inherently more risk than others. For 1205 example, reply charging and sender address hiding. The reply 1206 charging mechanism requires a high degree of trust between entities 1207 with little technical basis. Deliberate or accidental abuse of this 1208 trust can result in unexpected or unauthorized charges. For 1209 example, a sender may be charged for unauthorized replies, or a 1210 sender may be charged for a reply which the author thought would be 1211 paid for by the recipient. A sender's identity may be disclosed in 1212 violation of a request for this to be blocked. The identity of 1213 recipients may be disclosed to other recipients (or even 1214 non-recipients) for a message in which the sender intended for the 1215 recipients not to be disclosed. 1217 It is possible to hide the sender's identity from non-recipients 1218 using anonymous remailers. It is hard to hide the sender's identity 1219 from recipients when the mail is cryptographically signed. In view 1220 of anti-spam measures it may be undesirable to hide the sender's 1221 identity. 1223 Additional mechanisms can be developed to protect against various 1224 threats, however, these are not included in this version of this 1225 specification. It is strongly RECOMMENDED that features such as 1226 reply charging and sender identity hiding not be used across carrier 1227 domains, and be used within carrier domains only with full 1228 understanding of the risks involved. 1230 4 Normative References 1232 IETF: 1234 [DSN-Msg] "An Extensible Message Format for Delivery Status 1235 Notifications", Moore, Vaudreuil, RFC 3464, January 2003. 1237 [DSN-SMTP] "SMTP Service Extension for Delivery Status 1238 Notifications", Moore, RFC 3461, January 2003. 1240 [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: 1241 Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, 1242 November 1996. 1244 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 1245 Requirement Levels", RFC 2119, Harvard University, March 1997. 1247 Gellens [Page 27] Expires January 2005 1249 [MDN] "An Extensible Message Format for Message Disposition 1250 Notifications", Fajman, RFC 2298, March 1998. 1252 [Msg-Fmt] �Internet Message Format�, Resnick, RFC 2822, April 2001. 1254 [Report-Fmt] �The Multipart/Report Content Type for the Reporting of 1255 Mail System Administrative Messages�, Vaudreuil, RFC 3462, January 1256 2003 1258 [SMTP] �Simple Mail Transfer Protocol�, Klensin, RFC 2821, April 1259 2001. 1261 5 Informative References 1263 IETF: 1265 [Auth] "SMTP Service Extension for Authentication", Myers, RFC 2554, 1266 March 1999 1268 [Codes] "SMTP Service Extension for Returning Enhanced Error Codes", 1269 Freed, RFC 2034, October 1996. 1271 [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, 1272 June 2000. 1274 [Msg-Encap] "Proposed Standard for Message Encapsulation", Rose, 1275 Stefferud, RFC 934, January 1985. 1277 [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, 1278 February 1997. 1280 [IPSec] "Security Architecture for the Internet Protocol", Kent, 1281 Atkinson, RFC 2401, November 1998 1283 [PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, 1284 Roessler, RFC 3156, August 2001 1286 [SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC 1287 2633, June 1999 1289 [StartTLS] "SMTP Service Extension for Secure SMTP over Transport 1290 Layer Security", Hoffman, RFC 3207, February 2002 1292 [Submission] �Message Submission�, Gellens, Klensin, RFC 2476, 1293 December 1998. 1295 Gellens [Page 28] Expires January 2005 1296 OMA: 1298 OMA specifications are available at the OMA web site 1299 . 1301 [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C 1303 3GPP2 and 3GPP: 1305 3GPP2 specifications are available at the 3GPP2 (Third 1306 Generation Partnership Project 2) web site 1307 . 1309 3GPP specifications are available at the 3GPP (Third Generation 1310 Partnership Project) web site 1312 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", TIA-934-310, X.S0016-310 1314 "MMS MM4 Stage 3 Inter-Carrier Interworking", TIA-934-340, 1315 X.S0016-340 1317 �Multimedia Messaging Service: Functional description; Stage 2�, TS 1318 23.140 Release 5. 1320 [Formats] "MMS Media Formats and Codecs�, C.P0045, (pending) 1322 [Overview] "Multimedia Messaging Services (MMS) Overview", 1323 X.S0016-000-B, PN-3-0085-000. 1325 [Stage_1] "Multimedia Messaging Services (MMS); Stage 1", 1326 Requirements, October 2002, S.R0064-0. 1328 [Stage_2] �Multimedia Messaging Service (MMS); Stage 2", Functional 1329 Specification, April 2003, X.S0016-200/TIA-934-200. 1331 "Multimedia Messaging Service; Media formats and codecs", 1332 TS26.140Release 5. 1334 6 Author's Address 1336 Randall Gellens 1337 QUALCOMM Incorporated 1338 5775 Morehouse Drive 1339 San Diego, CA 92121 1340 USA 1341 randy@qualcomm.com 1343 Gellens [Page 29] Expires January 2005 1344 Intellectual Property Statement 1346 The IETF takes no position regarding the validity or scope of any 1347 intellectual property or other rights that might be claimed to 1348 pertain to the implementation or use of the technology described in 1349 this document or the extent to which any license under such rights 1350 might or might not be available; neither does it represent that it 1351 has made any effort to identify any such rights. Information on the 1352 IETF's procedures with respect to rights in standards-track and 1353 standards-related documentation can be found in BCP-11. Copies of 1354 claims of rights made available for publication and any assurances 1355 of licenses to be made available, or the result of an attempt made 1356 to obtain a general license or permission for the use of such 1357 proprietary rights by implementors or users of this specification 1358 can be obtained from the IETF Secretariat. 1360 The IETF invites any interested party to bring to its attention any 1361 copyrights, patents or patent applications, or other proprietary 1362 rights which may cover technology that may be required to practice 1363 this standard. Please address the information to the IETF Executive 1364 Director. 1366 Full Copyright Statement 1368 Copyright (C) The Internet Society (2004). 1370 This document is subject to the rights, licenses and restrictions 1371 contained in BCP 78, and except as set forth therein, the authors 1372 retain all their rights. 1374 Disclaimer 1376 This document and the information contained herein are provided on 1377 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1378 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1379 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1380 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1381 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1384 Gellens [Page 30] Expires January 2005