Network Working Group N. Freed Internet-Draft S. Vedam Expires: July 18, 2009 Sun Microsystems January 14, 2009 Sieve Email Filtering: Sieves and display directives in XML draft-freed-sieve-in-xml-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 18, 2009. Copyright Notice Copyright (c) 2009 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 (http://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. Abstract This document describes a way to represent Sieve email filtering language scripts in XML. Representing sieves in XML is intended not Freed & Vedam Expires July 18, 2009 [Page 1] Internet-Draft An XML Representation for Sieve January 2009 as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools. The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. Change History (to be removed prior to publication as an RFC Changed representation of comments in XML to use a comment element. Updatde references. Added an IANA registration of a URN for the Sieve namespace. Updated XML Schema to allow largely unrestricted use of material in other namespaces. Add compact Relax NG schema. Updated example stylesheet to handle material in other namespaces. Corrected stylesheet handling of elements. Added a section defining the structured comment convention. Moved the examples section to an appendix. Freed & Vedam Expires July 18, 2009 [Page 2] Internet-Draft An XML Representation for Sieve January 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 5 3. Grammatical structure of Sieve . . . . . . . . . . . . . . . . 5 4. XML Representation of Sieve . . . . . . . . . . . . . . . . . 6 4.1. XML Display Directives . . . . . . . . . . . . . . . . . . 8 4.2. Structured Comments . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Extended Example . . . . . . . . . . . . . . . . . . 12 Appendix B. XML Schema for Sieves in XML . . . . . . . . . . . . 19 Appendix C. Relax NG Schema for Sieves in XML . . . . . . . . . . 22 Appendix D. Stylesheet for conversion from XML . . . . . . . . . 23 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Freed & Vedam Expires July 18, 2009 [Page 3] Internet-Draft An XML Representation for Sieve January 2009 1. Introduction Sieve [RFC5228] is a language for filtering email messages at or around the time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system and it is intended to be manipulated by a variety of different user interfaces. Some user interface environments have extensive existing facilities for manipulating material represented in XML. While adding support for alternate data syntaxes may be possible in most if not all of these environments, it may not be particularly convenient to do so. The obvious way to deal with this issue is to map sieves into XML, possibly on a separate backend system, manipulate the XML, and convert it back to normal Sieve format. The fact that conversion into and out of XML may be done as a separate operation on a different system argues strongly for defining a common XML representation for Sieve. This way different front end user interfaces can be used with different back end mapping and storage facilities. Another issue with the creation and manipulation of sieve scripts by user interfaces is that the language is strictly focused on describing email filtering operations. The language contains no mechanisms for indicating how a given script should be presented in a user interface. Such information can be represented in XML very easily so it makes sense to define a framework to do this as part of the XML format. A structured comment convention is then used to retain this information when the script is converted to normal Sieve format. Various sieve extensions have already been defined, e.g., [RFC5183] [RFC5229] [RFC5230] [RFC5231] [RFC5232] [RFC5233] [RFC5235] [RFC5293], and more are planned. The set of extensions available varies from one implementation to the next and may even change as a result of configuration choices. It is therefore essential that the XML representation of Sieve be able to accommodate Sieve extensions without requiring schema changes. It is also desirable that Sieve extensions not require changes to the code that converts to and from the XML representation. This specification defines an XML representation for sieve scripts and explains how the conversion process to and from XML works. The XML representation is capable of accommodating any future Sieve extension as long as the underlying Sieve grammar remains unchanged. Furthermore, code that converts from XML to the normal Sieve format Freed & Vedam Expires July 18, 2009 [Page 4] Internet-Draft An XML Representation for Sieve January 2009 requires no changes to accommodate extensions, while code used to convert from normal Sieve format to XML only requires changes when new control commands are added - a rare event. An XML Schema, Relax NG Schema, and a sample stylesheet to convert from XML format are also provided in the appendices. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Grammatical structure of Sieve The Sieve language is designed to be highly extensible without making any changes to the basic language syntax. Accordingly the syntax of Sieve, defined in section 8 of [RFC5228], is entirely structural in nature and employs no reserved words of any sort. Structurally a sieve script consists of a series of commands. Each command in turn consists of an identifier, zero or more arguments, a optional test or test-list, and finally an optional block containing another series of commands. Commands are further broken down into controls and actions, although this distinction cannot be determined from the grammar. Some example Sieve controls are: stop; <-- No arguments, test, or command block require "fileinto"; <-- Control with a single argument if true {stop;} <-- Control with test and command block Some examples of Sieve actions are: discard; <-- Action with no args, test, or command block fileinto "folder"; <-- Action with an argument At the time of this writing there are no controls defined that accept both arguments and a test. Similarly, there are currently no defined actions that allow either a test or a command block. Nevertheless, the Sieve grammar allows such constructs to be defined by some future extension. A test consists of an identifier followed by zero or more arguments, then another test or test-list. Unlike commands, tests cannot be followed by a command block. Freed & Vedam Expires July 18, 2009 [Page 5] Internet-Draft An XML Representation for Sieve January 2009 Here are some examples of Sieve tests. Note that such tests have to appear as part of a command in order to be syntactically valid: true <-- Test with no argument or subordinate test envelope "to" "me@example.com" <-- Test with several arguments header :is "from" "you@example.com" <-- Test with tagged argument Command or test arguments can be either string lists, whole numbers or tags. (Tags are simply identifiers preceded by a colon.) Note that although the Sieve grammar treats single strings as a degenerate case of a string list, some tests or actions have arguments that can only be individual strings, not lists. Here is an example showing the use of both a test-list and a string list: if anyof (not exists ["From", "Date"], header :contains "from" "fool@example.edu") { discard; } Extensions can add new controls, actions, tests, or new arguments to existing controls or actions. Extensions have also changed how string content is interpreted, although this is not relevant to this specification. However, it is especially important to note that so far no Sieve extension has added a new control to the language and it seems safe to assume that due to their nature future addition of controls will be rare. Finally, comments are allowed between lexical elements in a Sieve script. It is very important that comments be preserved in the XML representation. 4. XML Representation of Sieve Sieve controls and actions are represented in XML as control or action elements respectively. The command's identifier appears as a name attribute on the element itself. This is the only attribute allowed on controls and actions - arguments, tests, test-lists, and nest command blocks are all represented as nested elements. While naming the element after the control or action itself may seem like a better choice, doing so would result in extensions requiring corresponding schema changes. The example Sieve controls shown in the previous section would be represented in XML as: Freed & Vedam Expires July 18, 2009 [Page 6] Internet-Draft An XML Representation for Sieve January 2009 fileinto The example Sieve actions shown above would appear in XML as: folder The separation of controls from actions in the XML representation means that conversion from normal Sieve format to XML has to be able to distinguish between controls and actions. This is easily done by maintaining a list of all known controls since experience indicates new controls are rarely added. Tests are represented in the same basic way as controls and actions, that is, as a test element with a name attribute giving the test identifier. For example: tome@example.com isfromyou@example.com String, number, and tag arguments are represented as str, num, and tag elements respectively. The actual string, number, or tag identifier appears as text inside the element. None of these elements have any defined attributes. Several examples of arguments have already appeared in the preceding control, action and test examples. String list arguments are represented as a list element which in turn contains one or more str elements. Note that this allows the distinction between a single string and a string list containing a single string to be preserved. This is not essential since a list containing a single string could simply be mapped to a string, but it seems prudent to maintain the distinction when mapping to and from XML. Nested command blocks appear as a series of control or action elements inside of an outer control or action element. No block element is needed since an inner command block can only appear once Freed & Vedam Expires July 18, 2009 [Page 7] Internet-Draft An XML Representation for Sieve January 2009 and only after any arguments, tests, or test-lists. For example: contains from fool@example.edu Finally, Sieve comments are mapped to a special comment element in XML. Both hash and bracketed comments are mapped to the same construct so the distinction between the two is lost in XML. XML comments are not used because some XML tools do not make it convenient to access comment nodes. 4.1. XML Display Directives Sometimes graphical user interfaces are a convenient way to provide sieve management functions to users. These interfaces typically summarize/annotate/group/display sieve script(s) in an intuitive way for end users. To do this effectively, the graphical user interface may require additional information about the sieve script itself. That information or "meta-data" might include, but is not limited to - a sieve name (identifying the current sieve), whether the sieve is enabled or disabled, the order in which the part of the sieve are presented to the user. The graphical user interface may also choose to provide mechanisms to allow the user to modify the script. It is often useful for a graphical user interface to group related sieve script elements and provide an interface that display these groups separately so they can be managed as a single object. Some examples include Sieve statements that together provide vacation responders, blacklists/whitelists and other types of filtering controls. Some advanced graphical user interfaces may even provide a natural language representation of a sieve script and/or an advanced Freed & Vedam Expires July 18, 2009 [Page 8] Internet-Draft An XML Representation for Sieve January 2009 interface to present sieve statements directly to the user. A graphical user interface may also choose to support only a subset of action commands in the Sieve language (and its extensions) and so a mechanism to indicate the extent of support and characterize the relationships between those supported action commands and test (with its arguments) is immensely useful and probably required for clients that may not have complete knowledge of sieve grammar and semantics. The Sieve language contains no mechanisms for indicating how a given script should be presented in a user interface. The language also does not contain any specific mechanisms to represent other sorts of meta-data about the script. Providing support for such meta-data as part of a sieve script is currently totally implementation specific and is usually done by imposing some type of structure on comments. However, such information can be represented in XML very easily so it makes sense to define a framework to do this as part of the XML format. Implementations may choose to use structured comments to retain this information when the script is converted to normal Sieve format. The schema for the XML representation of Sieve allows XML in other namespaces to be inserted in most places in Sieve scripts. This is the preferred means of including additional information. Alternately, the schema defines two display directives - displayblock and displaydata - as containers for meta-data needed by graphical user interfaces. The displayblock element can be used to enclose any number of sieve statements at any level. It is semantically meaningless to the sieve script itself. It allows an arbitrary set of attributes. Implementations MAY use this to provide many simple, display related meta-data for the sieve such as sieve identifier, group identifier, order of processing, etc. The displaydata element supports any number of arbitrary child elements. Implementations MAY use this to represent complex data about that sieve such as a natural language representation of sieve or a way to provide the sieve script directly. Again, this information SHOULD be preserved in structured comments when converted. 4.2. Structured Comments Since the XML representation is not intended as a storage format there needs to be a way to preserve the additional information that can be included in the XML representation in the normal Sieve syntax. Freed & Vedam Expires July 18, 2009 [Page 9] Internet-Draft An XML Representation for Sieve January 2009 This is done through the use of three structured comment conventions: 1. XML content in other namespaces is placed in Sieve bracketed comments beginning with the string "/* [/" and ending with the string "/] */". 2. Displaydata elements are placed in Sieve bracketed comments begining with the string "/* [|" and ending with the string "|] */". 3. The begininng of a displayblock element is mapped to a bracketed Sieve comment beginning with the string "/* [*" which then lists any displayblock attribute names and values in XML format. The end of a displaydata element is mapped to a comment of the form "/* *] */". Processors MUST preserve the additional information allowed in the XML format and SHOULD use the structured comment format shown above. 5. Security Considerations Any syntactically valid sieve script can be represented in XML. Accordingly, all security considerations applicable to Sieve and any extensions used also apply to the XML representation. The use of XML carries its own security risks. Section 7 of RFC 3470 [RFC3470] discusses these risks. Arbitrary data can be included using other namespaces or placed in the extensible displayblock and displaydata constructs defined in this specification, possibly including entire scripts and other executable content in languages other than Sieve. Appropriate security precautions should be taken when using these facilities. 6. IANA Considerations This section registers a new XML namespace per the procedures in RFC 3688 [RFC3688]. Freed & Vedam Expires July 18, 2009 [Page 10] Internet-Draft An XML Representation for Sieve January 2009 URI: urn:ietf:params:xml:ns:sieve Registrant Contact: IETF Sieve working group XML: BEGIN Sieve Namespace

Namespace for Sieve Language objects expressed in XML

urn:ietf:params:xml:ns:sieve

See RFC XXXX.

END 7. References 7.1. Normative References [OASISRNC] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification rnc, November 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008. Freed & Vedam Expires July 18, 2009 [Page 11] Internet-Draft An XML Representation for Sieve January 2009 7.2. Informative References [RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", RFC 5183, May 2008. [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008. [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008. [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: Relational Extension", RFC 5231, January 2008. [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags Extension", RFC 5232, January 2008. [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress Extension", RFC 5233, January 2008. [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008. [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering: Editheader Extension", RFC 5293, August 2008. Appendix A. Extended Example The example sieve script given in section 9 of [RFC5228] would be represented in XML as follows: Example Sieve Filter Declare any optional features or extensions used by the script fileinto Handle messages from known mailing lists Move messages from IETF filter discussion list to filter mailbox Freed & Vedam Expires July 18, 2009 [Page 12] Internet-Draft An XML Representation for Sieve January 2009 is Sender owner-ietf-mta-filters@imc.org filter move to "filter" mailbox Keep all messages to or from people in my company domain is From To example.com Try and catch unsolicited email. If a message is not to me, or it contains a subject known to be spam, file it away. all contains To Cc Bcc me@example.com matches subject *make*money*fast* Freed & Vedam Expires July 18, 2009 [Page 13] Internet-Draft An XML Representation for Sieve January 2009 *university*dipl*mas* spam Move all other (non-company) mail to "personal" mailbox. personal The same script could be annotated with graphical display hints in a variety of ways. Three possibilities are: fileinto is Sender owner-ietf-mta-filters@imc.org filter domain Freed & Vedam Expires July 18, 2009 [Page 14] Internet-Draft An XML Representation for Sieve January 2009 is From To example.com all contains To Cc Bcc me@example.com matches subject *make*money*fast* *university*dipl*mas* spam personal Freed & Vedam Expires July 18, 2009 [Page 15] Internet-Draft An XML Representation for Sieve January 2009 Note that since displayblock elements are semantically null as far as the script itself is concerned they can be used to group structures like elsif and else that are tied to statements in other groups. The representation of this script in regular Sieve syntax uses structured comments: require "fileinto"; /* [* name="File filter list mail" order="1" group="FILE_TO_FOLDER" enable="true" */ if header :is "Sender" "owner-ietf-mta-filters@imc.org" { fileinto "filter"; } /* *] */ /* [* name="Keep all company mail" order="2" group="KEEP_MESSAGE" enable="true" */ elsif address :domain :is [ "From", "To" ] "example.com" { keep; } /* *] */ /* [* name="File suspected spam" order="3" group="FILE_TO_FOLDER" enable="true" */ elsif anyof ( not ( address :all :contains [ "To", "Cc", "Bcc" ] "me@example.com" ), header :matches "subject" [ "*make*money*fast*", "*university*dipl*mas*" ] ) { fileinto "spam"; } /* *] */ /* [* name="File noncompany mail as personal" order="4" group="FILE_TO_FOLDER" enable="true" */ else { fileinto "personal"; } /* *] */ A separate namespace can be used to embed text or structured information: Freed & Vedam Expires July 18, 2009 [Page 16] Internet-Draft An XML Representation for Sieve January 2009 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org then file it into the "filter" folder. Otherwise if the address in the "From" or "To" has a domain that is "example.com" then keep it. Otherwise messages meeting with any of these conditions: (1) None of the addresses in "To" or "Cc" or "Bcc" contains the domain "example.com". (2) The "Subject" field matches the pattern *make*money*fast* or *university*dipl*mas* then file it into the "spam" folder. If all else fails then file the message in the "personal" folder. ... the actual sieve script ... Alternately, displaydata elements can be used to accomplish the same thing: Freed & Vedam Expires July 18, 2009 [Page 17] Internet-Draft An XML Representation for Sieve January 2009 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org then file it into the "filter" folder. Otherwise if the address in the "From" or "To" has a domain that is "example.com" then keep it. Otherwise messages meeting with any of these conditions: (1) None of the addresses in "To" or "Cc" or "Bcc" contains the domain "example.com". (2) The "Subject" field matches the pattern *make*money*fast* or *university*dipl*mas* then file it into the "spam" folder. If all else fails then file the message in the "personal" folder. ... the actual sieve script ... Again, structured comments are used to represent this in regular Sieve syntax: Freed & Vedam Expires July 18, 2009 [Page 18] Internet-Draft An XML Representation for Sieve January 2009 /* [| If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org then file it into the "filter" folder. Otherwise if the address in the "From" or "To" has a domain that is "example.com" then keep it. Otherwise messages meeting with any of these conditions: (1) None of the addresses in "To" or "Cc" or "Bcc" contains the domain "example.com". (2) The "Subject" field matches the pattern *make*money*fast* or *university*dipl*mas* then file it into the "spam" folder. If all else fails then file the message in the "personal" folder. |] */ ... the actual sieve script ... Appendix B. XML Schema for Sieves in XML This appendix is informative. The following is an XML Schema for the XML representation of Sieve scripts. Most of the elements employing a complex content model allow use of elements in other namespaces, subject to lax XML Schema validation rules. Additionally, displaydata elements can be used to encapsulate arbitrary XML content. Finally, displayblock elements can be used as a general- purpose grouping mechanism - arbitrary attributes are allowed on displayblock elements. Freed & Vedam Expires July 18, 2009 [Page 19] Internet-Draft An XML Representation for Sieve January 2009 Freed & Vedam Expires July 18, 2009 [Page 20] Internet-Draft An XML Representation for Sieve January 2009 Freed & Vedam Expires July 18, 2009 [Page 21] Internet-Draft An XML Representation for Sieve January 2009 Appendix C. Relax NG Schema for Sieves in XML This appendix is informative. The following defines a Relax NG schema using compact notation OASISRNC [OASISRNC] for the XML representation of Sieve scripts. Most of the elements employing a complex content model allow unrestricted use of elements in other namespaces. Additionally, displaydata elements can be used to encapsulate arbitrary XML content. Finally, displayblock elements can be used as a general-purpose grouping mechanism - arbitrary attributes are allowed on displayblock elements. namespace sieve = "urn:ietf:params:xml:ns:sieve" start = element sieve:sieve { ( control | action | displayblock | displaydata | comment | ext )* } comment = element sieve:comment { xsd:string } command = ( attribute name { xsd:token { pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, ( str | num | \list | tag | displaydata | comment | ext )*, test?, ( control | action | displayblock | displaydata | comment | ext )* ), empty control = element sieve:control { command } action = element sieve:action { command } test = element sieve:test { Freed & Vedam Expires July 18, 2009 [Page 22] Internet-Draft An XML Representation for Sieve January 2009 attribute name { xsd:token { pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, ( str | num | \list | tag | comment | ext )*, test* } \list = element sieve:list { str+ } tag = element sieve:tag { xsd:token { pattern = "[A-Za-z_][A-Za-z0-9_]*" } } str = element sieve:str { xsd:string } num = element sieve:num { xsd:nonNegativeInteger } any = ( element * { any } | attribute * { text } | text )* ext = element * - sieve:* { any }* displayblock = element sieve:displayblock { ( control | action | displayblock | displaydata | comment | ext )*, attribute * { text }* } displaydata = element sieve:displaydata { any* } Appendix D. Stylesheet for conversion from XML This appendix is informative. The following stylesheet can be used to convert the Sieve in XML representation to regular Sieve format. Content in other namespaces, displaydata, and displayblock elements are converted to structured comments as appropriate. \" \\ Freed & Vedam Expires July 18, 2009 [Page 24] Internet-Draft An XML Representation for Sieve January 2009 { } ; Freed & Vedam Expires July 18, 2009 [Page 25] Internet-Draft An XML Representation for Sieve January 2009 ( , ) " " G M K [ Freed & Vedam Expires July 18, 2009 [Page 26] Internet-Draft An XML Representation for Sieve January 2009 , ] : /* */ /* [* */ /* *] */ /* [| Freed & Vedam Expires July 18, 2009 [Page 27] Internet-Draft An XML Representation for Sieve January 2009 |] */ /* [/ /] */ < /> < Freed & Vedam Expires July 18, 2009 [Page 28] Internet-Draft An XML Representation for Sieve January 2009 > </ > =" " Appendix E. Acknowledgements The stylesheet copy mode code is loosely based on a sample code posted to the xsl-list list by Americo Albuquerque. Andrew McKeon, Alexey Melnikov, and Aaron Stone provided useful comments on the document. Authors' Addresses Ned Freed Sun Microsystems 800 Royal Oaks Monrovia, CA 91016-6347 USA Phone: +1 909 457 4293 Email: ned.freed@mrochek.com Freed & Vedam Expires July 18, 2009 [Page 29] Internet-Draft An XML Representation for Sieve January 2009 Srinivas Saisatish Vedam Sun Microsystems Phone: +91 80669 27577 Email: Srinivas.Sv@Sun.COM Freed & Vedam Expires July 18, 2009 [Page 30]