Subject: Re: [Jmap] draft-ietf-jmap-mdn-06

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 10 Jun 2020 22:45:13 +1000

Oops, I realise I didn't also send this to the list when I replied before and may have got the wrong address.

I found some issues when putting together the shepherding doc and doing a really thorough readthrough of the spec and also looking at our implementation.

It would be good to be prepared to talk about these things at the interim meeting next week.

Cheers,

Bron.

On Wed, May 20, 2020, at 16:46, Bron Gondwana wrote:
> My apologies for the delay. I realised our implementation is incomplete, so I sat down with Neil (virtually!) and did a full readthrough. What do you know, we found more stuff to query. Sorry about that.
> 
> *Abstract:*
> 
> This may be a little too short - it doesn't explain what JMAP is or why it would be of interest. Possibly also something that the editors will pick up on, but it would be good to make it a little more "this is what JMAP is, and this is why having MDN support in JMAP is a good idea".
> 
> *1.3 Capabilities Object*
> 
> I would move both MDN/send and MDN/parse as being only present if urn:ietf:params:jmap:mdn is present in the accountCapabilities. Given that MDN/parse works on a blobId, and blobIds are per account, it makes sense that both of them require an account.
> 
> *2. MDN: forEmailId*
> 
> I would reverse the expression change from:
> 
> This argument can only be null when the MDN object
      is a server response for the "MDN/parse" method.
> 
> And instead say "This property MUST NOT be null for MDN/send, but may be null in the response from MDN/parse". That way we're not making statements about potential future extensions.
> 
> *2. MDN: finalRecipient*
> 
> We discussed that wildcard identities are possible in JMAP, which could make calculating finalRecipient more difficult. I would do two things here:
> 
> 1) make finalRecipient optional on MDN/send - if set, it overrides the value that would be calculated from the Identity.
> 
> 2) add to Security Considerations that the server SHOULD validate that the user is permitted to use the finalRecipient value and return a forbiddenFrom error if not.
> 
> *2. MDN: Disposition Object*
> 
> RFC8098 defines the strings as case insensitive. JSON values don't have to be case sensitive, but it would be much more like the rest of JMAP if you defined these values to be only lowercase via JMAP, e.g.
> 
>    o  sendingMode: "String" This MUST be one of the following strings:
      "mdn-sent-manually" / "mdn-sent-automatically"
> 
> And also add some text which says that these are defined case insensitive in 8098 but are case sensitive in this RFC and MUST be converted to lowercase by /parse.
> 
> If you disagree and think they should match what's in the raw file, then document needs to specify that these particular values are case insensitive.
> 
> *2.1 MDN Send***
> 
> You refer an "MDNError" but don't actually define it. From the examples it's clear that this is a SetError. I think it would be best to change that to:
> 
> o  notSent: "Id[SetError]|null"
> 
> Having done so, you can then enumerate the expected error types and reasons, with reference to the existing registry (apart from the new mdnAlreadySent error).
> 
> *2.1 MDN Send part 2*
> 
> This paragraph has problems:
> 
>    If the Account Id or Identity id given cannot be found, the MDN
   sending is rejected with an "invalidProperties" error.
> 
> One is the inconsistent spelling of accountId and identityId which I'm sure the editors would capture, but you may as well fix upfront.
> 
> Secondly, the correct error here in JMAP is invalidArguments and it rejects the entire method call, as these are method level arguments rather than properties on an individual MDN.
> 
> *2.1 MDN Send implicit Email/set***
> 
> It is not clear from this text whether an implicit Email/set is issued if there are no successfully sent MDNs (i.e. 'sent' is null). I am happy with either, but it needs to be clear!
> 
> It would be good to explain here exactly how the implicit Email/set would look, e.g.
> 
> For the following method call:
> 
>        [ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "Md45b47b4877521042cec0938",
             "subject": "Read receipt for: World domination",
             "textBody": "This receipt shows that the email has been
                 displayed on your recipient's computer. There is no
                 guaranty it has been read or understood.",
             "reportingUA": "linagora.com; OpenPaaS",
             "disposition": {
               "actionMode": "manual-action",
               "sendingMode": "MDN-sent-manually",
               "type": "displayed"
             }
           }
         }
       }, "0" ]
> 
> The implicit Email/set call would be equivalent to:
> 
>        [ "Email/set", {
         "accountId": "ue150411c",
         "update": {
           "Md45b47b4877521042cec0938": {
             "keywords/$mdnsent": true
           }
         }
       }, "0" ]
