idnits 2.17.1 draft-freed-sieve-in-xml-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2009) is 5298 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'OASISRNC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Freed 3 Internet-Draft S. Vedam 4 Expires: April 24, 2010 Sun Microsystems 5 October 21, 2009 7 Sieve Email Filtering: Sieves and display directives in XML 8 draft-freed-sieve-in-xml-07 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 24, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes a way to represent Sieve email filtering 47 language scripts in XML. Representing sieves in XML is intended not 48 as an alternate storage format for Sieve but rather as a means to 49 facilitate manipulation of scripts using XML tools. 51 The XML representation also defines additional elements that have no 52 counterparts in the regular Sieve language. These elements are 53 intended for use by graphical user interfaces and provide facilities 54 for labeling or grouping sections of a script so they can be 55 displayed more conveniently. These elements are represented as 56 specially structured comments in regular Sieve format. 58 Change History (to be removed prior to publication as an RFC 60 Changed representation of comments in XML to use a comment element. 62 Update references. 64 Added an IANA registration of a URN for the Sieve namespace. 66 Updated XML Schema to allow largely unrestricted use of material in 67 other namespaces. 69 Add compact Relax NG schema. 71 Updated example stylesheet to handle material in other namespaces. 73 Corrected stylesheet handling of elements. 75 Added a section defining the structured comment convention. 77 Moved the examples section to an appendix. 79 Added text to clarify that the examples in the various appendices are 80 in fact code components and may therefore be reused. 82 Added a section on validation requirements. 84 Clarified various editor requirements and trust issues, restricted 85 the use of "*/" in non-Sieve XML content. 87 Added XML reference. 89 Added a list of all presently defined controls, explained how unknown 90 controls would be handled. 92 Added a note about the need to remove quotes and other syntax 93 elements when converting to XML. 95 Added a note about the fact that different front ends employing 96 different medadata may not interopate with each other. 98 Added preamble and postamble containers for displaydata, comment, and 99 external elements in command blocks. This addresses a unique 100 particle attribution constraint violation in XML schema. 102 Added information about the MIME loops extension defining two new 103 controls: foreverypart and break. 105 Table of Contents 107 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 108 2. Conventions used in this document . . . . . . . . . . . . . . 5 109 3. Grammatical structure of Sieve . . . . . . . . . . . . . . . . 5 110 4. XML Representation of Sieve . . . . . . . . . . . . . . . . . 7 111 4.1. XML Display Directives . . . . . . . . . . . . . . . . . . 10 112 4.2. Structured Comments . . . . . . . . . . . . . . . . . . . 11 113 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 12 114 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 115 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 116 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 117 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 118 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 119 Appendix A. Extended Example . . . . . . . . . . . . . . . . . . 14 120 Appendix B. XML Schema for Sieves in XML . . . . . . . . . . . . 22 121 Appendix C. Relax NG Schema for Sieves in XML . . . . . . . . . . 25 122 Appendix D. Stylesheet for conversion from XML . . . . . . . . . 27 123 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 33 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 126 1. Introduction 128 Sieve [RFC5228] is a language for filtering email messages at or 129 around the time of final delivery. It is designed to be 130 implementable on either a mail client or mail server. It is meant to 131 be extensible, simple, and independent of access protocol, mail 132 architecture, and operating system and it is intended to be 133 manipulated by a variety of different user interfaces. 135 Some user interface environments have extensive existing facilities 136 for manipulating material represented in XML [XML]. While adding 137 support for alternate data syntaxes may be possible in most if not 138 all of these environments, it may not be particularly convenient to 139 do so. The obvious way to deal with this issue is to map sieves into 140 XML, possibly on a separate backend system, manipulate the XML, and 141 convert it back to normal Sieve format. 143 The fact that conversion into and out of XML may be done as a 144 separate operation on a different system argues strongly for defining 145 a common XML representation for Sieve. This way different front end 146 user interfaces can be used with different back end mapping and 147 storage facilities. 149 Another issue with the creation and manipulation of sieve scripts by 150 user interfaces is that the language is strictly focused on 151 describing email filtering operations. The language contains no 152 mechanisms for indicating how a given script should be presented in a 153 user interface. Such information can be represented in XML very 154 easily so it makes sense to define a framework to do this as part of 155 the XML format. A structured comment convention is then used to 156 retain this information when the script is converted to normal Sieve 157 format. 159 It should be noted, however, that the ability for different front 160 ends to use the same mapping and storage facilities does not mean 161 that the additional XML information produced by different front ends 162 will interoperate. 164 Various sieve extensions have already been defined, e.g., [RFC5183] 165 [RFC5229] [RFC5230] [RFC5231] [RFC5232] [RFC5233] [RFC5235] 166 [RFC5293], and more are planned. The set of extensions available 167 varies from one implementation to the next and may even change as a 168 result of configuration choices. It is therefore essential that the 169 XML representation of Sieve be able to accommodate Sieve extensions 170 without requiring schema changes. It is also desirable that Sieve 171 extensions not require changes to the code that converts to and from 172 the XML representation. 174 This specification defines an XML representation for sieve scripts 175 and explains how the conversion process to and from XML works. The 176 XML representation is capable of accommodating any future Sieve 177 extension as long as the underlying Sieve grammar remains unchanged. 178 Furthermore, code that converts from XML to the normal Sieve format 179 requires no changes to accommodate extensions, while code used to 180 convert from normal Sieve format to XML only requires changes when 181 new control commands are added - a rare event. An XML Schema, Relax 182 NG Schema, and a sample stylesheet to convert from XML format are 183 also provided in the appendices. 185 2. Conventions used in this document 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC 2119 [RFC2119]. 191 The term "processor" is used throughout this document to refer to 192 agents that convert Sieve to and from the XML representation. The 193 term "editor" refers to agents that operate on, possibly creating or 194 modifying, Sieves in XML format. 196 3. Grammatical structure of Sieve 198 The Sieve language is designed to be highly extensible without making 199 any changes to the basic language syntax. Accordingly the syntax of 200 Sieve, defined in section 8 of [RFC5228], is entirely structural in 201 nature and employs no reserved words of any sort. 203 Structurally a sieve script consists of a series of commands. Each 204 command in turn consists of an identifier, zero or more arguments, a 205 optional test or test-list, and finally an optional block containing 206 another series of commands. Commands are further broken down into 207 controls and actions, although this distinction cannot be determined 208 from the grammar. 210 Some example Sieve controls are: 212 stop; <-- No arguments, test, or command block 213 require "fileinto"; <-- Control with a single argument 214 if true {stop;} <-- Control with test and command block 216 Some examples of Sieve actions are: 218 discard; <-- Action with no args, test, or command block 219 fileinto "folder"; <-- Action with an argument 220 At the time of this writing there are no controls defined that accept 221 both arguments and a test. Similarly, there are currently no defined 222 actions that allow either a test or a command block. Nevertheless, 223 the Sieve grammar allows such constructs to be defined by some future 224 extension. 226 A test consists of an identifier followed by zero or more arguments, 227 then another test or test-list. Unlike commands, tests cannot be 228 followed by a command block. 230 Here are some examples of Sieve tests. Note that such tests have to 231 appear as part of a command in order to be syntactically valid: 233 true <-- Test with no argument or subordinate test 234 envelope "to" "me@example.com" <-- Test with several arguments 235 header :is "from" "you@example.com" <-- Test with tagged argument 237 Command or test arguments can be either string lists, whole numbers 238 or tags. (Tags are simply identifiers preceded by a colon.) Note 239 that although the Sieve grammar treats single strings as a degenerate 240 case of a string list, some tests or actions have arguments that can 241 only be individual strings, not lists. 243 Here is an example showing the use of both a test-list and a string 244 list: 246 if anyof (not exists ["From", "Date"], 247 header :contains "from" "fool@example.edu") { 248 discard; 249 } 251 Extensions can add new controls, actions, tests, or new arguments to 252 existing controls or actions. Extensions have also changed how 253 string content is interpreted, although this is not relevant to this 254 specification. However, it is especially important to note that so 255 far only one of the many defined Sieve extensions - the foreverypart 256 extension [I-D.ietf-sieve-mime-loop] - has added new controls to the 257 language. It seems safe to assume that due to their nature future 258 addition of controls will be relatively rare. 260 Finally, comments are allowed between lexical elements in a Sieve 261 script. One important use case for comments is encoding meta-data 262 about the script, a facility which is lacking in the Sieve language. 263 Therefore comments need to be preserved in the XML representation. 265 4. XML Representation of Sieve 267 Sieve controls and actions are represented in XML as "control" or 268 "action" elements respectively. The command's identifier appears as 269 a name attribute on the element itself. This is the only attribute 270 allowed on controls and actions - arguments, tests, test-lists, and 271 nested command blocks are all represented as nested elements. While 272 naming the element after the control or action itself may seem like a 273 better choice, doing so would result in extensions requiring frequent 274 corresponding schema changes. 276 The example Sieve controls shown in the previous section would be 277 represented in XML as: 279 280 fileinto 281 282 283 285 The example Sieve actions shown above would appear in XML as: 287 288 folder 290 The separation of controls from actions in the XML representation 291 means that conversion from normal Sieve format to XML has to be able 292 to distinguish between controls and actions. This is easily done by 293 maintaining a list of all known controls since experience indicates 294 new controls are rarely added. At the time of this writing the list 295 of defined controls consists of: 297 1. if [RFC5228], 299 2. stop [RFC5228], 301 3. require [RFC5228], 303 4. foreverypart [I-D.ietf-sieve-mime-loop], and 305 5. break [I-D.ietf-sieve-mime-loop]. 307 It should be noted that with this approach unknown controls will 308 simply be treated as actions and can be passed back and forth between 309 the two representations. The treatment of a control as an action is 310 unlikely to cause other issues since knowledge of a control's 311 language semantics is almost always required to take of advantage of 312 it. 314 Tests are represented in the same basic way as controls and actions, 315 that is, as a "test" element with a name attribute giving the test 316 identifier. For example: 318 319 320 tome@example.com 321 322 323 isfromyou@example.com 324 326 String, number, and tag arguments are represented as "str", "num", 327 and "tag" elements respectively. The actual string, number, or tag 328 identifier appears as text inside the element. None of these 329 elements have any defined attributes. Several examples of arguments 330 have already appeared in the preceding control, action and test 331 examples. Any whitespace in the str body content MUST be preserved 332 by the processor. Also note that since strings and tags are 333 represented as element text any quotes or other syntactic elements 334 required in the regular Sieve representation are dropped rather than 335 being carried over into the XML. 337 String list arguments are represented as a "list" element which in 338 turn contains one or more str elements. Note that this allows the 339 distinction between a single string and a string list containing a 340 single string to be preserved. This is not essential since a list 341 containing a single string could simply be mapped to a string, but it 342 seems prudent to maintain the distinction when mapping to and from 343 XML. 345 Nested command blocks appear as a series of control or action 346 elements inside of an outer control or action element. No block 347 element is needed since an inner command block can only appear once 348 and only after any arguments, tests, or test-lists. For example: 350 351 352 353 358 contains 359 from 360 fool@example.edu 361 362 363 364 366 Sieve comments are mapped to a special "comment" element in XML. 367 Both hash and bracketed comments are mapped to the same construct so 368 the distinction between the two is lost in XML. XML comments are not 369 used because some XML tools do not make it convenient to access 370 comment nodes. 372 Comments are allowed between commands and inside "test" elements. 373 But comments aren't allowed directly inside commands - due to 374 limitations of XML schema special enclosing "preamble" and 375 "postamble" elements are needed: 377 378 379 Check to see if message should be discarded 380 381 382 383 388 contains 389 from 390 fool@example.edu 391 392 393 394 395 End of discard check 396 397 399 4.1. XML Display Directives 401 Sometimes graphical user interfaces are a convenient way to provide 402 sieve management functions to users. These interfaces typically 403 summarize/annotate/group/display sieve script(s) in an intuitive way 404 for end users. 406 To do this effectively, the graphical user interface may require 407 additional information about the sieve script itself. That 408 information or "meta-data" might include, but is not limited to - a 409 sieve name (identifying the current sieve), whether the sieve is 410 enabled or disabled, the order in which the part of the sieve are 411 presented to the user. The graphical user interface may also choose 412 to provide mechanisms to allow the user to modify the script. 414 It is often useful for a graphical user interface to group related 415 sieve script elements and provide an interface that display these 416 groups separately so they can be managed as a single object. Some 417 examples include Sieve statements that together provide vacation 418 responders, blacklists/whitelists and other types of filtering 419 controls. 421 Some advanced graphical user interfaces may even provide a natural 422 language representation of a sieve script and/or an advanced 423 interface to present sieve statements directly to the user. 425 A graphical user interface may also choose to support only a subset 426 of action commands in the Sieve language (and its extensions) and so 427 a mechanism to indicate the extent of support and characterize the 428 relationships between those supported action commands and test (with 429 its arguments) is immensely useful and probably required for clients 430 that may not have complete knowledge of sieve grammar and semantics. 432 The Sieve language contains no mechanisms for indicating how a given 433 script should be presented in a user interface. The language also 434 does not contain any specific mechanisms to represent other sorts of 435 meta-data about the script. Providing support for such meta-data as 436 part of a sieve script is currently totally implementation specific 437 and is usually done by imposing some type of structure on comments. 439 However, such information can be represented in XML very easily so it 440 makes sense to define a framework to do this as part of the XML 441 format. Implementations MAY choose to use structured comments to 442 retain this information when the script is converted to normal Sieve 443 format. 445 The sample schemata for the XML representation of Sieve allows XML in 446 foreign namespaces to be inserted in the same places "comment" 447 elements can appear in Sieve scripts. This is the preferred means of 448 including additional information. Alternately, the schema defines 449 two display directives - displayblock and displaydata - as containers 450 for meta-data needed by graphical user interfaces. 452 Editors MAY use displayblock, displaydata and foreign namespaces to 453 associate meta-data. Some editors find it inconvenient to preserve 454 this additional data during an editing session. Editors MAY preserve 455 this data during an editing session for compatibility with other 456 editors. 458 The displayblock element can be used to enclose any number of sieve 459 statements at any level. It is semantically meaningless to the sieve 460 script itself. It allows an arbitrary set of attributes. 461 Implementations MAY use this to provide many simple, display related 462 meta-data for the sieve such as sieve identifier, group identifier, 463 order of processing, etc. 465 The displaydata element supports any number of arbitrary child 466 elements. Implementations MAY use this to represent complex data 467 about that sieve such as a natural language representation of sieve 468 or a way to provide the sieve script directly. 470 4.2. Structured Comments 472 Since the XML representation is not intended as a storage format 473 there needs to be a way to preserve the additional information that 474 can be included in the XML representation in the normal Sieve syntax. 475 This is done through the use of three structured comment conventions: 477 1. XML content in other namespaces is placed in Sieve bracketed 478 comments beginning with the string "/* [/" and ending with the 479 string "/] */". 481 2. The content of displaydata elements is placed in Sieve bracketed 482 comments beginning with the string "/* [|" and ending with the 483 string "|] */". 485 3. The beginning of a displayblock element is mapped to a bracketed 486 Sieve comment beginning with the string "/* [*" which then lists 487 any displayblock attribute names and values in XML format. The 488 end of a displayblock element is mapped to a comment of the form 489 "/* *] */". 491 Processors MUST preserve the additional information allowed in the 492 XML format and SHOULD use the structured comment format shown above. 494 Note: If "*/" is found in the XML content, when mapped into a comment 495 it would prematurely terminate that comment. Escaping of this 496 sequence would often be inconvenient for processors. Editors SHALL 497 NOT include "*/" within displayblock, displaydata or foreign markup. 498 Processors MAY regard documents containing "*/" in foreign markup, 499 displayblock or displaydata as invalid. 501 4.3. Validation 503 A processor MAY validate documents against a schema and MAY reject 504 any which do not conform. For any document that a processor does not 505 reject as invalid, any markup that the processor cannot understand by 506 reference to this specification MAY be discarded. 508 Note that example Relax NG and XML Schema are given in the appendices 509 below. 511 5. Security Considerations 513 Any syntactically valid sieve script can be represented in XML. 514 Accordingly, all security considerations applicable to Sieve and any 515 extensions used also apply to the XML representation. 517 The use of XML carries its own security risks. Section 7 of RFC 3470 518 [RFC3470] discusses these risks. 520 It is axiomatic that a Sieve editor must be trusted to do what the 521 user specifies. If XML formats are used this trust necessarily must 522 extend to the components involved in converting to and from XML 523 format. 525 Arbitrary data can be included using other namespaces or placed in 526 the extensible displayblock and displaydata constructs defined in 527 this specification, possibly including entire scripts and other 528 executable content in languages other than Sieve. Such material will 529 necessarily have its own security considerations, which are beyond 530 the scope of this document. 532 6. IANA Considerations 534 This section registers a new XML namespace per the procedures in RFC 535 3688 [RFC3688]. 537 URI: urn:ietf:params:xml:ns:sieve 539 Registrant Contact: IETF Sieve working group 540 542 XML: 544 BEGIN 545 546 548 549 550 552 Sieve Namespace 553 554 555

