Re: [Jmap] Submission

[Brandon Long <[e-mail]>]

On Wed, Apr 19, 2017 at 7:05 PM, Chris Newman <[e-mail]>
wrote:

> On 19 Apr 2017, at 13:38, Alexey Melnikov wrote:
>
>> > On 19 Apr 2017, at 20:36, Ted Lemon <[e-mail]> wrote:
>>
>>>
>>> On Apr 19, 2017, at 3:29 PM, Chris Newman <[e-mail]>
>>>> wrote:
>>>> When deploying a large mail service it's important to keep the
>>>> submission mail queues (which have management/monitoring issues)
>>>> functionally separate from the mail store (which has very different
>>>> management/monitoring issues). If the JMAP design requires a mail queue to
>>>> be present on the JMAP server or present in the mail store, that is an
>>>> unacceptable protocol design error as it hinders the manageability of large
>>>> deployments.
>>>>
>>>
>>> Isn't this just an implementation detail?   IOW, how is it different to
>>> have a different protocol for queuing messages, versus having different
>>> handling for a mailbox with a specific name?
>>>
>>
>> It is not clear to me why a queue can't be also a mailbox. Interfaces
>> seem to be pretty similar for both.
>>
>
> The architectural requirements of a mail store and mail queue are very
> different. For comparison:
>
> Mail store
>  * data is "owned" by the end-user
>  * long-lived small & large objects
>  * write-once, read-multiple, important dynamic metadata (flags &
> annotations)
>  * quota-based administrative limits
>  * over quota is flagged for statistics but not an operational problem
>  * for security, read can be restricted to only work when the end-user
> authenticates
>  * final delivery agent can be limited to append-only access
>  * data for different users must be kept separate with ACL restrictions
>  * random access is important; message metadata must be cached for
> efficiency
>
> Mail queue
>  * data is "owned" by the delivery system
>  * short-lived small & large objects
>  * write-once, normally read+delete once, largely static metadata
> (envelope)
>  * generally no administrative limits (or limits are imposed at submission
> time)
>  * large queue indicates operational problems, needs to flag a monitoring
> system alert
>  * for security, all read/write access can be restricted to delivery
> agent; no need for ACL complexity
>  * data for different users can be combined for efficient queuing.
>  * sending messages for different users over the same SMTP relay channel
> improves privacy by making traffic analysis harder
>  * access follows queue pattern; many need to cache envelope metadata for
> efficiency but message metadata is not cached
>
> It possible to implement something that provides the union of the required
> semantics. But combining the semantics creates security and privacy
> constraints, adds monitoring complexity to the deployment, and removes a
> bunch of potential optimizations.
>
> So I object to JMAP if it requires me to implement something combining
> mail store and mail queue semantics. The protocol design needs to allow
> implementations with clean functional separation between mail queue and
> mail store.


My understanding of an "outbox" is typically "the message is here when I
want it submitted to the mail queue, and removed when that submission has
been accomplished".

Ie, on disconnected clients, this is often where messages are stored
locally before they can be submitted via MSA.

So, the outbox / jmap wouldn't require mail queue semantics, it's not the
mail queue, it's the precursor to the mail queue.

A more advanced solution might be for the message to be in the outbox for
the entire time it's in the mail queue.  I wouldn't implement them as one
and the same, but move a message from the outbox to the sent folder (on
success) or back to drafts or something (on failure) when the message has
exited the mail queue.  Ie, you could use DSN from the mall queue back to
the mail store to cause the messages to move folders.  I don't think anyone
is suggesting this is required for jmap, though.

I often considered something like that for Gmail, as it eliminates the
confusion people often have that a message may be pending in our mail
queues for days.  It does require a fairly integrated system, however.

Brandon