> 
> *2.2 MDN/parse***
> 
> There reasons for "forEmailId" to be null could be expanded to include: "the server can't efficiently calculate the related email".
> 
> (I guess if there's more than one email with the same "Message-Id" header but different emailId then what gets returned here is undefined - could be any one of the emails, or could be null)
> 
> Again, the invalidProperties error should be invalidArguments.
> 
> *3.1 Sending an MDN***
> 
> The Email/set example is incorrect. Since the implicit request is a patch to "keywords/$mdnsent", a server would not be expected to echo the full value of the keywords property in the result, since it didn't unilaterally change it. I would expect this response:
> 
>      [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]
> 
> Where "updated" maps the emailId from the forEmailId property to an empty object.
> 
> *All examples need to either have sendingMode changed to lowercase or the definition changed as above.*
> 
> *5. Security Considerations***
> 
> As mentioned above, we should talk about validating the finalRecipient if we allow it to be set by the client.
> 
> 
> Again, sorry about it taking so long to get back with this feedback - I bet you're frustrated at how slow the process is, and this time it's entirely my fault. I look forward to reviewing a -10 and actually shepherding this thing for real!
> 
> Cheers,
> 
> Bron.
> 
> On Tue, May 5, 2020, at 22:44, Bron Gondwana wrote:
>> Hi Raphael - I got Ken to follow up to you on it since he wrote our implementation. I see you've dealt with that in -09.
>> 
>> I'll do the shepherd writeup this week and submit it this week.
>> 
>> Cheers,
>> 
>> Bron.
>> 
>> On Wed, Apr 29, 2020, at 00:26, Raphael OUAZANA wrote:
>>> Hi Bron,

>>> Any news on this?

>>> Thanks,

>>> Raphaël.

>>> Le 20 mars 2020 09:24, de [email-masked]
>>>> I agree, I think I've fixed every comments with -08.

>>>> Thanks,

>>>> Raphaël.

>>>> Le 20 mars 2020 06:43, de [email-masked]
>>>>> Thanks for that. 
>>>>> 
>>>>> With that done, I BELIEVE that we -08 resolves every issue outstanding. Do you agree? I'll go ahead and do the shepherd writeup if so.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Bron.
>>>>> 
>>>>> On Thu, Mar 19, 2020, at 21:17, Raphael OUAZANA wrote:
>>>>>> 

>>>>>> Le 18 mars 2020 19:09, de [email-masked]
>>>>>>> 

>>>>>>> On 3/18/20 1:42 PM, Raphael OUAZANA wrote:
>>>>>>>> Hello,

>>>>>>>> Le 6 mars 2020 20:35, de [email-masked] 
>>>>>>>>> 

>>>>>>>>> On 3/5/20 7:40 PM, Ken Murchison wrote:
>>>>>>>>> > A few questions as I implement this in Cyrus:
>>>>>>>>> 

>>>>>>>>> > - The JMAP server may not be able to determine the Final-Recipient of 
>>>>>>>>> > the original message was Bcc'd or sent to an alias. Should the MDN 
>>>>>>>>> > object include a 'from' property?
>>>>>>>>> 

>>>>>>>> It should match the email of the account, no?

>>>>>>> If the email was sent to an email alias and eventually delivered to the underlying account, the sender of the MDN might want to have the MDN use the alias so as not to leak the real address of the account.

>>>>>>>> Or maybe we should ask for an identity when sending an MDN, so that the user can choose which email appears in this field?

>>>>>>> Yes, that is what I was thinking. If the user doesn't provide a from address, then we can default to the email of the account.

>>>>>> I will add an identity parameter, like in MessageSubmission. I will make it mandatory because for me it's not clear how we can get an email address from an account.

>>>>>> Regards,

>>>>>> Raphaël.

>>>>>> _______________________________________________
>>>>>> Jmap mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/jmap
>>>>>> 
>>>>> 
>>>>> --
>>>>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>>  [email-masked]
>>>>> 
>>>>> 
>> 
>> --
>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>  [email-masked]
>> 
>> 
> 
> --
>  Bron Gondwana, CEO, Fastmail Pty Ltd
>  [email-masked]
> 
> 

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Raphael OUAZANA <[email-masked]>
Date: Wed, 10 Jun 2020 12:49:31 +0000

Hi Bron,

No problem, I well received your previous answer, I was just very busy.

I will try to take some time to dig into your remarks soon.

Regards,

Raphaël.

Le 10 juin 2020 14:45, de [email-masked]

Cheers,

Bron.

Abstract:

1.3 Capabilities Object

2. MDN: forEmailId

2. MDN: finalRecipient

2. MDN: Disposition Object

2.1 MDN Send

2.1 MDN Send part 2

2.1 MDN Send implicit Email/set

[ "MDN/send", {

[ "Email/set", {

2.2 MDN/parse

3.1 Sending an MDN

[ "Email/set", {

All examples need to either have sendingMode changed to lowercase or the definition changed as above.

5. Security Considerations

Cheers,

Bron.

Cheers,

Bron.

Hi Bron,

Any news on this?

Thanks,

Raphaël.

Thanks,

Raphaël.

Thanks for that.

Cheers,

Bron.

On 3/18/20 1:42 PM, Raphael OUAZANA
wrote:

Hello,

If the email was sent to an email alias and eventually delivered
to the underlying account, the sender of the MDN might want to
have the MDN use the alias so as not to leak the real address of
the account.

Or maybe we should ask for an identity when sending an MDN, so
that the user can choose which email appears in this field?

Yes, that is what I was thinking.  If the user doesn't provide a
from address, then we can default to the email of the account.

Regards,

Raphaël.

Jmap mailing list

[email-masked]

--

[email-masked]

--

[email-masked]

--

[email-masked]

--

[email-masked]

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 10 Jun 2020 22:57:56 +1000

Great thanks! Hopefully you can attend the meeting next week too.

Cheers,

Bron.

---

From: Raphael OUAZANA <[email-masked]>
Date: Wed, 10 Jun 2020 16:58:50 +0000

One point in particular is not clear to me:

2.1 MDN Send

You refer an "MDNError" but don't actually define it.  From the examples it's clear that this is a SetError..  I think it would be best to change that to:

Can I use this definition even if it's not only a SetError, but an union of SetError and mdnAlreadySent?

Regards,

Raphaël.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 11 Jun 2020 07:53:02 +1000

>> *2.1 MDN Send*

> Can I use this definition even if it's not only a SetError, but an union of SetError and mdnAlreadySent?

It was clear to me reading that mdnAlreadySent is a type for SetError.

>From RFC8620:

A *SetError* object has the following properties:

   o  type: "String"

      The type of error.

   o  description: "String|null"

      A description of the error to help with debugging that includes an
      explanation of what the problem was.  This is a non-localised
      string and is not intended to be shown directly to end users.

So "mdnAlreadySent" would be added to the registry at https://www.iana.org/assignments/jmap/jmap.xhtml and listed as a possible error type for this method.

Bron.

---

From: cketti <[email-masked]>
Date: Thu, 11 Jun 2020 12:39:08 +0200

On 10.06.20 14:45, Bron Gondwana wrote:
>> *3.1 Sending an MDN*
>>
>> The Email/set example is incorrect.  Since the implicit request is a
>> patch to "keywords/$mdnsent", a server would not be expected to echo
>> the full value of the keywords property in the result, since it
>> didn't unilaterally change it.  I would expect this response:
>>
>>      [ "Email/set", {

This would be annoying for clients. They'd have to hard-code what the
implicit Email/set looks like.

It also makes it harder to change what the implicit Email/set call looks
like in a future version of the spec. If an additional property was to
be modified it would have to be included in the response to be backward
compatible to this spec. Then you'd have to come up with a new way to
specify an implicit request ("include these changed properties in the
response, but not those").

I do realize that including the modified keyword in the response makes
things more complicated for the server. But to me it feels like the
better alternative.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 11 Jun 2020 22:09:26 +1000

> This would be annoying for clients. They'd have to hard-code what the implicit Email/set looks like.

> It also makes it harder to change what the implicit Email/set call looks like in a future version of the spec. If an additional property was to be modified it would have to be included in the response to be backward compatible to this spec. Then you'd have to come up with a new way to specify an implicit request ("include these changed properties in the response, but not those").

> I do realize that including the modified keyword in the response makes things more complicated for the server. But to me it feels like the better alternative.

The argument of "if an additional property was to be modified" doesn't apply in JMAP land, because that additional property would come with an additional "using" parameter, and the client would have to set that - in which case it would know what the server would do. There's no backwards/forwards compatibility issue because the client explicitly requests which specs are to be used, and the server explicitly lists which ones it supports.

HOWEVER...

You raise pretty much the same objection that I have to implicit sets in the first place. They shouldn't exist. So what would it look like to have an EXPLICIT set?

       [[ "MDN/send", {
         },
*         "onSuccessUpdateEmail": {
           "#k1546": {
             "keywords/$mdnsent": true**
**           }**
**         }*
       }, "0" ]]

This would match the semantics of EmailSubmission/set, which this is kind of a special case of in some ways, and would then mean that there's never any need to worry about the automatic tasks that the server takes, because it never does. Yes, you need to hard-code that logic into clients, but it strongly matches with my hard earned belief that automatic magical behaviour on the server is bad - the client should explicitly ask for side-effects.

I would also put a SHOULD or even MUST in the spec that the server reject an MDN/send which doesn't result in setting the keyword $mdnsent on the server in that case.

But - I'm happy with either way - but I'm not happy with requiring the Email/set response to act differently from every other triggered Email/set response, because as a server author this makes things really messy.

Bron.

---

From: cketti <[email-masked]>
Date: Thu, 11 Jun 2020 15:04:25 +0200

On 11.06.20 14:09, Bron Gondwana wrote:
> You raise pretty much the same objection that I have to implicit sets
> in the first place.  They shouldn't exist.  So what would it look like
> to have an EXPLICIT set?
>
>        [[ "MDN/send", {
> *"onSuccessUpdateEmail": { "#k1546": { "keywords/$mdnsent": true***
> *}***
> *}*
>        }, "0" ]]
>
> This would match the semantics of EmailSubmission/set, which this is
> kind of a special case of in some ways, and would then mean that
> there's never any need to worry about the automatic tasks that the
> server takes, because it never does.  Yes, you need to hard-code that
> logic into clients, but it strongly matches with my hard earned belief
> that automatic magical behaviour on the server is bad - the client
> should explicitly ask for side-effects.
>
> I would also put a SHOULD or even MUST in the spec that the server
> reject an MDN/send which doesn't result in setting the keyword
> $mdnsent on the server in that case.

I like that. I agree that being explicit is better.