Namespace for Sieve Language objects expressed in XML

556

urn:ietf:params:xml:ns:sieve

557

See 558 RFC XXXX. 559

560 561 562 END 564 7. References 566 7.1. Normative References 568 [OASISRNC] 569 Clark, J., "RELAX NG Compact Syntax", OASIS Committee 570 Specification rnc, November 2002. 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 576 the Use of Extensible Markup Language (XML) 577 within IETF Protocols", BCP 70, RFC 3470, January 2003. 579 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 580 January 2004. 582 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 583 Language", RFC 5228, January 2008. 585 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 586 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 587 Edition)", W3C REC-xml-20081126, November 2008, 588 . 590 7.2. Informative References 592 [I-D.ietf-sieve-mime-loop] 593 Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME 594 part Tests, Iteration, Extraction, Replacement and 595 Enclosure", draft-ietf-sieve-mime-loop (work in progress), 596 July 2009, 597 . 599 [RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", 600 RFC 5183, May 2008. 602 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 603 RFC 5229, January 2008. 605 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 606 Vacation Extension", RFC 5230, January 2008. 608 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 609 Relational Extension", RFC 5231, January 2008. 611 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 612 Extension", RFC 5232, January 2008. 614 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 615 Extension", RFC 5233, January 2008. 617 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 618 Extensions", RFC 5235, January 2008. 620 [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering: 621 Editheader Extension", RFC 5293, August 2008. 623 Appendix A. Extended Example 625 The example sieve script given in section 9 of [RFC5228] would be 626 represented in XML as the following code component: 628 629 630 Example Sieve Filter 631 Declare any optional features or extensions used by the script 633 635 636 fileinto 637 639 640 Handle messages from known mailing lists 641 Move messages from IETF filter discussion list to filter mailbox 642 643 644 645 is 646 Sender 647 owner-ietf-mta-filters@imc.org 648 649 650 filter 651 652 653 move to "filter" mailbox 654 655 657 658 Keep all messages to or from people in my company 659 660 661 662 domain 663 is 664 665 From 666 To 667 668 example.com 669 670 671 673 674 Try and catch unsolicited email. If a message is not to me, 675 or it contains a subject known to be spam, file it away. 676 677 678 679 680 681 all 682 contains 683 684 To 685 Cc 686 Bcc 687 688 me@example.com 689 690 691 692 matches 693 subject 694 695 *make*money*fast* 696 *university*dipl*mas* 697 698 699 700 701 spam 702 703 704 705 706 707 Move all other (non-company) mail to "personal" 708 mailbox. 709 710 711 712 personal 713 714 716 718 The same script could be annotated with graphical display hints in a 719 variety of ways. Three possible code components that do this are: 721 723 724 fileinto 725 727 730 731 732 is 733 Sender 734 owner-ietf-mta-filters@imc.org 735 736 737 filter 738 739 740 742 744 745 746 domain 747 is 748 749 From 750 To 751 752 example.com 753 754 755 756 758 760 761 762 763 764 all 765 contains 766 767 To 768 Cc 769 Bcc 770 771 me@example.com 772 773 774 775 matches 776 subject 777 778 *make*money*fast* 779 *university*dipl*mas* 780 781 782 783 784 spam 785 786 787 789 791 792 793 personal 794 795 796 798 800 Note that since displayblock elements are semantically null as far as 801 the script itself is concerned they can be used to group structures 802 like elsif and else that are tied to statements in other groups. 804 The representation of this script in regular Sieve syntax uses 805 structured comments: 807 require "fileinto"; 808 /* [* name="File filter list mail" order="1" 809 group="FILE_TO_FOLDER" enable="true" */ 810 if header :is "Sender" "owner-ietf-mta-filters@imc.org" 811 { 812 fileinto "filter"; 813 } 814 /* *] */ 815 /* [* name="Keep all company mail" order="2" 816 group="KEEP_MESSAGE" enable="true" */ 817 elsif address :domain :is [ "From", "To" ] "example.com" 818 { 819 keep; 820 } 821 /* *] */ 822 /* [* name="File suspected spam" order="3" 823 group="FILE_TO_FOLDER" enable="true" */ 824 elsif anyof ( not ( address :all :contains [ "To", "Cc", "Bcc" ] 825 "me@example.com" ), 826 header :matches "subject" [ "*make*money*fast*", 827 "*university*dipl*mas*" ] ) 828 { 829 fileinto "spam"; 830 } 831 /* *] */ 832 /* [* name="File noncompany mail as personal" order="4" 833 group="FILE_TO_FOLDER" enable="true" */ 834 else 835 { 836 fileinto "personal"; 837 } 838 /* *] */ 840 A separate namespace can be used to embed text or structured 841 information: 843 846 847 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 848 then file it into the "filter" folder. 850 Otherwise if the address in the "From" or "To" has a domain 851 that is "example.com" then keep it. 853 Otherwise messages meeting with any of these conditions: 855 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 856 the domain "example.com". 858 (2) The "Subject" field matches the pattern *make*money*fast* 859 or *university*dipl*mas* then file it into the "spam" 860 folder. 862 If all else fails then file the message in the "personal" 863 folder. 864 866 ... the actual sieve script ... 868 870 Alternately, displaydata elements can be used to accomplish the same 871 thing: 873 875 876 877 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 878 then file it into the "filter" folder. 880 Otherwise if the address in the "From" or "To" has a domain 881 that is "example.com" then keep it. 883 Otherwise messages meeting with any of these conditions: 885 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 886 the domain "example.com". 888 (2) The "Subject" field matches the pattern *make*money*fast* 889 or *university*dipl*mas* then file it into the "spam" 890 folder. 892 If all else fails then file the message in the "personal" 893 folder. 894 895 897 ... the actual sieve script ... 899 901 Again, structured comments are used to represent this in regular 902 Sieve syntax: 904 /* [| 905 906 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 907 then file it into the "filter" folder. 909 Otherwise if the address in the "From" or "To" has a domain 910 that is "example.com" then keep it. 912 Otherwise messages meeting with any of these conditions: 914 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 915 the domain "example.com". 917 (2) The "Subject" field matches the pattern *make*money*fast* 918 or *university*dipl*mas* then file it into the "spam" 919 folder. 921 If all else fails then file the message in the "personal" 922 folder. 923 924 |] */ 926 ... the actual sieve script ... 928 Appendix B. XML Schema for Sieves in XML 930 This appendix is informative. The following code component is an XML 931 Schema for the XML representation of Sieve scripts. Most of the 932 elements employing a complex content model allow use of elements in 933 other namespaces, subject to lax XML Schema validation rules. 934 Additionally, displaydata elements can be used to encapsulate 935 arbitrary XML content. Finally, displayblock elements can be used as 936 a general-purpose grouping mechanism - arbitrary attributes are 937 allowed on displayblock elements. 939 941 945 946 947 948 949 950 951 952 953 954 955 956 957 958 960 962 963 964 965 966 967 968 970 971 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 993 994 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1010 1011 1012 1013 1015 1016 1017 1018 1020 1021 1022 1024 1026 1028 1030 1031 1032 1033 1034 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1048 1049 1050 1051 1053 1054 1055 1056 1057 1058 1059 1061 1063 Appendix C. Relax NG Schema for Sieves in XML 1065 This appendix is informative. The following code component defines a 1066 Relax NG schema using compact notation OASISRNC [OASISRNC] for the 1067 XML representation of Sieve scripts. Most of the elements employing 1068 a complex content model allow unrestricted use of elements in other 1069 namespaces. Additionally, displaydata elements can be used to 1070 encapsulate arbitrary XML content. Finally, displayblock elements 1071 can be used as a general-purpose grouping mechanism - arbitrary 1072 attributes are allowed on displayblock elements. 1074 namespace sieve = "urn:ietf:params:xml:ns:sieve" 1076 start = element sieve:sieve { ( control | action | displayblock | 1077 displaydata | comment | ext )* } 1079 comment = element sieve:comment { xsd:string } 1081 ambles = 1082 ( 1083 ( displaydata | comment | ext )* 1084 ), 1085 empty 1087 preamble = element sieve:preamble { ambles } 1088 postamble = element sieve:postamble { ambles } 1090 command = 1091 ( 1092 attribute name { 1093 xsd:token { 1094 pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, 1096 preamble?, 1097 ( str | num | \list | tag )*, 1098 test?, 1099 ( control | action | displayblock)*, 1100 postamble? 1101 ), 1102 empty 1104 control = element sieve:control { command } 1105 action = element sieve:action { command } 1107 test = 1108 element sieve:test 1109 { 1110 attribute name { 1111 xsd:token { 1112 pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, 1113 ( str | num | \list | tag | comment | ext )*, 1114 test* 1115 } 1117 \list = element sieve:list { str+ } 1119 tag = element sieve:tag { 1120 xsd:token { 1121 pattern = "[A-Za-z_][A-Za-z0-9_]*" } } 1123 str = element sieve:str { xsd:string } 1125 num = element sieve:num { xsd:nonNegativeInteger } 1127 any = ( element * { any } | attribute * { text } | text )* 1129 ext = element * - sieve:* { any }* 1131 displayblock = 1132 element sieve:displayblock 1133 { 1134 ( control | action | displayblock | 1135 displaydata | comment | ext )*, 1136 attribute * { text }* 1137 } 1139 displaydata = element sieve:displaydata { any* } 1141 Appendix D. Stylesheet for conversion from XML 1143 This appendix is informative. The following code component is a 1144 stylesheet that can be used to convert the Sieve in XML 1145 representation to regular Sieve format. Content in other namespaces, 1146 displaydata, and displayblock elements are converted to structured 1147 comments as appropriate. 1149 1151 1153 1157 1160 1161 1162 1164 1167 1168 1169 1170 1171 1173 1175 1176 1177 1178 1179 1180 1181 1183 1184 \" 1185 1186 1188 1190 1191 1192 1193 1195 1196 \\ 1197 1198 1200 1201 1202 1203 1204 1205 1206 1208 1210 1211 1212 1213 1214 1215 1216 1218 1219 1220 1223 1224 1225 1226 1227 1228 1229 { 1230 1231 1233 1234 1235 1236 1237 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 } 1249 1250 1251 ; 1252 1253 1254 1256 1257 1258 1259 1260 1261 1263 1264 1265 1266 1268 1269 ( 1270 1271 1272 1273 , 1274 1275 1276 ) 1277 1278 1280 1281 " 1282 1283 1284 1285 " 1287 1289 1290 1291 1292 1293 1294 1295 G 1296 1297 1298 1299 M 1300 1301 1302 1303 K 1304 1305 1306 1307 1308 1309 1311 1312 [ 1313 1314 1315 1316 , 1317 1318 1319 ] 1320 1322 1323 : 1324 1325 1327 1328 1329 1330 1331 1332 /* 1333 1334 1335 */ 1336 1338 1340 1341 1342 1343 1344 1345 /* [* 1346 1347 */ 1348 1349 1350 1351 1352 1353 1354 /* *] */ 1355 1357 1358 1359 1360 1361 1362 /* [| 1363 1364 1366 1367 1368 1369 1370 |] */ 1371 1373 1375 1376 1377 1378 1379 1380 /* [/ 1381 1382 1384 1385 1386 1387 1388 /] */ 1389 1391 1393 1394 1395 1396 1397 1398 < 1399 1400 1401 /> 1402 1404 1405 1406 1407 1408 1409 < 1410 1411 1412 > 1413 1414 1416 1417 1418 1419 1420 1421 1422 </ 1423 1424 > 1425 1427 1428 1429 1430 =" 1431 1432 " 1433 1435 1437 Appendix E. Acknowledgements 1439 The stylesheet copy mode code is loosely based on a sample code 1440 posted to the xsl-list list by Americo Albuquerque. Jari Arkko, 1441 Robert Burrell Donkin, Andrew McKeon, Alexey Melnikov, and Aaron 1442 Stone provided useful comments on the document. 1444 Authors' Addresses 1446 Ned Freed 1447 Sun Microsystems 1448 800 Royal Oaks 1449 Monrovia, CA 91016-6347 1450 USA 1452 Phone: +1 909 457 4293 1453 Email: ned.freed@mrochek.com 1455 Srinivas Saisatish Vedam 1456 Sun Microsystems 1458 Phone: +91 80669 27577 1459 Email: Srinivas.Sv@Sun.COM