Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and COMMENT)

Bron Gondwana <brong@fastmailteam.com> Thu, 19 November 2020 02:35 UTC

Return-Path: <brong@fastmailteam.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 02B573A09F4 for <jmap@ietfa.amsl.com>; Wed, 18 Nov 2020 18:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KdjeMB+s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rDwfq2UB
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 JzgXU9OAJKsv for <jmap@ietfa.amsl.com>; Wed, 18 Nov 2020 18:35:05 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC9E3A09F0 for <jmap@ietf.org>; Wed, 18 Nov 2020 18:35:04 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 001825C01A8; Wed, 18 Nov 2020 21:35:02 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 18 Nov 2020 21:35:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=qUcI hDyExfDDE5J8dEooHxFtjCgrObIMFB9o/ZNwmx8=; b=KdjeMB+sM1x6ZxlOw5jb IKh4GLNYc6+fWVXy9GLVmGUoDYy/pdo7ZPRlP0SBOsm56nbA4wW5OvV83z/5mJeu Bt48wD05IvCgRoN/YD39YOzDD/KS68tsEgL8b6+cGpz7KpG7L9bn11GhIr7LTBaE 7CF8pmYw/xcYcXPbLAHf4esvPWsItmRUdl97ciTPHxEeKLcd0dvJiRLherOryWCF BzVRj3eQHZPS+YSanRGN529Nc6pVEwhzBA/6a7xIAhLOsuI2cWm4tnxdY8PcdvHn xXY2IG78aIQQsd3qRnMQMpIKazX3/sssMmIxrkQPvp219X1q2lx44qHjKwnm/nAF XQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qUcIhD yExfDDE5J8dEooHxFtjCgrObIMFB9o/ZNwmx8=; b=rDwfq2UBexjYtsCZH9hwf7 sen1HUbeXlqSmIEphLHOJxlTkPvuWM1wao3HsOLy+VLN9mgnavPkEdumPBYeUZ0A x3NjxRbP+cOfYP9klUE2mCiJn16i2oV0QckfIpJpI6/M4DuNjf48vWreXU18PL4P fcogE3mzUVte4Mcm0GBJixaDcN9y4oJIWfuwZ6MKuKPT2lO7zunBVL7VtqmNa/oG XUPLRYAiB8dRCRIjBCL/h2WDCpOxkG+o3HwETnSRnU1iMuDqKoFWJuUqWB+nSVPy nDvztEBptDmESU84oEmkCR2ZacWXgQo2Yg5fx1pctxbGp6tGsMY2wTYgkf/eF7TQ ==
X-ME-Sender: <xms:1tm1X239UGYPE3e7_cbIzFdHNqhGHPoOVbDXwn8_8NeeC23M3N1hFw> <xme:1tm1X5HxncID8a_gMwNkFim4J1rmQxj6DVAr79v3MM8Dl3u4JB8fKjvHd-EDio8OO UqP3vTKPUM>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefiedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepffdvkeefgeelieeutedttdffheevvefffeekuddvtddt keeigfejuddvhfdvudelnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:1tm1X-54VCtHOA8410al_FD8y1-c3x4j8wiIfZKnG642tVPquPtXgw> <xmx:1tm1X3296Hu5YwB5NpxZ5ajtZy44poXivSS7KOtXMUc-hhLoh4nXAQ> <xmx:1tm1X5HA1i1cE4sIBGrCrS4NFffqHiVs-rr1i2LE0D4hVRHxw4HbNA> <xmx:1tm1X8OFsoHCqi9uXZVwpamxAMo2d8naQZIRUzveiItTIiEjfEJY6w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D73EE1802D3; Wed, 18 Nov 2020 21:35:01 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <522c72f3-a4d3-46ae-b62b-bc87302d64a3@dogfood.fastmail.com>
In-Reply-To: <160193187289.4946.17482930539468511819@ietfa.amsl.com>
References: <160193187289.4946.17482930539468511819@ietfa.amsl.com>
Date: Thu, 19 Nov 2020 13:34:40 +1100
From: Bron Gondwana <brong@fastmailteam.com>
To: jmap@ietf.org
Cc: Raphael OUAZANA <rouazana@linagora.com>, Benjamin Kaduk <kaduk@mit.edu>
Content-Type: multipart/alternative; boundary="c62d93845e7b4d5c9f5115eeb3e96d7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/STzSyhaIwwvRcdYwqq2Uz8nFdKo>
Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and COMMENT)
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 19 Nov 2020 02:35:07 -0000

Hi Raphael,

This discuss is blocking MDN progress.  Can you please look at providing clarifying text here, or discuss with Ben what he wants.

Ben - the intent is that the client can override the value if it needs to.  Generally it won't need to, but sometimes there will be preferred canonical versions of addresses.  For example: Fastmail tries to hide the user's username entirely from the sender if they sent to an external alias, so that their username can remain secret from those who contact them on that alias - so we would override finalRecipient to be the alias name at our boundary, even though the actual final recipient inside our system was their primary address.

