Subject: [Extra] [Sieve] Dealing with informal conventions in generated Sieve scripts

From: Hans-Joerg Happel <[email-masked]>
Date: Thu, 21 Oct 2021 19:06:24 +0200

Hi,

in a recent discussion about the JMAP for Sieve draft in the JMAP WG, we 
identified some issues with the current usage of Sieve in the wild.

I might have a partial view, but roughly I'd classify Sieve usage as 
follows:

1) User-defined Sieve rules
1.1) Tool-assisted Sieve rules (mainly via Webmail filter forms/UIs)
1.2) Free-form Sieve rules (created by expert users with knowledge of 
Sieve syntax)
2) Other usages of Sieve (e.g., in automated pre- or postprocessing of 
mails)

My main concern is *user-defined* rules of type 1.1, which I would argue 
are more common than free-form rules (as they are supposed to represent 
the majority of non-expert end users).

Type 1.1 rules as I discuss here, are usually generated by code, based 
on user interaction in some rule API/Webmailer. In these settings, 
there's typically one Sieve script, which is composed of a set of 
individual rules, which each correspond to one user-defined rule.

Some of these rules might be only indirectly created by the user (e.g., 
"special use" rules such as vacation notice/OOF rules) and not be 
editable or visible to the user as a rule.

Within that category of rules, we observed a number of informal 
conventions, which different vendors apply. Things we observed are:

a) The underlying software (e.g., groupware) may be mentioned as a 
comment in the rule header (e.g., [1]).

b) Comments are used by several systems to denote:
* Rule names (e.g., [2])
* Rule description (rare?)
* Rule types (for "special use" rules) (e.g., [1])
* Rule id (e.g., [2])

c) For disabling individual rules, different mechanisms may be used:
* Moving a rule to inactive Sieve script
* Commenting out an individual rule
* Wrapping with "if(true/false)" or "allOf(true/false, ..)"

So, what's the point now?

For our use case of rule migration, we basically apply certain parsing 
and mapping based on knowing (or guessing) what the underlying software 
is / what conventions it uses.

Essentially, this applies to any (ManageSieve) client, which is not the 
"default" client (which created to the rule) by itself. If such clients 
do not follow the mentioned informal practices, there might be 
interoperability issues by interfering with the conventions expected by 
the underlying groupware.

This led us to propose in JMAP for Sieve, that there should be an option 
that a server identifies the underlying system, so that clients can 
apply mentioned adaptions.

I was then asked to summarize issues for this list, as this affects 
general Sieve usage as well - probably to check if mentioned informal 
practices might be standardized for future use.

As said, my view is certainly incomplete, so I look forward to learn 
about further experiences.

Thanks and best,
Hans-Joerg

[1] Horde

# Sieve Filter
# Generated by Ingo (http://www.horde.org/apps/ingo/) (09/03/2021, 
05:37:41 PM)

....

# Vacation

[2] OpenXChange

## Flag: |UniqueId:14|Rulename: aktuelles Datum

-- 
audriga GmbH
Durlacher Allee 47
76131 Karlsruhe
Tel: +49 (0) 721 17029 316
Fax: +49 (0) 721 17029 3179

[email-masked]
https://www.audriga.com

Handelsregister: Amtsgericht Mannheim - HRB 713034
Sitz der Gesellschaft: Karlsruhe
Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel
USt-ID: DE 279724142