idnits 2.17.1 draft-ietf-jmap-mdn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8098]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2019) is 1874 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-jmap-core-14 == Outdated reference: A later version (-16) exists of draft-ietf-jmap-mail-15 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JMAP R. Ouazana, Ed. 3 Internet-Draft Linagora 4 Intended status: Standards Track March 7, 2019 5 Expires: September 8, 2019 7 Handling Message Disposition Notification with JMAP 8 draft-ietf-jmap-mdn-01 10 Abstract 12 This document specifies a data model for handling [RFC8098] MDN 13 messages with a server using JMAP. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 8, 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Notational conventions . . . . . . . . . . . . . . . . . 3 51 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.3. Addition to the capabilities object . . . . . . . . . . . 3 53 2. MDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Methods added to the EmailSubmission object . . . . . . . . . 4 55 3.1. EmailSubmission/sendMDN . . . . . . . . . . . . . . . . . 4 56 3.2. EmailSubmission/parseMDN . . . . . . . . . . . . . . . . 5 57 4. Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Sending an MDN for a received email . . . . . . . . . . . 6 59 4.2. Asking for MDN when sending an email . . . . . . . . . . 7 60 4.3. Parsing a received MDN . . . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 5.1. JMAP Capability Registration for "mdn" . . . . . . . . . 8 63 5.2. Registration of JMAP keyword '$MDNSent' . . . . . . . . . 9 64 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 7.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 JMAP ([I-D.ietf-jmap-core] - JSON Meta Application Protocol) is a 73 generic protocol for synchronising data, such as mail, calendars or 74 contacts, between a client and a server. It is optimised for mobile 75 and web environments, and aims to provide a consistent interface to 76 different data types. 78 MDN are defined in [RFC8098] and are used as "read receipts", 79 "acknowledgements", or "receipt notifications". 81 A client can have to deal with MDN in different ways: 83 1. When receiving an email, an MDN can be sent to the sender. This 84 specification defines an EmailSubmission/sendMDN method to cover 85 this case. 87 2. When sending an email, an MDN can be requested. This must be 88 done with the help of a header, and is already specified by 89 [RFC8098] and can already be handled by [I-D.ietf-jmap-mail] this 90 way. 92 3. When receiving an MDN, the MDN could be related to an existing 93 sent mail. This is already covered by [I-D.ietf-jmap-mail] in 94 the EmailSubmission object. Client could want to display 95 detailed information about a received MDN. This specification 96 defines a EmailSubmission/parseMDN method to cover this case. 98 1.1. Notational conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 Type signatures, examples and property descriptions in this document 107 follow the conventions established in section 1.1 of 108 [I-D.ietf-jmap-core]. Data types defined in the core specification 109 are also used in this document. 111 Servers MUST support all properties specified for the new data types 112 defined in this document. 114 1.2. Terminology 116 The same terminology is used in this document as in the core JMAP 117 specification. 119 1.3. Addition to the capabilities object 121 The capabilities object is returned as part of the standard JMAP 122 Session object; see the JMAP spec. Servers supporting _this_ 123 specification MUST add a property called "urn:ietf:params:jmap:mdn" 124 to the capabilities object. 126 2. MDN 128 An *MDN* object has the following properties: 130 o *forEmailId*: "String" Email Id of the received email this MDN is 131 relative to. 133 o *subject*: "String|null" Subject used as "Subject" header for this 134 MDN. 136 o *textBody*: "String|null" Human readable part of the MDN, as plain 137 text. 139 o *reportingUA*: "String|null" Name of the MUA creating this MDN. 140 It is used to build the MDN Report part of the MDN. 142 o *disposition*: "Disposition" Object containing the diverse MDN 143 disposition options. 145 o *mdnGateway*: "String|null" (server-set) Name of the gateway or 146 MTA that translated a foreign (non-Internet) message disposition 147 notification into this MDN. 149 o *originalRecipient*: "String|null" (server-set) Original recipient 150 address as specified by the sender of the message for which the 151 MDN is being issued. 153 o *finalRecipient*: "String" (server-set) Recipient for which the 154 MDN is being issued. 156 o *originalMessageID*: "String|null" (server-set) Message-ID (the 157 [RFC5322] header field, not the JMAP Id) of the message for which 158 the MDN is being issued. 160 o *error*: "String[]|null" (server-set) Additional information in 161 the form of text messages when the "error" disposition modifier 162 appears. 164 o *extensionFields*: "String[String]|null" (server-set) Object where 165 keys are extension-field names and values are extension-field 166 values. 168 A *Disposition* object has the following properties: 170 o *actionMode*: "String" This MUST be one of the following strings: 171 "manual-action" / "automatic-action" 173 o *sendingMode*: "String" This MUST be one of the following strings: 174 "MDN-sent-manually" / "MDN-sent-automatically" 176 o *type*: "String" This MUST be one of the following strings: 177 "deleted" / "dispatched" / "displayed" / "processed" 179 See [RFC8098] for the exact meaning of these different fields. 181 3. Methods added to the EmailSubmission object 183 3.1. EmailSubmission/sendMDN 185 The EmailSubmission/sendMDN method generates and sends an [RFC5322] 186 message from an MDN object. 188 It takes the following arguments: 190 o *accountId*: "Id" The id of the account to use. 192 o *mdns*: "String[MDN]" A map of creation id (client specified) to 193 MDN objects 195 If the _forEmailId_, _subject_, _textBody_, _reportingUA_, 196 _disposition_ properties are invalid (e.g. missing, wrong type, id 197 not found), the submission creation is rejected with a standard 198 "invalidProperties" SetError and no email is sent. Any other error 199 usually sent by "EmailSubmission/set" for *create* can be returned by 200 this method. 202 The client SHOULD NOT issue a sendMDN request if the message has the 203 "$MDNSent" keyword set. In this case, the server MUST reject the 204 submission with a standard "forbiddenToSend" SetError. 206 When sending the MDN, the server is in charge of generating the 207 _originalRecipient_, _finalRecipient_ and _originalMessageID_ fields 208 accordingly to the [RFC8098] specification. 210 The response has the following arguments: 212 o *accountId*: "String" The id of the account used for this call. 214 o *created*: "String[EmailSubmission]" A map of creation id (client- 215 specified) to an email sent from the referenced properties. The 216 returned EmailSubmission is similar to a call to a standard 217 "EmailSubmission/set" with a _create_ parameter. 219 o *notCreated*: "String[SetError]" A map of creation id to a 220 SetError object for each Email that failed to be sent. The 221 possible errors are defined above. 223 For each "forEmailId" whose EmailSubmission where created, the server 224 MUST add a "$MDNSent" keyword to the email. 226 3.2. EmailSubmission/parseMDN 228 This method allows you to parse blobs as [RFC5322] messages to get 229 MDN objects. This can be used to parse and get detailed information 230 about blobs referenced in the _mdnBlobIds_ of the EmailSubmission 231 object, or any email the client could expect to be an MDN. 233 The _forEmailId_ property can be null or missing if the 234 _originalMessageID_ property is missing or not referencing an 235 existing email. 237 The Email/parse method takes the following arguments: 239 o *accountId*: "String" The id of the account to use. 241 o *blobIds*: "Id[]" The ids of the blobs to parse. 243 The response has the following arguments: 245 o *accountId*: "Id" The id of the account used for the call. 247 o *parsed*: "Id[MDN]|null" A map of blob id to parsed MDN 248 representation for each successfully parsed blob, or null if none. 250 o *notParsable*: "Id[]|null" A list of ids given that corresponded 251 to blobs that could not be parsed as MDNs, or null if none. 253 o *notFound*: "Id[]|null" A list of blob ids given that could not be 254 found, or null if none. 256 4. Samples 258 4.1. Sending an MDN for a received email 260 A client can use the following request to send an MDN back to the 261 sender: 263 [[ "EmailSubmission/sendMDN", { 264 "accountId": "ue150411c", 265 "mdns": { 266 "k1546": { 267 "forEmailId": "Md45b47b4877521042cec0938", 268 "subject": "Read receipt for: World domination", 269 "textBody": "This receipt shows that the email has been 270 displayed on your recipient's computer. There is no 271 guaranty it has been read or understood.", 272 "reportingUA": "linagora.com; OpenPaaS", 273 "disposition": { 274 "actionMode": "manual-action", 275 "sendingMode": "MDN-sent-manually", 276 "type": "displayed" 277 } 278 } 279 } 280 }, "0" ]] 282 If the email id matches an existing email without the "$MDNSent" 283 keyword, the server can answer: 285 [[ "EmailSubmission/sendMDN", { 286 "accountId": "ue150411c", 287 "oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", 288 "newState": "355421f6-8aed-4cf4-a0c4-7377e951af36", 289 "created": { 290 "k1546": { 291 "id": "73191acf-ede7-4008-bde2-57cd9ed3c559" 292 } 293 } 294 }, "0" ], 296 4.2. Asking for MDN when sending an email 298 This is done with the [I-D.ietf-jmap-mail] "Email/set" _create_ 299 method. 301 [[ "Email/set", { 302 "accountId": "ue150411c", 303 "create": { 304 "k1546": { 305 "mailboxIds": { 306 "2ea1ca41b38e": true 307 }, 308 "keywords": { 309 "$seen": true, 310 "$draft": true 311 }, 312 "from": [{ 313 "name": "Joe Bloggs", 314 "email": "joe@example.com" 315 }], 316 "to": [{ 317 "name": "John", 318 "email": "john@example.com" 319 }], 320 "headers:" [{ 321 "name": "Disposition-Notification-To", 322 "value": "joe@example.com" 323 }], 324 "subject": "World domination", 325 ... 326 } 327 } 328 }, "0" ]] 330 Note the specified "Disposition-Notification-To" header indicating 331 where to send MDN back (usually the sender of the email). 333 4.3. Parsing a received MDN 335 The client issues a parse request: 337 [[ "EmailSubmission/parseMDN", { 338 "accountId": "ue150411c", 339 "blobIds: "0f9f65ab-dc7b-4146-850f-6e4881093965" 340 }, "0" ]] 342 The server responds: 344 [[ "EmailSubmission/parseMDN", { 345 "accountId": "ue150411c", 346 "parsed": { 347 "0f9f65ab-dc7b-4146-850f-6e4881093965": { 348 "forEmailId": "Md45b47b4877521042cec0938", 349 "subject": "Read receipt for: World domination", 350 "textBody": "This receipt shows that the email has been 351 displayed on your recipient's computer. There is no 352 guaranty it has been read or understood.", 353 "reportingUA": "linagora.com; OpenPaaS", 354 "disposition": { 355 "actionMode": "manual-action", 356 "sendingMode": "MDN-sent-manually", 357 "type": "displayed" 358 } 359 "finalRecipient": "rfc822; john@example.com", 360 "originalMessageID": "<1521557867.2614.0.camel@apache.org>" 361 } 362 } 363 }, "0" ]] 365 5. IANA Considerations 367 5.1. JMAP Capability Registration for "mdn" 369 IANA will register the "mdn" JMAP Capability as follows: 371 Capability Name: "urn:ietf:params:jmap:mdn" 373 Specification document: this document 375 Intended use: common 377 Change Controller: IETF 379 Security and privacy considerations: this document, section 6. 381 5.2. Registration of JMAP keyword '$MDNSent' 383 This registers the JMAP keyword '$MDNSent' in the "IMAP and JMAP 384 keywords Registry". 386 Keyword name: "$MDNSent" 388 Scope: IMAP and JMAP 390 Purpose (description): Specifies that a Message Disposition 391 Notification (MDN) must not be sent for any message annotated with 392 the $MDNSent IMAP keyword. 394 Private or Shared on a server: SHARED 396 Is it an advisory keyword or may it cause an automatic action: This 397 keyword can cause automatic action by the client. See [RFC3503] for 398 more details. 400 When/by whom the keyword is set/cleared: This keyword is set by an 401 IMAP client when it decides to act on an MDN request, or when 402 uploading a sent or draft message. It can also be set by a delivery 403 agent. Once set, the flag SHOULD NOT be cleared. 405 Related keywords: None 407 Related IMAP/JMAP Capabilities: None 409 Security Considerations: See Section 6 of [RFC3503] 411 Published specification (recommended): this document 413 Person & email address to contact for further information: (editor- 414 contact-goes-here) 416 Intended usage: COMMON 418 Owner/Change controller: IESG 420 6. Security considerations 422 The same considerations regarding MDN (see [RFC8098]) apply to this 423 document. 425 7. References 427 7.1. Normative References 429 [I-D.ietf-jmap-core] 430 Jenkins, N. and C. Newman, "JSON Meta Application 431 Protocol", draft-ietf-jmap-core-14 (work in progress), 432 January 2019. 434 [I-D.ietf-jmap-mail] 435 Jenkins, N. and C. Newman, "JMAP for Mail", draft-ietf- 436 jmap-mail-15 (work in progress), February 2019. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN) 444 profile for Internet Message Access Protocol (IMAP)", 445 RFC 3503, DOI 10.17487/RFC3503, March 2003, 446 . 448 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 449 DOI 10.17487/RFC5322, October 2008, 450 . 452 [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition 453 Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, 454 February 2017, . 456 7.2. Informative References 458 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 459 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 460 May 2017, . 462 Author's Address 464 Raphael Ouazana (editor) 465 Linagora 466 100 Terrasse Boieldieu - Tour Franklin 467 Paris - La Defense CEDEX 92042 468 France 470 Email: rouazana@linagora.com 471 URI: https://www.linagora.com