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

[Benjamin Kaduk <[e-mail]>]

Hi Bron,

Thanks for clarifying the intent.  It looks like we'd then be looking at
something like:

OLD:
   When sending the MDN, the server is in charge of generating the
   "originalRecipient", "finalRecipient" and "originalMessageId" fields
   according to the [RFC8098] specification.

NEW:
   When sending the MDN, the server is in charge of generating the
   "originalRecipient", "finalRecipient" and "originalMessageId" fields
   according to the [RFC8098] specification, subject to potential client
   override of finalRecipient.

?

Thanks,

Ben

On Thu, Nov 19, 2020 at 01:34:40PM +1100, Bron Gondwana wrote:
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jmap
> > 
> 
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
>