Internet DRAFT - draft-happel-sieve-filter-rule-metadata
draft-happel-sieve-filter-rule-metadata
Network Working Group H.-J. Happel
Internet-Draft audriga GmbH
Intended status: Informational 13 March 2023
Expires: 14 September 2023
Sieve Filter Rule Metadata
draft-happel-sieve-filter-rule-metadata-00
Abstract
This document describes current practices in managing Sieve scripts
and proposes a standardized way for storing filter rule metadata in
Sieve comments.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Happel Expires 14 September 2023 [Page 1]
Internet-Draft Sieve Filter Rule Metadata March 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. GUI-based email filter editors . . . . . . . . . . . . . 3
1.2. Indirect creation of email filters . . . . . . . . . . . 3
1.3. Special purpose email filters . . . . . . . . . . . . . . 4
1.4. Other kinds of Sieve scripts . . . . . . . . . . . . . . 4
1.5. Conventions Used in This Document . . . . . . . . . . . . 4
2. Modular Sieve scripts in practice . . . . . . . . . . . . . . 4
2.1. Rule comments . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Deactivation of filtering rules . . . . . . . . . . . . . 5
2.2.1. Example: Commenting out . . . . . . . . . . . . . . . 5
2.2.2. Example: Wrapping . . . . . . . . . . . . . . . . . . 5
2.3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Proposed conventions . . . . . . . . . . . . . . . . . . . . 6
3.1. Script comments . . . . . . . . . . . . . . . . . . . . . 6
3.2. Rule comments . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Deactivation of filtering rules . . . . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. CriticalPath . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Horde (Ingo) . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Oracle Communication Messaging Server . . . . . . . . . . 8
4.4. OpenXchange . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. OpenWave/InterMail . . . . . . . . . . . . . . . . . . . 9
5. Security considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Sieve is a formal language for email filtering specified in
(RFC5228). Filters are stored in so called "scripts", which are text
files containing Sieve filtering expressions.
Users can edit Sieve scripts directly, in case they have access to
the script files, or by using the ManageSieve protocol (RFC5804), if
it is made available by their email service.
While experienced users may follow this approach, (RFC5228, section
1) anticipates that "GUI-based editors will be the preferred way of
editing filters for a large number of users."
This likely describes current practice, given that typical end users
rarely have direct access to their Sieve scripts, and given that most
email services do not offer ManageSieve access. Furthermore, even
for a popular email client such as Thunderbird, only very rough
Script editors seem to exist [TBSieve].
Happel Expires 14 September 2023 [Page 2]
Internet-Draft Sieve Filter Rule Metadata March 2023
1.1. GUI-based email filter editors
Many Webmail and Groupware software features GUI-based email filter
editors, which use Sieve as the underlying script language. When
creating filters, the editor will create or update the user's Sieve
script. When opening the editor, the script will be parsed and
presented in a constrained set of UI widgets (such as dropdown-lists
or input fields).
The vast majority (if not all) GUI-based editors follow a similar
interaction paradigm, which is designed along the Sieve language
design concepts. A user first needs to define a "test" (RFC5228,
section 2.5), which defines filtering criteria (e.g., based on sender
or size of a message). The second major component is the definition
of one or more "actions" (RFC5228, section 4), such as to move an
email matching the filtering criteria into a certain mailbox.
The design of existing editors affords users to _modularize_ their
email filters, so that multiple test/action style "fiter rules" are
created. The "else" and "elseif" keywords, which are common in free-
form Sieve scripts (RFC5228, section 9), are typically not used in
those modularized filter rules.
Modularized filter rules often contain a "stop;" commend as their
final action by default, which makes them widely independent of each
other. GUI-based email filter editors typically allow users to label
and to (re-)order filter rules.
1.2. Indirect creation of email filters
Besides a dedicated GUI-based editor for email filters, many Webmail
and Groupware software include additional ways to modify the Sieve
script of a user. There are _contextual_ interfaces, which create
rules in the background or which launch a prefilled filter rule
creation dialog.
Examples are:
* Creating a filter rule based on a sender's email address ("Move
all emails from "John Doe" to ...")
* Adding a sender to a block- or allowlist
The latter case is also an example for special purpose filters as
described in the following.
Happel Expires 14 September 2023 [Page 3]
Internet-Draft Sieve Filter Rule Metadata March 2023
1.3. Special purpose email filters
Email filters are often used as a technology for realizing other
features, such as blocklists, vacation messages [RFC5230], or email
forwarding. In most of these cases, there will be a _dedicated user
interface_ specific to the feature. This user interface will still
write to the user's Sieve script, but the corresponding email filter
will either not be editable or hidden in the regular email filter
editor.
This special handling in the filter editor (i.e., the recognition of
a special purpose filter rule) is typically based on metadata which
is captured in Sieve comments (see also Section 4).
1.4. Other kinds of Sieve scripts
Besides capturing rules based on user input, Sieve scripts are
sometimes also used in other ways. E.g., some SPAM filtering systems
use machine-generated Sieve scripts for their operations. Such
scripts are typically hidden from end users and hence cannot be
edited. They are out of the scope of this draft.
1.5. Conventions Used in This Document
2. Modular Sieve scripts in practice
2.1. Rule comments
In order to manage modularized Sieve scripts, GUI-based script
editors need to capture the following information.
* The _type_ of a rule, distinguishing user-defined rules from
certain special-purpose rules. Examples for the latter are:
VACTION, SPAM, ALLOWED/BLOCKED SENDER, AUTOFORWARD.
* The user-defined name of a rules, as shown in the rule management
UI. Some systems will use predefined rule names instead of rule
types.
In addition to this, some systems store further information:
* Rule Id: an id for internal reference and/or ordering of rules in
processing and list presentation.
* Rule position: a numberic value to maintain the ordering of filter
rules in a separate field.
* Rule description: additional notes complementing the rule label
Happel Expires 14 September 2023 [Page 4]
Internet-Draft Sieve Filter Rule Metadata March 2023
Since none of this information is natively supported by the Sieve
rule language, systems fall back to Sieve comments for storing.
Various vendor-specific practices have emerged, as seen in Section 4.
2.2. Deactivation of filtering rules
Another aspect of informal standardization has been the deacativation
of certain Sieve code. Based on the RFC, Sieve offers two means of
deactivation:
* Commenting out Sieve code
* Keeping one active and multiple deativated scripts (as per
ManageSieve (RFC5804, section 1.4))
While some vendors using type (b) scripts rely on commenting out for
disabling individual modular rules, others came up with more
formalized approaches such as wrapping disabled rules using a simple
"if (false)" clause.
2.2.1. Example: Commenting out
The following filtering rule is take from an OpenXChange-generated
Sieve script:
Flag: |UniqueId:15|Rulename: testRuleCreate
if true
{
discard ;
}
Once "deactivated" in the user interface, this filtering rule will be
represented in the Sieve script as follows:
## Flag: |UniqueId:15|Rulename: testRuleCreate
#<!-->if true
#<!-->{
#<!--> discard ;
#<!-->}
2.2.2. Example: Wrapping
The following filtering rule is take from an CriticalPath-generated
Sieve script:
if allof (true, header :contains "X-Priority" "5")
{
discard;
}
Happel Expires 14 September 2023 [Page 5]
Internet-Draft Sieve Filter Rule Metadata March 2023
Once "deactivated" in the user interface, this filtering rule will be
represented in the Sieve script as follows:
if allof (false, header :contains "X-Priority" "5")
{
discard;
}
2.3. Issues
While the described informal workarounds helped vendors to cope
within the boundaries of the Sieve language, we see a number of
issues with this status quo:
* Interoperability: Vendor-specific workarounds tend to work only
with the vendors own user interfaces. Any attempt to edit the
resulting Sieve scripts can essentially cause trouble displaying
these scripts respectively their contained rules within the
vendors UI. Furthermore, editing special-purpose rules might even
lead to more severe side effects. The lack of interoperability
might be considered a barrier for the implementation of useful
Sieve clients, which in turn hinders more widespread adoption of
Sieve.
* Portability: similar to the way Sieve clients should be able to
interoperate with the Sieve usage of servers, Sieve scripts should
be portable between different Sieve server vendors. Otherwise,
users will not be able to transfer their data between different
providers.
3. Proposed conventions
The purpose of this section is to propose a normative reference for
filtering rule comments and deactivation.
3.1. Script comments
(TBD)
3.2. Rule comments
(TBD)
3.3. Deactivation of filtering rules
For the purpose of deactivating rules, the "wrapping" approach
described in the previous section should be applied.
(TBD)
Happel Expires 14 September 2023 [Page 6]
Internet-Draft Sieve Filter Rule Metadata March 2023
4. Examples
In this section, we will document Sieve script patterns used by the
software of different vendors.
"(...)" stands for omitted code in example scripts.
4.1. CriticalPath
# cp_filter_name: Test filter
# cp_filter_description:
4.2. Horde (Ingo)
Happel Expires 14 September 2023 [Page 7]
Internet-Draft Sieve Filter Rule Metadata March 2023
# Sieve Filter
# Generated by Ingo (http://www.horde.org/apps/ingo/) (09/03/2021, 05:37:41 PM)
require ["vacation", "regex", "fileinto", "imapflags", "body", "reject", "notify"];
# Whitelisted Addresses
if address :all :comparator "i;ascii-casemap" :is ["From", "Sender", "Resent-From"] "whitelist@foo.com" {
keep;
stop;
}
# Vacation
(...)
# Blacklisted Addresses
if address :all :comparator "i;ascii-casemap" :is ["From", "Sender", "Resent-From"] "non@foo.com" {
discard;
stop;
}
# Spamfilter
if header :comparator "i;ascii-casemap" :matches "X-Spam-Status" "yes*" {
fileinto "spamblock";
stop;
}
# Forwards
if true {
redirect "fws@foo.com";
}
# userDefined Rule (Name: fileInto userDefinedFolder)
if address :all :comparator "i;ascii-casemap" :contains "To" "x" {
fileinto "userDefinedFolder";
stop;
}
4.3. Oracle Communication Messaging Server
#RULE: $Name="Blocked senders" $Type="BLOCKED_ADDRESSES" $Version=1 $Lz=1 $Order=1
#BEGINFILTER
(...)
#ENDFILTER
#RULE: $Name="Test Folder Bulkmail" $Type="DEFAULT_TYPE" $Version=1 $Lz=1 $Order=6
#require "fileinto";
(...)
#ENDRULE
Happel Expires 14 September 2023 [Page 8]
Internet-Draft Sieve Filter Rule Metadata March 2023
4.4. OpenXchange
## Flag: vacation|UniqueId:1|Rulename: vacation notice
## Flag: autoforward|UniqueId:2|Rulename: autoforward
## Flag: |UniqueId:0|Rulename: MyTestFiler
4.5. OpenWave/InterMail
5. Security considerations
TBD
6. IANA Considerations
This document has no IANA actions at this time.
7. Informative References
[TBSieve] Schmid, T., "Thunderbird Sieve Add-On",
<https://addons.thunderbird.net/de/thunderbird/addon/
sieve/>.
Author's Address
Hans-Joerg Happel
audriga GmbH
Email: happel@audriga.com
URI: https://www.audriga.com
Happel Expires 14 September 2023 [Page 9]
