diff options
Diffstat (limited to 'doc/rfc/rfc5784.txt')
| -rw-r--r-- | doc/rfc/rfc5784.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc5784.txt b/doc/rfc/rfc5784.txt new file mode 100644 index 0000000..5222ecf --- /dev/null +++ b/doc/rfc/rfc5784.txt @@ -0,0 +1,1795 @@ + + + + + + +Internet Engineering Task Force (IETF) N. Freed +Request for Comments: 5784 S. Vedam +Category: Standards Track Sun Microsystems +ISSN: 2070-1721 March 2010 + + + Sieve Email Filtering: Sieves and Display Directives in XML + +Abstract + + This document describes a way to represent Sieve email filtering + language scripts in XML. Representing Sieves in XML is intended not + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5784. + + + + + + + + + + + + + + + + +Freed & Vedam Standards Track [Page 1] + +RFC 5784 An XML Representation for Sieve March 2010 + + +Copyright Notice + + Copyright (c) 2010 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. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 + 3. Grammatical Structure of Sieve . . . . . . . . . . . . . . . . 4 + 4. XML Representation of Sieve . . . . . . . . . . . . . . . . . 6 + 4.1. XML Display Directives . . . . . . . . . . . . . . . . . . 9 + 4.2. Structured Comments . . . . . . . . . . . . . . . . . . . 10 + 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Extended Example . . . . . . . . . . . . . . . . . . 14 + Appendix B. XML Schema for Sieves in XML . . . . . . . . . . . . 21 + Appendix C. Relax NG Schema for Sieves in XML . . . . . . . . . . 24 + Appendix D. Stylesheet for Conversion from XML . . . . . . . . . 26 + Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 32 + + + + + + + + + + + + + + + + + +Freed & Vedam Standards Track [Page 2] + +RFC 5784 An XML Representation for Sieve March 2010 + + +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 [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 back-end 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. + + It should be noted, however, that the ability for different front + ends to use the same mapping and storage facilities does not mean + that the additional XML information produced by different front ends + will interoperate. + + 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. + + + + +Freed & Vedam Standards Track [Page 3] + +RFC 5784 An XML Representation for Sieve March 2010 + + + 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 + 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]. + + The term "processor" is used throughout this document to refer to + agents that convert Sieve to and from the XML representation. The + term "editor" refers to agents that operate on, possibly creating or + modifying, Sieves in XML format. + +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, + an 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 arguments, test, or command block +fileinto "folder"; <-- Action with an argument + + + + + +Freed & Vedam Standards Track [Page 4] + +RFC 5784 An XML Representation for Sieve March 2010 + + + 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. + + 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 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, only one of the many defined Sieve extensions -- the + foreverypart extension [RFC5703] -- has added new controls to the + language. It seems safe to assume that, due to their nature, future + addition of controls will be relatively rare. + + Finally, comments are allowed between lexical elements in a Sieve + script. One important use case for comments is encoding meta-data + about the script, a facility that is lacking in the Sieve language. + Therefore, comments need to be preserved in the XML representation. + + + + + + + +Freed & Vedam Standards Track [Page 5] + +RFC 5784 An XML Representation for Sieve March 2010 + + +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 + nested 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 frequent + corresponding schema changes. + + The example Sieve controls shown in the previous section would be + represented as these XML fragments: + + <control name="stop"/> + + <control name="require"><str>fileinto</str></control> + + <control name="if"> + <test name="true"/><control name="stop"/> + </control> + + The example Sieve actions shown above would appear in XML as: + + <action name="discard"/> + <action name="fileinto"><str>folder</str></action> + + 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. At the time of this writing, the list + of defined controls consists of: + + 1. if [RFC5228], + + 2. stop [RFC5228], + + 3. require [RFC5228], + + 4. foreverypart [RFC5703], and + + 5. break [RFC5703]. + + It should be noted that with this approach unknown controls will + simply be treated as actions and can be passed back and forth between + the two representations. The treatment of a control as an action is + + + + +Freed & Vedam Standards Track [Page 6] + +RFC 5784 An XML Representation for Sieve March 2010 + + + unlikely to cause other issues since knowledge of a control's + language semantics is almost always required to take advantage of it. + + 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, the following XML fragments show various + types of tests: + + <test name="true"/> + + <test name="envelope"/> + <str>to</str><str>me@example.com</str> + </test> + + <test name="header"/> + <tag>is</tag><str>from</str><str>you@example.com</str> + </test> + + 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. Any whitespace in the str body content MUST be preserved + by the processor. Also, note that since strings and tags are + represented as element text, any quotes or other syntactic elements + required in the regular Sieve representation are dropped rather than + being carried over into the XML. + + 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 + and only after any arguments, tests, or test-lists. For example: + + + + + + + + + + +Freed & Vedam Standards Track [Page 7] + +RFC 5784 An XML Representation for Sieve March 2010 + + + <control name="if"> + <test name="anyof"> + <test name="not"> + <test name="exists"> + <list><str>From</str><str>Date</str></list> + </test> + </test> + <test name="header"> + <tag>contains</tag> + <str>from</str> + <str>fool@example.edu</str> + </test> + </test> + <action name="discard"/> + </control> + + 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. + + Comments are allowed between commands and inside "test" elements. + But comments aren't allowed directly inside commands -- due to + limitations of XML Schema, special enclosing "preamble" and + "postamble" elements are needed: + + <control name="if"> + <preamble> + <comment>Check to see if message should be discarded</comment> + </preamble> + <test name="anyof"> + <test name="not"> + <test name="exists"> + <list><str>From</str><str>Date</str></list> + </test> + </test> + <test name="header"> + <tag>contains</tag> + <str>from</str> + <str>fool@example.edu</str> + </test> + </test> + <action name="discard"/> + <postamble> + <comment>End of discard check</comment> + </postamble> + </control> + + + +Freed & Vedam Standards Track [Page 8] + +RFC 5784 An XML Representation for Sieve March 2010 + + +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, and the order in which the parts 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 displays 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 + 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 the 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. + + + + + +Freed & Vedam Standards Track [Page 9] + +RFC 5784 An XML Representation for Sieve March 2010 + + + The sample schemata for the XML representation of Sieve allows XML in + foreign namespaces to be inserted in the same places "comment" + elements can appear 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. + + Editors MAY use displayblock, displaydata, and foreign namespaces to + associate meta-data. Some editors find it inconvenient to preserve + this additional data during an editing session. Editors MAY preserve + this data during an editing session for compatibility with other + editors. + + 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. + +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. + 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. The content of displaydata elements is placed in Sieve bracketed + comments beginning with the string "/* [|" and ending with the + string "|] */". + + 3. The beginning 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 displayblock 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. + + + +Freed & Vedam Standards Track [Page 10] + +RFC 5784 An XML Representation for Sieve March 2010 + + + Note: If "*/" is found in the XML content, when mapped into a + comment, it would prematurely terminate that comment. Escaping this + sequence would often be inconvenient for processors. Editors SHALL + NOT include "*/" within displayblock, displaydata, or foreign markup. + Processors MAY regard documents containing "*/" in foreign markup, + displayblock, or displaydata as invalid. + +4.3. Validation + + A processor MAY validate documents against a schema, and it MAY + reject any that do not conform. For any document that a processor + does not reject as invalid, any markup that the processor cannot + understand by reference to this specification MAY be discarded. + + Note that example Relax NG and XML Schema are given in the appendices + below. + +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. + + It is axiomatic that a Sieve editor must be trusted to do what the + user specifies. If XML formats are used, this trust necessarily must + extend to the components involved in converting to and from XML + format. + + 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. Such material will + necessarily have its own security considerations, which are beyond + the scope of this document. + +6. IANA Considerations + + This section registers a new XML namespace per the procedures in RFC + 3688 [RFC3688]. + + + + + + + + + +Freed & Vedam Standards Track [Page 11] + +RFC 5784 An XML Representation for Sieve March 2010 + + + URI: urn:ietf:params:xml:ns:sieve + + Registrant Contact: IETF Sieve working group + <ietf-mta-filters@imc.org> + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Sieve Namespace</title> + </head> + <body> + <h1>Namespace for Sieve Language objects expressed in XML</h1> + <h2>urn:ietf:params:xml:ns:sieve</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc5784.txt"> + RFC 5784</a>. + </p> + </body> + </html> + 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 Standards Track [Page 12] + +RFC 5784 An XML Representation for Sieve March 2010 + + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and + F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth + Edition)", W3C REC-xml-20081126, November 2008, + <http://www.w3.org/TR/2008/REC-xml-20081126/>. + +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. + + [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME + Part Tests, Iteration, Extraction, Replacement, and + Enclosure", RFC 5703, October 2009. + + + + + + + + + + + + + + + + + +Freed & Vedam Standards Track [Page 13] + +RFC 5784 An XML Representation for Sieve March 2010 + + +Appendix A. Extended Example + + The example Sieve script given in Section 9 of [RFC5228] would be + represented in XML as the following code component: + + <sieve xmlns="urn:ietf:params:xml:ns:sieve"> + <comment> + Example Sieve Filter + Declare any optional features or extensions used by the script + </comment> + + <control name="require"> + <str>fileinto</str> + </control> + <comment> + Handle messages from known mailing lists. + Move messages from IETF filter discussion list to filter mailbox. + </comment> + <control name="if"> + <test name="header"> + <tag>is</tag> + <str>Sender</str> + <str>owner-ietf-mta-filters@imc.org</str> + </test> + <action name="fileinto"> + <str>filter</str> + </action> + <postamble> + <comment>move to "filter" mailbox</comment> + </postamble> + </control> + + <comment> + Keep all messages to or from people in my company. + </comment> + <control name="elsif"> + <test name="address"> + <tag>domain</tag> + <tag>is</tag> + <list> + <str>From</str> + <str>To</str> + </list> + <str>example.com</str> + </test> + <action name="keep"/> + </control> + + + + +Freed & Vedam Standards Track [Page 14] + +RFC 5784 An XML Representation for Sieve March 2010 + + + <comment> + Try and catch unsolicited email. If a message is not to me, + or it contains a subject known to be spam, file it away. + </comment> + <control name="elsif"> + <test name="anyof"> + <test name="not"> + <test name="address"> + <tag>all</tag> + <tag>contains</tag> + <list> + <str>To</str> + <str>Cc</str> + <str>Bcc</str> + </list> + <str>me@example.com</str> + </test> + </test> + <test name="header"> + <tag>matches</tag> + <str>subject</str> + <list> + <str>*make*money*fast*</str> + <str>*university*dipl*mas*</str> + </list> + </test> + </test> + <action name="fileinto"> + <str>spam</str> + </action> + </control> + <control name="else"> + <preamble> + <comment> + Move all other (non-company) mail to "personal" + mailbox. + </comment> + </preamble> + <action name="fileinto"> + <str>personal</str> + </action> + </control> + + </sieve> + + + + + + + +Freed & Vedam Standards Track [Page 15] + +RFC 5784 An XML Representation for Sieve March 2010 + + + The same script could be annotated with graphical display hints in a + variety of ways. Three possible code components that do this are: + + <sieve xmlns="urn:ietf:params:xml:ns:sieve"> + + <control name="require"> + <str>fileinto</str> + </control> + + <displayblock name="File filter list mail" order="1" + group="FILE_TO_FOLDER" enable="true"> + <control name="if"> + <test name="header"> + <tag>is</tag> + <str>Sender</str> + <str>owner-ietf-mta-filters@imc.org</str> + </test> + <action name="fileinto"> + <str>filter</str> + </action> + </control> + </displayblock> + + <displayblock name="Keep all company mail" order="2" + group="KEEP_MESSAGE" enable="true"> + <control name="elsif"> + <test name="address"> + <tag>domain</tag> + <tag>is</tag> + <list> + <str>From</str> + <str>To</str> + </list> + <str>example.com</str> + </test> + <action name="keep"/> + </control> + </displayblock> + + <displayblock name="File suspected spam" order="3" + group="FILE_TO_FOLDER" enable="true"> + <control name="elsif"> + <test name="anyof"> + <test name="not"> + <test name="address"> + <tag>all</tag> + <tag>contains</tag> + <list> + + + +Freed & Vedam Standards Track [Page 16] + +RFC 5784 An XML Representation for Sieve March 2010 + + + <str>To</str> + <str>Cc</str> + <str>Bcc</str> + </list> + <str>me@example.com</str> + </test> + </test> + <test name="header"> + <tag>matches</tag> + <str>subject</str> + <list> + <str>*make*money*fast*</str> + <str>*university*dipl*mas*</str> + </list> + </test> + </test> + <action name="fileinto"> + <str>spam</str> + </action> + </control> + </displayblock> + + <displayblock name="File noncompany mail as personal" order="4" + group="FILE_TO_FOLDER" enable="true"> + <control name="else"> + <action name="fileinto"> + <str>personal</str> + </action> + </control> + </displayblock> + + </sieve> + + 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. + + + + + + + + + + + + + + + +Freed & Vedam Standards Track [Page 17] + +RFC 5784 An XML Representation for Sieve March 2010 + + + 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"; + } + /* *] */ + + + + + + + + + + + + + + + + +Freed & Vedam Standards Track [Page 18] + +RFC 5784 An XML Representation for Sieve March 2010 + + + A separate namespace can be used to embed text or structured + information: + + <sieve xmlns="urn:ietf:params:xml:ns:sieve" + xmlns:nls="http://example.com/nls"> + + <nls:interpretation> + If the email 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", "Cc", or "Bcc" contain + 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. + </nls:interpretation> + + ... the actual Sieve script ... + + </sieve> + + + + + + + + + + + + + + + + + + + + + + +Freed & Vedam Standards Track [Page 19] + +RFC 5784 An XML Representation for Sieve March 2010 + + + Alternately, displaydata elements can be used to accomplish the same + thing: + + <sieve xmlns="urn:ietf:params:xml:ns:sieve"> + + <displaydata> + <nls-interpretation> + If the email 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","Cc", or "Bcc" contain + 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. + </nls-interpretation> + </displaydata> + + ... the actual Sieve script ... + + </sieve> + + + + + + + + + + + + + + + + + + + + + +Freed & Vedam Standards Track [Page 20] + +RFC 5784 An XML Representation for Sieve March 2010 + + + Again, structured comments are used to represent this in regular + Sieve syntax: + + /* [| + <nls-interpretation> + If the email 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","Cc", or "Bcc" contain + 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. + </nls-interpretation> + |] */ + + ... the actual Sieve script ... + +Appendix B. XML Schema for Sieves in XML + + This appendix is informative. The following code component 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. + + <?xml version="1.0" encoding="UTF-8"?> + + <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" + xmlns="urn:ietf:params:xml:ns:sieve" + targetNamespace="urn:ietf:params:xml:ns:sieve"> + + <xsd:element name="sieve"> + <xsd:complexType> + <xsd:sequence> + <xsd:choice maxOccurs="unbounded" minOccurs="0"> + + + +Freed & Vedam Standards Track [Page 21] + +RFC 5784 An XML Representation for Sieve March 2010 + + + <xsd:element ref="control"/> + <xsd:element ref="action"/> + <xsd:element ref="displayblock"/> + <xsd:element ref="displaydata"/> + <xsd:element ref="comment"/> + <xsd:any namespace="##other" processContents="lax"/> + </xsd:choice> + </xsd:sequence> + </xsd:complexType> + </xsd:element> + + <xsd:element name="comment" type="xsd:string"/> + + <xsd:complexType name="ambles"> + <xsd:choice minOccurs="0" maxOccurs="unbounded"> + <xsd:element ref="displaydata"/> + <xsd:element ref="comment"/> + <xsd:any namespace="##other" processContents="lax"/> + </xsd:choice> + </xsd:complexType> + + <xsd:element name="preamble" type="ambles"/> + <xsd:element name="postamble" type="ambles"/> + + <xsd:complexType name="command"> + <xsd:sequence> + <xsd:element ref="preamble" minOccurs="0" maxOccurs="1"/> + <xsd:choice minOccurs="0" maxOccurs="unbounded"> + <xsd:element ref="str"/> + <xsd:element ref="num"/> + <xsd:element ref="list"/> + <xsd:element ref="tag"/> + </xsd:choice> + <xsd:element ref="test" minOccurs="0" maxOccurs="1"/> + <xsd:choice minOccurs="0" maxOccurs="unbounded"> + <xsd:element ref="control"/> + <xsd:element ref="action"/> + <xsd:element ref="displayblock"/> + </xsd:choice> + <xsd:element ref="postamble" minOccurs="0" maxOccurs="1"/> + </xsd:sequence> + <xsd:attribute use="required" name="name" type="identifier"/> + </xsd:complexType> + + <xsd:element name="control" type="command"/> + <xsd:element name="action" type="command"/> + + <xsd:element name="test"> + + + +Freed & Vedam Standards Track [Page 22] + +RFC 5784 An XML Representation for Sieve March 2010 + + + <xsd:complexType> + <xsd:sequence> + <xsd:choice minOccurs="0" maxOccurs="unbounded"> + <xsd:element ref="str"/> + <xsd:element ref="num"/> + <xsd:element ref="list"/> + <xsd:element ref="tag"/> + <xsd:element ref="displaydata"/> + <xsd:element ref="comment"/> + <xsd:any namespace="##other" processContents="lax"/> + </xsd:choice> + <xsd:element ref="test" minOccurs="0" + maxOccurs="unbounded"/> + </xsd:sequence> + <xsd:attribute use="required" name="name" type="identifier"/> + </xsd:complexType> + </xsd:element> + + <xsd:element name="list"> + <xsd:complexType> + <xsd:sequence> + <xsd:element ref="str" minOccurs="1" + maxOccurs="unbounded"/> + </xsd:sequence> + </xsd:complexType> + </xsd:element> + + <xsd:element name="tag" type="identifier"/> + + <xsd:element name="str" type="xsd:string"/> + + <xsd:element name="num" type="xsd:nonNegativeInteger"/> + + <xsd:simpleType name="identifier"> + <xsd:restriction base="xsd:token"> + <xsd:pattern value="[A-Za-z_][A-Za-z0-9_]*"/> + </xsd:restriction> + </xsd:simpleType> + + <xsd:element name="displayblock"> + <xsd:complexType> + <xsd:sequence> + <xsd:choice minOccurs="0" maxOccurs="unbounded"> + <xsd:element ref="control"/> + <xsd:element ref="action"/> + <xsd:element ref="displayblock"/> + <xsd:element ref="displaydata"/> + <xsd:element ref="comment"/> + + + +Freed & Vedam Standards Track [Page 23] + +RFC 5784 An XML Representation for Sieve March 2010 + + + <xsd:any namespace="##other" processContents="lax"/> + </xsd:choice> + </xsd:sequence> + <xsd:anyAttribute processContents="skip"/> + </xsd:complexType> + </xsd:element> + + <xsd:element name="displaydata"> + <xsd:complexType> + <xsd:sequence minOccurs="0" maxOccurs="unbounded"> + <xsd:any processContents="skip"/> + </xsd:sequence> + </xsd:complexType> + </xsd:element> + + </xsd:schema> + +Appendix C. Relax NG Schema for Sieves in XML + + This appendix is informative. The following code component 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 } + + ambles = + ( + ( displaydata | comment | ext )* + ), + empty + + preamble = element sieve:preamble { ambles } + postamble = element sieve:postamble { ambles } + + command = + ( + attribute name { + xsd:token { + + + +Freed & Vedam Standards Track [Page 24] + +RFC 5784 An XML Representation for Sieve March 2010 + + + pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, + preamble?, + ( str | num | \list | tag )*, + test?, + ( control | action | displayblock)*, + postamble? + ), + empty + + control = element sieve:control { command } + action = element sieve:action { command } + + test = + element sieve:test + { + 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* } + + + + + + +Freed & Vedam Standards Track [Page 25] + +RFC 5784 An XML Representation for Sieve March 2010 + + +Appendix D. Stylesheet for Conversion from XML + + This appendix is informative. The following code component is a + stylesheet that 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. + + <?xml version="1.0" encoding="UTF-8"?> + + <!-- Convert Sieve in XML to standard Sieve syntax --> + + <xsl:stylesheet version="1.0" + xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + xmlns:sieve="urn:ietf:params:xml:ns:sieve"> + + <xsl:output method="text" encoding="UTF-8" + media-type="application/sieve"/> + + <!-- Only preserve whitespace in str elements --> + <xsl:strip-space elements="*"/> + <xsl:preserve-space elements="sieve:str"/> + + <!-- Match top level sieve node, + start processing in sieve mode --> + + <xsl:template match="sieve:sieve"> + <xsl:apply-templates select="*" mode="sieve"> + <xsl:with-param name="prefix" select="''"/> + </xsl:apply-templates> + </xsl:template> + + <!-- Routine to properly literalize quotes in Sieve strings --> + + <xsl:template name="quote-string"> + <xsl:param name="str"/> + <xsl:choose> + <xsl:when test="not($str)"/> + <xsl:when test="contains($str, '"')"> + <xsl:call-template name="quote-string"> + <xsl:with-param name="str" + select="substring-before($str, '"')"/> + </xsl:call-template> + <xsl:text>\"</xsl:text> + <xsl:call-template name="quote-string"> + <xsl:with-param name="str" + select="substring-after($str, '"')"/> + </xsl:call-template> + + + +Freed & Vedam Standards Track [Page 26] + +RFC 5784 An XML Representation for Sieve March 2010 + + + </xsl:when> + <xsl:when test="contains($str, '\')"> + <xsl:call-template name="quote-string"> + <xsl:with-param name="str" + select="substring-before($str, '\')"/> + </xsl:call-template> + <xsl:text>\\</xsl:text> + <xsl:call-template name="quote-string"> + <xsl:with-param name="str" + select="substring-after($str, '\')"/> + </xsl:call-template> + </xsl:when> + <xsl:otherwise> + <xsl:value-of select="$str"/> + </xsl:otherwise> + </xsl:choose> + </xsl:template> + + <!-- Sieve mode processing templates --> + + <xsl:template match="sieve:control|sieve:action" mode="sieve"> + <xsl:param name="prefix"/> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:value-of select="@name"/> + <xsl:variable name="blockbegin" + select="generate-id(sieve:control|sieve:action)"/> + <xsl:for-each select="*"> + <xsl:choose> + <xsl:when test="self::sieve:str|self::sieve:num| + self::sieve:list|self::sieve:tag| + self::sieve:test"> + <xsl:apply-templates select="." mode="sieve"/> + </xsl:when> + <xsl:when test="generate-id(.) = $blockbegin"> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text>{</xsl:text> + <xsl:apply-templates select="." mode="sieve"> + <xsl:with-param name="prefix" + select="concat($prefix, ' ')"/> + </xsl:apply-templates> + </xsl:when> + <xsl:otherwise> + <xsl:apply-templates select="." mode="sieve"> + <xsl:with-param name="prefix" + + + +Freed & Vedam Standards Track [Page 27] + +RFC 5784 An XML Representation for Sieve March 2010 + + + select="concat($prefix, ' ')"/> + </xsl:apply-templates> + </xsl:otherwise> + </xsl:choose> + </xsl:for-each> + <xsl:choose> + <xsl:when test="count(sieve:control|sieve:action) > 0"> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text>}</xsl:text> + </xsl:when> + <xsl:otherwise> + <xsl:text>;</xsl:text> + </xsl:otherwise> + </xsl:choose> + </xsl:template> + + <xsl:template match="sieve:preamble|sieve:postamble" mode="sieve"> + <xsl:param name="prefix"/> + <xsl:apply-templates mode="sieve"> + <xsl:with-param name="prefix" select="$prefix"/> + </xsl:apply-templates> + </xsl:template> + + <xsl:template match="sieve:test" mode="sieve"> + <xsl:text xml:space="preserve"> </xsl:text> + <xsl:value-of select="@name"/> + <xsl:apply-templates select="*[not(self::sieve:test)]" + mode="sieve"/> + <xsl:if test="count(descendant::sieve:test) > 0"> + <xsl:text> (</xsl:text> + <xsl:for-each select="sieve:test"> + <xsl:apply-templates select="." mode="sieve"/> + <xsl:if test="count(following-sibling::sieve:test) > 0"> + <xsl:text>,</xsl:text> + </xsl:if> + </xsl:for-each> + <xsl:text> )</xsl:text> + </xsl:if> + </xsl:template> + + <xsl:template match="sieve:str" mode="sieve"> + <xsl:text> "</xsl:text> + <xsl:call-template name="quote-string"> + <xsl:with-param name="str" select="text()"/> + </xsl:call-template> + <xsl:text>"</xsl:text> + + + +Freed & Vedam Standards Track [Page 28] + +RFC 5784 An XML Representation for Sieve March 2010 + + + </xsl:template> + + <xsl:template match="sieve:num" mode="sieve"> + <xsl:text xml:space="preserve"> </xsl:text> + <!-- Use numeric suffixes when possible --> + <xsl:choose> + <xsl:when test="(number(text()) mod 1073741824) = 0"> + <xsl:value-of select="number(text()) div 1073741824"/> + <xsl:text>G</xsl:text> + </xsl:when> + <xsl:when test="(number(text()) mod 1048576) = 0"> + <xsl:value-of select="number(text()) div 1048576"/> + <xsl:text>M</xsl:text> + </xsl:when> + <xsl:when test="(number(text()) mod 1024) = 0"> + <xsl:value-of select="number(text()) div 1024"/> + <xsl:text>K</xsl:text> + </xsl:when> + <xsl:otherwise> + <xsl:value-of select="text()"/> + </xsl:otherwise> + </xsl:choose> + </xsl:template> + + <xsl:template match="sieve:list" mode="sieve"> + <xsl:text> [</xsl:text> + <xsl:for-each select="sieve:str"> + <xsl:apply-templates select="." mode="sieve"/> + <xsl:if test="count(following-sibling::sieve:str) > 0"> + <xsl:text>,</xsl:text> + </xsl:if> + </xsl:for-each> + <xsl:text> ]</xsl:text> + </xsl:template> + + <xsl:template match="sieve:tag" mode="sieve"> + <xsl:text> :</xsl:text> + <xsl:value-of select="text()"/> + </xsl:template> + + <xsl:template match="sieve:comment" mode="sieve"> + <xsl:param name="prefix"/> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text>/*</xsl:text> + <xsl:value-of select="."/> + <xsl:value-of select="$prefix"/> + + + +Freed & Vedam Standards Track [Page 29] + +RFC 5784 An XML Representation for Sieve March 2010 + + + <xsl:text>*/</xsl:text> + </xsl:template> + + <!-- Convert display information into structured comments --> + + <xsl:template match="sieve:displayblock" mode="sieve"> + <xsl:param name="prefix"/> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text>/* [*</xsl:text> + <xsl:apply-templates select="@*" mode="copy"/> + <xsl:text> */</xsl:text> + <xsl:apply-templates select="*" mode="sieve"> + <xsl:with-param name="prefix" select="$prefix"/> + </xsl:apply-templates> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text>/* *] */</xsl:text> + </xsl:template> + + <xsl:template match="sieve:displaydata" mode="sieve"> + <xsl:param name="prefix"/> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text>/* [|</xsl:text> + <xsl:apply-templates mode="copy"> + <xsl:with-param name="prefix" + select="concat($prefix, ' ')"/> + </xsl:apply-templates> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text> |] */</xsl:text> + </xsl:template> + + <!-- Copy unrecnognized nodes and their descendants --> + + <xsl:template match="*" mode="sieve"> + <xsl:param name="prefix"/> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text>/* [/</xsl:text> + <xsl:apply-templates select="." mode="copy"> + <xsl:with-param name="prefix" + + + +Freed & Vedam Standards Track [Page 30] + +RFC 5784 An XML Representation for Sieve March 2010 + + + select="concat($prefix, ' ')"/> + </xsl:apply-templates> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text> /] */</xsl:text> + </xsl:template> + + <!-- Copy mode processing templates --> + + <xsl:template match="*[not(node())]" mode="copy"> + <xsl:param name="prefix"/> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text><</xsl:text> + <xsl:value-of select="name()"/> + <xsl:apply-templates select="@*" mode="copy"/> + <xsl:text>/></xsl:text> + </xsl:template> + + <xsl:template match="*[node()]" mode="copy"> + <xsl:param name="prefix"/> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + <xsl:text><</xsl:text> + <xsl:value-of select="name()"/> + <xsl:apply-templates select="@*" mode="copy"/> + <xsl:text>></xsl:text> + <xsl:apply-templates mode="copy"> + <xsl:with-param name="prefix" + select="concat($prefix, ' ')"/> + </xsl:apply-templates> + <xsl:if test="*[last()][not(text())]"> + <xsl:text xml:space="preserve"> + </xsl:text> + <xsl:value-of select="$prefix"/> + </xsl:if> + <xsl:text></</xsl:text> + <xsl:value-of select="name()"/> + <xsl:text>></xsl:text> + </xsl:template> + + <xsl:template match="@*" mode="copy"> + <xsl:text> </xsl:text> + <xsl:value-of select="name()"/> + <xsl:text>="</xsl:text> + + + +Freed & Vedam Standards Track [Page 31] + +RFC 5784 An XML Representation for Sieve March 2010 + + + <xsl:value-of select="."/> + <xsl:text>"</xsl:text> + </xsl:template> + + </xsl:stylesheet> + +Appendix E. Acknowledgements + + The stylesheet copy mode code is loosely based on a sample code + posted to the xsl-list list by Americo Albuquerque. Jari Arkko, + Robert Burrell Donkin, 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 + + + Srinivas Saisatish Vedam + Sun Microsystems + + Phone: +91 80669 27577 + EMail: Srinivas.Sv@Sun.COM + + + + + + + + + + + + + + + + + + + + + +Freed & Vedam Standards Track [Page 32] + |