Subject: [Jmap] Discussion of "MANAGESIEVE for JMAP"

From: Bron Gondwana <[email-masked]>
Date: Tue, 17 Jul 2018 05:26:48 +1000

This was the extension discussion for sieve.  The discussion in the
room covered:
* Full sieve support is common on servers, but rare in clients
* Do we want to support all of sieve, or just a subset?  (if so, how do
  we decide what subset?  How do we update with future sieve
  extensions?)* how does this interact with the vacation support in the mail spec?

My suggestion is that we start with an extension for full sieve, and
maybe propose a way to manage a more limited file as well.  The key
question here would be whether we transport sieve scripts as a blob of
raw text, or whether we define a "sieve as JSON" mapping.
Next steps:

* What's the scope of what we want to do?  (managesieve inside JMAP /
  sieve as JSON / limited subset)* Who wants to author a spec?

Bron.

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

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 16 Jul 2018 15:44:47 -0400

As discussed in the meeting, to a rounding error, no one writes sieve. Instead, clients present a GUI that generates sieve in the background. The trouble is that different clients will support different features and produce different sieve, not to mention going from the raw sieve back to the GUI building blocks is a hard task in itself, so I struggle to see how this extension is going to lead to useful interoperability, unless you presume users only use one client and anything else is "here be dragons".

A JMAP extension for "rules" would be very useful if it could let multiple clients edit them… but whenever I've looked into trying to define this, the differences in supported features between servers let alone clients is so huge it's seemed impossible to come up with anything likely to be both useful and implemented.

Neil.

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 17 Jul 2018 06:11:29 +1000

Yep, so the question is "how can we add value" over just having people
use managesieve...

On Tue, Jul 17, 2018, at 05:44, Neil Jenkins wrote:
> As discussed in the meeting, to a rounding error, no one writes sieve.
> Instead, clients present a GUI that generates sieve in the background.
> The trouble is that different clients will support different features
> and produce different sieve, not to mention going from the raw sieve
> back to the GUI building blocks is a hard task in itself, so I
> struggle to see how this extension is going to lead to useful
> interoperability, unless you presume users only use one client and
> anything else is "here be dragons".> 
> A JMAP extension for "rules" would be very useful if it could let
> multiple clients edit them… but whenever I've looked into trying to
> define this, the differences in supported features between servers let
> alone clients is so huge it's seemed impossible to come up with
> anything likely to be both useful and implemented.> 
> Neil.
> _________________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap

---

From: Ned Freed <[email-masked]>
Date: Mon, 16 Jul 2018 14:28:36 -0700 (PDT)

> As discussed in the meeting, to a rounding error, no one writes sieve.

This seems backwards to me: Lots of clients *write* sieve. (And I'm quite
surprised at how well they do it - we rarely encounter syntax problems with
generated sieves, and clients are actually pretty good at getting the quoting
right in order to avoid injection attacks.)

What clients don't do is *read* sieves. I've only found one implementation that
did this, and I could never get it to work - although that was entirely a
matter of it being  browser-based thing that for whatever reason refused to
load.

What clients read instead is a set of rules, which may or may not be stored
as part of the sieve. And there are also implementations that construct
sieves as as side effect of a much more general business rules logic scheme.

Not to be discounted are clients that let users write their own sieves. You may
think this doesn't happen, but you'd be wrong - we have a number of sites that
support it, including some very large ones.

> Instead, clients present a GUI that generates sieve in the background. The
> trouble is that different clients will support different features and produce
> different sieve, not to mention going from the raw sieve back to the GUI
> building blocks is a hard task in itself, so I struggle to see how this
> extension is going to lead to useful interoperability, unless you presume users
> only use one client and anything else is "here be dragons".

Who says the purpose of the extension is necessarily to provide
interoperability? Seems to me the main goal here is to make it possible to
write reaosnable mail clients. Given how many clients support setting up
and maintaining server-side rules, I don't think a system that fails to allow
for this can be seen as anything other than deficient.

> A JMAP extension for "rules" would be very useful if it could let multiple
> clients edit them… but whenever I've looked into trying to define this, the
> differences in supported features between servers let alone clients is so huge
> it's seemed impossible to come up with anything likely to be both useful and
> implemented.

Well, I've heard tell of a mail filtering language, something called sieve,
that probably could be prevailed upon to provide a subset of capabilities
and associated semantics that would form the basis for a rule language.

Or maybe that was just my imagination.

				Ned

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 17 Jul 2018 08:24:42 +1000

Am I reading a volunteering to write a Sieve JMAP extension?

Bron.