The text does require that the server validate that the client is allowed to use the value it sets as finalRecipient.

Cheers,

Bron.

On Tue, Oct 6, 2020, at 08:04, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-jmap-mdn-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This should be quite easy to resolve; I'm just not sure yet which
> direction the resolution will be.
> 
> I think we should be a little more clear about whether the client can
> override the finalRecipient calculation (or just provide a suggestion to
> do so, or not give any input at all, etc.): the description of the
> finalRecipient property of an MDN object says that "if set, it
> overrides the value that would be calculated by the server from the
> Identity", which to me suggests that the client could set something to
> override the server (if the server sua sponte did something different
> that would typically be an "exception", not an "override"), but later on
> in Section 2.1 we say that "[w]hen sending the MDN, the server is in
> charge of generating the "originalRecipient", "finalRecipient" and
> "originalMessageId" fields according to the [RFC8098] specification.  I
> do not see discussion in RFC 8098 of client intput into the server's
> populating of this field, so I'm unsure whether/where the client has
> input.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for noting the `jq` validation in the sheperd writeup!
> 
> Section 1
> 
>    A client can have to deal with MDNs in different ways:
> 
> (editorial) "have to deal with" seems like it can be read as implying
> obligation to do so (even though the majuscule "MUST" is not used); it
> seems like this is just attempting to enumerate the cases in which an
> MDN might be encountered or need to be interacted with.
> 
>    2.  When sending an email message, an MDN can be requested.  This
>        must be done with the help of a header, and is already specified
>        by [RFC8098] and can already be handled by [RFC8621] this way.
> 
> (nit?) "header" or "header field"?  (We get this a lot for HTTP and I've
> forgotten if SMTP uses the same rule...)
> 
>    3.  When receiving an MDN, the MDN could be related to an existing
>        sent message.  This is already covered by [RFC8621] in the
>        EmailSubmission object.  [...]
> 
> (The "DeliveryStatus" member, in particular, right?)
> 
> Section 1.3
> 
>    The value of this "urn:ietf:params:jmap:mdn" property is an empty
>    object in the account's "accountCapabilities" property.
> 
> I presume it's also an empty object in the server's "capabilities"
> property as well (and we should probably say so).
> 
> Section 2
> 
> It's a little interesting to me that RFC 8261 did not define or mention
> specific access to the User-Agent string but we need to have a specific
> reportingUA here.  I do recognize that it's (an optional) part of the
> RFC 8098 ABNF, and that RFC 8098 mentions the relevant security
> considerations already.  Perhaps a subtle nudge in this section that the
> "null" option may have better privacy properties would be appropriate.
> (We may also revisit whether/what to include in the examples for
> reportingUA.)
> 
>    o  finalRecipient: "String|null" Recipient for which the MDN is being
>       issued.  if set, it overrides the value that would be calculated
>       by the server from the Identity.
> 
> Could we get a couple more words to support the definite article?  (I am
> not sure which Identity is "the" Identity just from this context; it is
> only later on that we discover that there is an identityId in the
> MDN/send arguments.)
> 
>    o  extensionFields: "String[String]|null" Object where keys are
>       extension-field names and values are extension-field values.
> 
> I used process of elimination to conclude that these are RFC 8098
> extension-field ABNF names/values; I don't know if there's a good way to
> hint the reader of that fact.
> 
>    o  actionMode: "String" This MUST be one of the following strings:
>       "manual-action" / "automatic-action"
> 
>    o  sendingMode: "String" This MUST be one of the following strings:
>       "mdn-sent-manually" / "mdn-sent-automatically"
> 
> I recognize that this is entirely the responsibility of RFC 8098 and not
> this document, but is it valid to combine "automatic-action" with
> "mdn-sent-manually"?  I am not 100% I understand the semantics.
> 
> Section 2.1
> 
>                                  The latter because of the implicit call
>    to Email/set and the use of Identities, described below.  [...]
> 
> nit: does this sentence have a verb?
> 
>    The following already registered SetError would mean:
> 
> nit: these are the SetError types, right?
> 
> Section 3.x
> 
> It might be helpful to use a different creation ID for the different
> classes of example (though not required by the protocol).
> 
> Section 3.1
> 
>              "extension": {
>                "X-EXTENSION-EXAMPLE": "example.com"
>              }
> 
> nit(?): somehow I thought X- extensions were generally thought to not be
> needed/useful anymore.
> 
> Section 5
> 
>    In order to enforce trust regarding the relation between the user
>    sending an email message and the identity of this user, the server
>    SHOULD validate in conformance to the provided Identity that the user
>    is permitted to use the finalRecipient value and return a
>    forbiddenFrom error if not.
> 
> "enforce" and "SHOULD" are not words I usually see in combination.
> 
> 
> 
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com