Re: [Jmap] Submission

["Adrien de Croy" <[e-mail]>]

Just to clarify about what I was thinking when I raised the spectre of 
notifications.

Quite often the person would like to see more than one.  The key 
attribute about notifications intended for humans is timeliness.  We 
have a system where you may get something that looks like a bounce 
message 4hrs after sending your message.  You may get a bounce message 
10 minutes later (or worse) if you entered the destination address 
incorrectly.  You may have already gone home, and now missed the 
deadline to submit your tender for the project.  There are real 
consequences to the delays that are created by mail systems.

As for DSNs the person generally doesn't want to see them in their inbox 
as messages.

Whether underneath these are multilpe DSNs or whatever I don't think 
many people really care, although we have questions about what should a 
client do to a server-stored message (e.g. as per IMAP) when it's a 
control message like this (should it be processed and then deleted?).

The problem with DSNs also is that they are not protocol.  they are just 
other messages that a MUA has to retrieve and process, based on whatever 
retrieval schedule.  This works against timeliness.

In any case, there will still be a lot of mail that is not delivered by 
SMTP or SUBMIT - and that's mail where the destination is to another 
user of the JMAP server.  This is a considerable amount of mail.  In 
this case also, the notifications could be in the protocol, since the 
time overall is probably very short.  All we need for mail that takes 
longer to change state (e.g. because it's going off-site via 
SMTP/SUBMIT) is a way to send a status message back.  This could be an 
email, or it could be some other kind of message.  The JMAP server 
submitting mail via SMTP/SUBMIT could then choose to request DSNs on 
behalf of the client, and the client will always get some kind of 
notification, whether that is

* Your message was delivered to another local mailbox
* your message was submitted for delivery and there will be further 
notifications
      - incoming DSN from SMTP etc
* your message was submitted for delivery, but there will be no more 
status notifications

This should help provide incentive for MTA vendors to implement DSNs as 
well.

As for other envelope extensions, I agree the SMTP/SUBMIT system needs 
to know certain envelope-related things, such as whether the content is 
binary or 7-bit safe or not.  This is where the discussion about 
shackling JMAP to SUBMIT/SMTP comes in.  It's a shame that we still have 
to support a transport that needs to care about the payload.  Seems like 
a basic layering violation to me.

If we aren't going to do anything about that, like set a minimum level 
of required support for the systems the JMAP will interface to, we won't 
improve this, nor provide any incentive for it to be improved, and so it 
won't be.  We will still be Base64 or quoted-printable encoding 
everything.

also we may find there is more interest in this protocol if we DO look 
at fixing something (anything) about SMTP.

Adrien


------ Original Message ------
From: "Ned Freed" <[e-mail]>
To: "Ted Lemon" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>; "Ned Freed" <[e-mail]>
Sent: 24/04/2017 11:50:54 AM
Subject: Re: [Jmap] Submission

>>  On Apr 23, 2017, at 7:13 PM, Ned Freed <[e-mail]> wrote:
>>  > This is a entirely false dichotomy of choices you have going here. 
>>Nobody is
>>  > proposing "nailing it to SUBMIT". All anyone is saying is that you 
>>need to
>>  > have a means of specifying the envelope separate from the message 
>>and its
>>  > headers, and that the envelope needs to be extensible.
>
>>  If that's the case, then I don't think there's anything to argue 
>>about.   But I've been getting the impression that that's not the 
>>case.   I am fully in agreement with the assertion, with which I don't 
>>recall anyone disagreeing, that the envelope has to be separate from 
>>the message and has to be extensible.
>
>>  My concern is with avoiding a requirement that JMAP submit have the 
>>same
>>  _flow_ as SMTP submit.
>
>Huh? Nobody has said that. AFAIK nobody has even hinted at that.
>
>>  So I want it to be the case that status can be delivered 
>>asynchronously,
>>  essentially.   I don't mind if it's also possible to deliver it 
>>synchronously,
>>  since that's just a degenerate case of asynchronous.
>
>That's a completely different matter, and in that regard, I'll just 
>make
>a few observations:
>
>(0) Synchronous delivery of status is, with the exception of a handful 
>of
>     egregiously broken clients, always going to provide the better user
>     experience. This has everything to do with how people are wired and
>     nothing to do with the technology.
>
>(1) SUBMIT and SMTP both have the ability to deliver status both 
>synchronously
>     and asynchronously. We call the latter "DSNs". They have not worked 
>out
>     well.
>
>(2) Asynchronous delivery of status information is NOT a degenerate 
>case
>     of synchronous delivery. For example, it's entirely possible for a 
>SUBMIT
>     server to always return success status codes and issue a DSN later. 
>(In
>     fact our SUBMIT server can be set to do exactly this, in order to
>     deal with the aforementioned egregiously broken clients.)
>
>(3) The argument that DSNs being in-band rather than an out-of-band 
>mechanism
>     is the root cause of all the problems in this area doesn't fly. 
>Out-of-band
>     mechanisms for message status reporting have been tried - the 
>obvious
>     example is X.400 - and if anything they've worked less well than
>     the in-band approach taken in SMTP. So nobody should assume that 
>the
>     definition of such a mechanism will magically lead to glory.
>
>(4) There seems to be an assumption that an alternative asynchronous
>     notification mechanism is something  that SUBMIT could not do. If 
>so,
>     that's incorrect. In fact I can easily imagine a SUBMIT extension 
>that
>     would specify an alternative mechanism for reporting delivery
>     success/failures, which the server would then employ instead of
>     generating one or more DSNs.
>
>     In fact this would be so trivially easy to implement modulo 
>whatever
>     the backwards-pointing notification mechanism is I bet I could do 
>it
>     in only and hour or two of coding.
>
>(5) Implementing proper error handling is hard, getting everyone to 
>implement
>     it correctly is probably impossible.
>
>(6) There are a host of problems associated with the Outbox/Sent magic 
>folder
>     proposal that have nothing to do with anything being discussed 
>here.
>
>In fact I believe I'm going to coin a new term at this point - the 
>FUSMEHP. I
>bet you can geuss what it means.
>
>     Ned
>
>_______________________________________________
>Jmap mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/jmap