On Tue, Jul 17, 2018, at 07:28, Ned Freed wrote:
>> As discussed in the meeting, to a rounding error, no one
>> writes sieve.> 
> This seems backwards to me: Lots of clients **write** sieve. (And
> I'm quite> surprised at how well they do it - we rarely encounter syntax
> problems with> generated sieves, and clients are actually pretty good at getting
> the quoting> right in order to avoid injection attacks.)
> 
> What clients don't do is **read** sieves. I've only found one
> implementation that> did this, and I could never get it to work - although that was
> entirely a> matter of it being  browser-based thing that for whatever reason
> refused to> load.
> 
> What clients read instead is a set of rules, which may or may not
> be stored> as part of the sieve. And there are also implementations that
> construct> sieves as as side effect of a much more general business rules
> logic scheme.> 
> Not to be discounted are clients that let users write their own
> sieves. You may> think this doesn't happen, but you'd be wrong - we have a number of
> sites that> support it, including some very large ones.
> 
>> Instead, clients present a GUI that generates sieve in the
>> background. The>> trouble is that different clients will support different features and
>> produce>> different sieve, not to mention going from the raw sieve back to
>> the GUI>> building blocks is a hard task in itself, so I struggle to see
>> how this>> extension is going to lead to useful interoperability, unless you
>> presume users>> only use one client and anything else is "here be dragons".
> 
> interoperability? Seems to me the main goal here is to make it
> possible to> write reaosnable mail clients. Given how many clients support
> setting up> and maintaining server-side rules, I don't think a system that fails
> to allow> for this can be seen as anything other than deficient.
> 
>> multiple>> clients edit them… but whenever I've looked into trying to define
>> this, the>> differences in supported features between servers let alone clients
>> is so huge>> it's seemed impossible to come up with anything likely to be both
>> useful and>> implemented.
> 
> Well, I've heard tell of a mail filtering language, something
> called sieve,> that probably could be prevailed upon to provide a subset of
> capabilities> and associated semantics that would form the basis for a rule
> language.>

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 16 Jul 2018 18:36:11 -0400

On Tue, 17 Jul 2018, at 8:09 AM, Ned Freed wrote:
> This seems backwards to me: Lots of clients *write* sieve.

Yes. Sorry if I was not clear: I was saying few people write sieve directly themselves.

> support it, including some very large ones.

Oh, I'm aware this happens—we support this ourselves at FastMail—but in terms of being a useful problem to solve, allowing clients to support a GUI for configuring rules on the server is much more useful than offering a text box for users to type in sieve.

> interoperability?

Well, generally interoperability is one of the reasons we define standards. If a user with multiple clients (which is pretty common) finds they either show different sets of rules, or worse(?), overwrite each other's rules, I suspect they will find this confusing and consider it broken behaviour. With my service provider hat on, I do not look forward to dealing with those support tickets.

Neil.

---

From: "Chris Newman" <[email-masked]>
Date: Mon, 16 Jul 2018 23:39:42 -0400

I think there is good reason to believe that Managesieve's semantics for 
multiple Sieves will result in usability problems if multiple clients 
access Managesieve for the same user. Interesting question: could we 
come up with a reasonably simple model that allows clients to: 1. offer 
a GUI that generates a Sieve, and 2. be aware of other generated Sieves 
in such a way that the least astonishment principle is not violated.

Here's a strawman:
A client can upload a Sieve script but there is mandatory metadata as 
follows:
1. a human description of the client that generated the Sieve that's 
useful to provide end-user context.
2. a flag indicating if the client generates "concatenation-friendly" 
Sieves (let's not worry the technical details of that yet).
3. a textual description of what the filter does intended to be read by 
an end user (likely needs at least line breaks and indenting). (maybe 
also a 1-liner or title for the Sieve)
4. enable/disable flag

If a concatenation-hostile Sieve is on the server, there's only one 
Sieve allowed. If another client wants to set rules it can offer the 
user the option to delete the Sieve created by client X that does Y 
(since X & Y are mandatory metadata).

Multiple Sieves are allowed if they are all concatenation-friendly.

When multiple sieves are present, the order the sieves run in is 
settable by the client. Disabled Sieves don't run but do participate in 
the ordering.

So a minimal JMAP-sieve client generates a concatenation hostile Sieve 
with mandatory metadata and will offer to delete all server-side Sieves 
(with presentation of the metadata) if there are any.

A better JMAP-sieve client will generate concatenation-friendly Sieves 
and can offer a GUI to reorder and enable/disable the Sieves (including 
ones by other clients).

Ok, strawmen are meant to be bashed so bash away...

		- Chris

> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jmap&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=27Vu7AQgrnPiwFD08DlPCM_c_FE68RWdyBCpytmUuxY&s=rbZUMaAM-FCuKja2ekQGKYSHjLneRGhJEDkjwC9Sa-E&e=