[Jmap] DSN and MDN in JMAP
"Chris Newman" <chris.newman@oracle.com> Tue, 18 July 2017 13:02 UTC
Return-Path: <chris.newman@oracle.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D00213172B for <jmap@ietfa.amsl.com>; Tue, 18 Jul 2017 06:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.002
X-Spam-Level:
X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnsY4qxC0zxY for <jmap@ietfa.amsl.com>; Tue, 18 Jul 2017 06:02:48 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1335B12EC3F for <jmap@ietf.org>; Tue, 18 Jul 2017 06:02:48 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6ID2kxi018991 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <jmap@ietf.org>; Tue, 18 Jul 2017 13:02:47 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v6ID2k3s015176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <jmap@ietf.org>; Tue, 18 Jul 2017 13:02:46 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6ID2kKf027057 for <jmap@ietf.org>; Tue, 18 Jul 2017 13:02:46 GMT
Received: from [31.133.136.212] (/31.133.136.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jul 2017 06:02:45 -0700
From: Chris Newman <chris.newman@oracle.com>
To: jmap@ietf.org
Date: Tue, 18 Jul 2017 15:02:38 +0200
Message-ID: <71E3B9BE-C58C-40DF-AA63-EB4B94334DD5@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5347)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/UGu_hKL5wtIm2xE_2ewEgkKlZug>
Subject: [Jmap] DSN and MDN in JMAP
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jul 2017 13:02:49 -0000
Adding Delivery Status RFC 3464 and Message Disposition Notification RFC 3798 to MessageSubmission object: Most interesting fields for a client UI: A client wishing to show whether message has been seen by a recipient will look at the "Disposition-Type" per-recipient field (semantics in RFC 3798 section 3.2.6.2). A client wishing to show delivery status will look at the "Action" per-recipient field (semantics in RFC 3464 section 2.3.3). Thoughts on how to map data from these standards to JMAP: 1. RFC 3464 uses type;value for most items. 99% of the time only one type is used/needed on the Internet. I suggest we strip the "type;" when mapping to JSON. That makes the mapping spec slightly more complex, but the values easier for a client to use. Alternatively we could pass the values through unchanged (simpler spec, more complex client). 2. I suggest we just allow UTF-8 in all fields, including addresses. This gets us nearly free support for RFC 6533. If we're removing "type;", we also need to remove 3464/6533 quoting from addresses. 3. Probably want to convert date syntax from 5322 format to RFC 3339 format, but numeric time zone offsets are required by RFC 3464, so we shouldn't break that. 4. DSNs have per-DSN fields (that apply when a report covering multiple recipients is sent) and per-recipient fields. I suggest storing a copy of the per-DSN fields with each recipient to keep the data model as simple as possible. An alternative would be to have an array of JSON objects for each DSN received and store a pointer to that record. 5. For MDN, the 'Disposition' field is a meta-field; I split it into three fields, it's possible to split it into 4 but I think that's not necessary 6. JMAP servers MAY hide DSN & MDN notification messages so they don't appear in the JMAP view of the mail store. If we do this and want to guarantee no loss of information, we might want to add a list of BLOB IDs to the MessageSubmission object that can be used to fetch raw DSN & MDN messages. * 7. An implementation of JMAP is permitted to set DSN & MDN fields for local deliveries without actually generating one or more DSN/MDN messages to transport the information, as long as the semantics of the fields are the same as if such a notification message was generated according to the DSN & MDN standards.* 8. One interesting idea... DSNs correlate using the ENVID (envelope ID, RFC 3461). We could require JMAP servers to set the ENVID to the ID of the JMAP MessageSubmission object on submission (presuming the submission server advertises RFC 3461). If we do this, the MessageSubmission ID must be restricted to ASCII and it would be best to avoid characters requiring xtext escaping (RFC 3461 section 4).* 9. It's possible to move most of this mapping to a separate spec, but I think four items belong in the JMAP Mail base spec (identified by *). See base spec RFC 3464 & 3798 for defined semantics of the fields. All fields are per-recipient (per #5): { "Original-Envelope-Id": string, # optional "Reporting-MTA": string, # required, drop "dns;" "DSN-Gateway": string # optional, drop "dns;" "Received-From-MTA": string # optional, drop "dns;" "Arrival-Date": string # optional, numeric time zone "Original-Recipient": string, # optional, drop address-type, allow 5321 & 6531 "Final-Recipient": string # required, drop address-type, allow 5321 & 6531 "Action": string # required: failed, delayed, delivered, relayed, expanded* "Status": string # required: SMTP enhanced status code. "Remote-MTA": string # optional, drop "dns;" "Diagnostic-Code": string # optional, drop "smtp;" "Last-Attempt-Date": string # optional, numeric time zone required "Final-Log-ID": string # optional "Will-Retry-Until": string # optional, numeric time zone required i18n DSN (RFC 6533) "Localized-Diagnostic": { "lang-tag" : string, ... } MDN fields (per-recipient, RFC 3798) ------------------------------------ "Reporting-UA": string # optional "MDN-Gateway": string # optional, drop "smtp;" "MDN-Original-Recipient": string # optional "MDN-Final-Recipient": string # required "Original-Message-ID": string # optional "Disposition-Mode": string # required {manual,automatic}-action/MDN-sent-{manually,automatically} "Disposition-Type": string # required {displayed,deleted}* "Disposition-Modifiers": string # optional "Failure": string # optional "Error": string # optional "Warning": string # optional } JMAP Clients wishing to generate MDNs (RFC 3798) will look at the following three headers: Disposition-Notification-To Disposition-Notification-Options Original-Recipient and the $MDNSent keyword (RFC 3503) JMAP servers MAY generate MDNs as a result of setting $Seen if they follow the rules in RFC 3503 and set $MDNSent keyword appropriately. Comments? - Chris
- [Jmap] DSN and MDN in JMAP Chris Newman
- Re: [Jmap] DSN and MDN in JMAP Neil Jenkins
- Re: [Jmap] DSN and MDN in JMAP Bron Gondwana
- Re: [Jmap] DSN and MDN in JMAP Chris Newman
- Re: [Jmap] DSN and MDN in JMAP Rolf E. Sonneveld
- Re: [Jmap] DSN and MDN in JMAP Ned Freed