[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