idnits 2.17.1 draft-freed-sieve-in-xml-06.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 (August 13, 2009) is 5369 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: February 14, 2010 Sun Microsystems 5 August 13, 2009 7 Sieve Email Filtering: Sieves and display directives in XML 8 draft-freed-sieve-in-xml-06 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 February 14, 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 Table of Contents 97 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 98 2. Conventions used in this document . . . . . . . . . . . . . . 5 99 3. Grammatical structure of Sieve . . . . . . . . . . . . . . . . 5 100 4. XML Representation of Sieve . . . . . . . . . . . . . . . . . 6 101 4.1. XML Display Directives . . . . . . . . . . . . . . . . . . 9 102 4.2. Structured Comments . . . . . . . . . . . . . . . . . . . 10 103 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 11 104 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 106 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 107 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 108 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 109 Appendix A. Extended Example . . . . . . . . . . . . . . . . . . 13 110 Appendix B. XML Schema for Sieves in XML . . . . . . . . . . . . 21 111 Appendix C. Relax NG Schema for Sieves in XML . . . . . . . . . . 24 112 Appendix D. Stylesheet for conversion from XML . . . . . . . . . 25 113 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 31 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 116 1. Introduction 118 Sieve [RFC5228] is a language for filtering email messages at or 119 around the time of final delivery. It is designed to be 120 implementable on either a mail client or mail server. It is meant to 121 be extensible, simple, and independent of access protocol, mail 122 architecture, and operating system and it is intended to be 123 manipulated by a variety of different user interfaces. 125 Some user interface environments have extensive existing facilities 126 for manipulating material represented in XML [XML]. While adding 127 support for alternate data syntaxes may be possible in most if not 128 all of these environments, it may not be particularly convenient to 129 do so. The obvious way to deal with this issue is to map sieves into 130 XML, possibly on a separate backend system, manipulate the XML, and 131 convert it back to normal Sieve format. 133 The fact that conversion into and out of XML may be done as a 134 separate operation on a different system argues strongly for defining 135 a common XML representation for Sieve. This way different front end 136 user interfaces can be used with different back end mapping and 137 storage facilities. 139 Another issue with the creation and manipulation of sieve scripts by 140 user interfaces is that the language is strictly focused on 141 describing email filtering operations. The language contains no 142 mechanisms for indicating how a given script should be presented in a 143 user interface. Such information can be represented in XML very 144 easily so it makes sense to define a framework to do this as part of 145 the XML format. A structured comment convention is then used to 146 retain this information when the script is converted to normal Sieve 147 format. 149 Various sieve extensions have already been defined, e.g., [RFC5183] 150 [RFC5229] [RFC5230] [RFC5231] [RFC5232] [RFC5233] [RFC5235] 151 [RFC5293], and more are planned. The set of extensions available 152 varies from one implementation to the next and may even change as a 153 result of configuration choices. It is therefore essential that the 154 XML representation of Sieve be able to accommodate Sieve extensions 155 without requiring schema changes. It is also desirable that Sieve 156 extensions not require changes to the code that converts to and from 157 the XML representation. 159 This specification defines an XML representation for sieve scripts 160 and explains how the conversion process to and from XML works. The 161 XML representation is capable of accommodating any future Sieve 162 extension as long as the underlying Sieve grammar remains unchanged. 163 Furthermore, code that converts from XML to the normal Sieve format 164 requires no changes to accommodate extensions, while code used to 165 convert from normal Sieve format to XML only requires changes when 166 new control commands are added - a rare event. An XML Schema, Relax 167 NG Schema, and a sample stylesheet to convert from XML format are 168 also provided in the appendices. 170 2. Conventions used in this document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 The term "processor" is used throughout this document to refer to 177 agents that convert Sieve to and from the XML representation. The 178 term "editor" refers to agents that operate on, possibly creating or 179 modifying, Sieves in XML format. 181 3. Grammatical structure of Sieve 183 The Sieve language is designed to be highly extensible without making 184 any changes to the basic language syntax. Accordingly the syntax of 185 Sieve, defined in section 8 of [RFC5228], is entirely structural in 186 nature and employs no reserved words of any sort. 188 Structurally a sieve script consists of a series of commands. Each 189 command in turn consists of an identifier, zero or more arguments, a 190 optional test or test-list, and finally an optional block containing 191 another series of commands. Commands are further broken down into 192 controls and actions, although this distinction cannot be determined 193 from the grammar. 195 Some example Sieve controls are: 197 stop; <-- No arguments, test, or command block 198 require "fileinto"; <-- Control with a single argument 199 if true {stop;} <-- Control with test and command block 201 Some examples of Sieve actions are: 203 discard; <-- Action with no args, test, or command block 204 fileinto "folder"; <-- Action with an argument 206 At the time of this writing there are no controls defined that accept 207 both arguments and a test. Similarly, there are currently no defined 208 actions that allow either a test or a command block. Nevertheless, 209 the Sieve grammar allows such constructs to be defined by some future 210 extension. 212 A test consists of an identifier followed by zero or more arguments, 213 then another test or test-list. Unlike commands, tests cannot be 214 followed by a command block. 216 Here are some examples of Sieve tests. Note that such tests have to 217 appear as part of a command in order to be syntactically valid: 219 true <-- Test with no argument or subordinate test 220 envelope "to" "me@example.com" <-- Test with several arguments 221 header :is "from" "you@example.com" <-- Test with tagged argument 223 Command or test arguments can be either string lists, whole numbers 224 or tags. (Tags are simply identifiers preceded by a colon.) Note 225 that although the Sieve grammar treats single strings as a degenerate 226 case of a string list, some tests or actions have arguments that can 227 only be individual strings, not lists. 229 Here is an example showing the use of both a test-list and a string 230 list: 232 if anyof (not exists ["From", "Date"], 233 header :contains "from" "fool@example.edu") { 234 discard; 235 } 237 Extensions can add new controls, actions, tests, or new arguments to 238 existing controls or actions. Extensions have also changed how 239 string content is interpreted, although this is not relevant to this 240 specification. However, it is especially important to note that so 241 far no Sieve extension has added a new control to the language and it 242 seems safe to assume that due to their nature future addition of 243 controls will be rare. 245 Finally, comments are allowed between lexical elements in a Sieve 246 script. Finally, comments are allowed between lexical elements in a 247 Sieve script. One important use case for comments is encoding meta- 248 data about the script, a facility which is lacking in the Sieve 249 language. Therefore comments need to be preserved in the XML 250 representation. 252 4. XML Representation of Sieve 254 Sieve controls and actions are represented in XML as "control" or 255 "action" elements respectively. The command's identifier appears as 256 a name attribute on the element itself. This is the only attribute 257 allowed on controls and actions - arguments, tests, test-lists, and 258 nested command blocks are all represented as nested elements. While 259 naming the element after the control or action itself may seem like a 260 better choice, doing so would result in extensions requiring 261 corresponding schema changes. 263 The example Sieve controls shown in the previous section would be 264 represented in XML as: 266 267 fileinto 268 269 270 272 The example Sieve actions shown above would appear in XML as: 274 275 folder 277 The separation of controls from actions in the XML representation 278 means that conversion from normal Sieve format to XML has to be able 279 to distinguish between controls and actions. This is easily done by 280 maintaining a list of all known controls since experience indicates 281 new controls are rarely added. At the time of this writing the list 282 of defined and proposed controls consists of: 284 1. if [RFC5228], 286 2. stop [RFC5228], 288 3. require [RFC5228], 290 4. foreverypart [I-D.ietf-sieve-mime-loop], and 292 5. break [I-D.ietf-sieve-mime-loop]. 294 It should be noted that with this approach unknown controls will 295 simply be treated as actions and can be passed back and forthe 296 between the two representations. The treatment of a control as an 297 aciton is unlikely to cause other issues since knowledge of a 298 control's language semantics is almost always required to take of 299 advantage of it. 301 Tests are represented in the same basic way as controls and actions, 302 that is, as a "test" element with a name attribute giving the test 303 identifier. For example: 305 306 307 tome@example.com 308 309 310 isfromyou@example.com 311 313 String, number, and tag arguments are represented as "str", "num", 314 and "tag" elements respectively. The actual string, number, or tag 315 identifier appears as text inside the element. None of these 316 elements have any defined attributes. Several examples of arguments 317 have already appeared in the preceding control, action and test 318 examples. Any whitespace in the str body content MUST be preserved 319 by the processor. Also note that since strings and tags are 320 represented as element text any quotes or other syntactic elements 321 required in the regular Sieve representation are dropped rather than 322 being carried over into the XML. 324 String list arguments are represented as a "list" element which in 325 turn contains one or more str elements. Note that this allows the 326 distinction between a single string and a string list containing a 327 single string to be preserved. This is not essential since a list 328 containing a single string could simply be mapped to a string, but it 329 seems prudent to maintain the distinction when mapping to and from 330 XML. 332 Nested command blocks appear as a series of control or action 333 elements inside of an outer control or action element. No block 334 element is needed since an inner command block can only appear once 335 and only after any arguments, tests, or test-lists. For example: 337 338 339 340 345 contains 346 from 347 fool@example.edu 348 349 350 351 352 Finally, Sieve comments are mapped to a special "comment" element in 353 XML. Both hash and bracketed comments are mapped to the same 354 construct so the distinction between the two is lost in XML. XML 355 comments are not used because some XML tools do not make it 356 convenient to access comment nodes. 358 4.1. XML Display Directives 360 Sometimes graphical user interfaces are a convenient way to provide 361 sieve management functions to users. These interfaces typically 362 summarize/annotate/group/display sieve script(s) in an intuitive way 363 for end users. 365 To do this effectively, the graphical user interface may require 366 additional information about the sieve script itself. That 367 information or "meta-data" might include, but is not limited to - a 368 sieve name (identifying the current sieve), whether the sieve is 369 enabled or disabled, the order in which the part of the sieve are 370 presented to the user. The graphical user interface may also choose 371 to provide mechanisms to allow the user to modify the script. 373 It is often useful for a graphical user interface to group related 374 sieve script elements and provide an interface that display these 375 groups separately so they can be managed as a single object. Some 376 examples include Sieve statements that together provide vacation 377 responders, blacklists/whitelists and other types of filtering 378 controls. 380 Some advanced graphical user interfaces may even provide a natural 381 language representation of a sieve script and/or an advanced 382 interface to present sieve statements directly to the user. 384 A graphical user interface may also choose to support only a subset 385 of action commands in the Sieve language (and its extensions) and so 386 a mechanism to indicate the extent of support and characterize the 387 relationships between those supported action commands and test (with 388 its arguments) is immensely useful and probably required for clients 389 that may not have complete knowledge of sieve grammar and semantics. 391 The Sieve language contains no mechanisms for indicating how a given 392 script should be presented in a user interface. The language also 393 does not contain any specific mechanisms to represent other sorts of 394 meta-data about the script. Providing support for such meta-data as 395 part of a sieve script is currently totally implementation specific 396 and is usually done by imposing some type of structure on comments. 398 However, such information can be represented in XML very easily so it 399 makes sense to define a framework to do this as part of the XML 400 format. Implementations MAY choose to use structured comments to 401 retain this information when the script is converted to normal Sieve 402 format. 404 The sample schemata for the XML representation of Sieve allows XML in 405 foreign namespaces to be inserted in most places in Sieve scripts. 406 This is the preferred means of including additional information. 407 Alternately, the schema defines two display directives - displayblock 408 and displaydata - as containers for meta-data needed by graphical 409 user interfaces. 411 Editors MAY use displayblock, displaydata and foreign namespaces to 412 associate meta-data. Some editors find it inconvenient to preserve 413 this additional data during an editing session. Editors MAY preserve 414 this data during an editing session for compatibility with other 415 editors. 417 The displayblock element can be used to enclose any number of sieve 418 statements at any level. It is semantically meaningless to the sieve 419 script itself. It allows an arbitrary set of attributes. 420 Implementations MAY use this to provide many simple, display related 421 meta-data for the sieve such as sieve identifier, group identifier, 422 order of processing, etc. 424 The displaydata element supports any number of arbitrary child 425 elements. Implementations MAY use this to represent complex data 426 about that sieve such as a natural language representation of sieve 427 or a way to provide the sieve script directly. 429 4.2. Structured Comments 431 Since the XML representation is not intended as a storage format 432 there needs to be a way to preserve the additional information that 433 can be included in the XML representation in the normal Sieve syntax. 434 This is done through the use of three structured comment conventions: 436 1. XML content in other namespaces is placed in Sieve bracketed 437 comments beginning with the string "/* [/" and ending with the 438 string "/] */". 440 2. The content of displaydata elements is placed in Sieve bracketed 441 comments beginning with the string "/* [|" and ending with the 442 string "|] */". 444 3. The beginning of a displayblock element is mapped to a bracketed 445 Sieve comment beginning with the string "/* [*" which then lists 446 any displayblock attribute names and values in XML format. The 447 end of a displayblock element is mapped to a comment of the form 448 "/* *] */". 450 Processors MUST preserve the additional information allowed in the 451 XML format and SHOULD use the structured comment format shown above. 453 Note: If "*/" is found in the XML content, when mapped into a comment 454 it would prematurely terminate that comment. Escaping of this 455 sequence would often be inconvenient for processors. Editors SHALL 456 NOT include "*/" within displayblock, displaydata or foreign markup. 457 Processors MAY regard documents containing "*/" in foreign markup, 458 displayblock or displaydata as invalid. 460 4.3. Validation 462 A processor MAY validate documents against a schema and MAY reject 463 any which do not conform. For any document that a processor does not 464 reject as invalid, any markup that the processor cannot understand by 465 reference to this specification MAY be discarded. 467 Note that example Relax NG and XML Schema are given in the appendices 468 below. 470 5. Security Considerations 472 Any syntactically valid sieve script can be represented in XML. 473 Accordingly, all security considerations applicable to Sieve and any 474 extensions used also apply to the XML representation. 476 The use of XML carries its own security risks. Section 7 of RFC 3470 477 [RFC3470] discusses these risks. 479 It is axiomatic that a Sieve editor must be trusted to do what the 480 user specifies. If XML formats are used this trust necessarily must 481 extent to the components involved in converting to and from XML 482 format. 484 Arbitrary data can be included using other namespaces or placed in 485 the extensible displayblock and displaydata constructs defined in 486 this specification, possibly including entire scripts and other 487 executable content in languages other than Sieve. Appropriate 488 security precautions should be taken when using these facilities. 490 6. IANA Considerations 492 This section registers a new XML namespace per the procedures in RFC 493 3688 [RFC3688]. 495 URI: urn:ietf:params:xml:ns:sieve 497 Registrant Contact: IETF Sieve working group 498 500 XML: 502 BEGIN 503 504 506 507 508 510 Sieve Namespace 511 512 513

Namespace for Sieve Language objects expressed in XML

514

urn:ietf:params:xml:ns:sieve

515

See 516 RFC XXXX. 517

518 519 520 END 522 7. References 524 7.1. Normative References 526 [OASISRNC] 527 Clark, J., "RELAX NG Compact Syntax", OASIS Committee 528 Specification rnc, November 2002. 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 534 the Use of Extensible Markup Language (XML) 535 within IETF Protocols", BCP 70, RFC 3470, January 2003. 537 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 538 January 2004. 540 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 541 Language", RFC 5228, January 2008. 543 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 544 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 545 Edition)", W3C REC-xml-20081126, November 2008, 546 . 548 7.2. Informative References 550 [I-D.ietf-sieve-mime-loop] 551 Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME 552 part Tests, Iteration, Extraction, Replacement and 553 Enclosure", draft-ietf-sieve-mime-loop (work in progress), 554 July 2009, 555 . 557 [RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", 558 RFC 5183, May 2008. 560 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 561 RFC 5229, January 2008. 563 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 564 Vacation Extension", RFC 5230, January 2008. 566 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 567 Relational Extension", RFC 5231, January 2008. 569 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 570 Extension", RFC 5232, January 2008. 572 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 573 Extension", RFC 5233, January 2008. 575 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 576 Extensions", RFC 5235, January 2008. 578 [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering: 579 Editheader Extension", RFC 5293, August 2008. 581 Appendix A. Extended Example 583 The example sieve script given in section 9 of [RFC5228] would be 584 represented in XML as the following code component: 586 587 588 Example Sieve Filter 589 Declare any optional features or extensions used by the script 591 593 594 fileinto 595 597 598 Handle messages from known mailing lists 599 Move messages from IETF filter discussion list to filter mailbox 600 601 602 603 is 604 Sender 605 owner-ietf-mta-filters@imc.org 606 607 608 filter 609 move to "filter" mailbox 610 612 613 Keep all messages to or from people in my company 614 615 616 617 domain 618 is 619 620 From 621 To 622 623 example.com 624 625 626 628 629 Try and catch unsolicited email. If a message is not to me, 630 or it contains a subject known to be spam, file it away. 631 632 633 634 635 636 all 637 contains 638 639 To 640 Cc 641 Bcc 642 643 me@example.com 644 645 646 647 matches 648 subject 649 650 *make*money*fast* 651 *university*dipl*mas* 652 653 654 655 656 spam 657 658 659 660 661 Move all other (non-company) mail to "personal" 662 mailbox. 663 664 665 personal 666 667 669 671 The same script could be annotated with graphical display hints in a 672 variety of ways. Three possible code components that do this are: 674 676 677 fileinto 678 680 682 683 684 is 685 Sender 686 owner-ietf-mta-filters@imc.org 688 689 690 filter 691 692 693 695 697 698 699 domain 700 is 701 702 From 703 To 704 705 example.com 706 707 708 709 711 713 714 715 716 717 all 718 contains 719 720 To 721 Cc 722 Bcc 723 724 me@example.com 725 726 727 728 matches 729 subject 730 731 *make*money*fast* 732 *university*dipl*mas* 733 734 735 736 737 spam 738 739 740 742 744 745 746 personal 747 748 749 751 753 Note that since displayblock elements are semantically null as far as 754 the script itself is concerned they can be used to group structures 755 like elsif and else that are tied to statements in other groups. 757 The representation of this script in regular Sieve syntax uses 758 structured comments: 760 require "fileinto"; 761 /* [* name="File filter list mail" order="1" 762 group="FILE_TO_FOLDER" enable="true" */ 763 if header :is "Sender" "owner-ietf-mta-filters@imc.org" 764 { 765 fileinto "filter"; 766 } 767 /* *] */ 768 /* [* name="Keep all company mail" order="2" 769 group="KEEP_MESSAGE" enable="true" */ 770 elsif address :domain :is [ "From", "To" ] "example.com" 771 { 772 keep; 773 } 774 /* *] */ 775 /* [* name="File suspected spam" order="3" 776 group="FILE_TO_FOLDER" enable="true" */ 777 elsif anyof ( not ( address :all :contains [ "To", "Cc", "Bcc" ] 778 "me@example.com" ), 779 header :matches "subject" [ "*make*money*fast*", 780 "*university*dipl*mas*" ] ) 781 { 782 fileinto "spam"; 783 } 784 /* *] */ 785 /* [* name="File noncompany mail as personal" order="4" 786 group="FILE_TO_FOLDER" enable="true" */ 787 else 788 { 789 fileinto "personal"; 790 } 791 /* *] */ 793 A separate namespace can be used to embed text or structured 794 information: 796 799 800 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 801 then file it into the "filter" folder. 803 Otherwise if the address in the "From" or "To" has a domain 804 that is "example.com" then keep it. 806 Otherwise messages meeting with any of these conditions: 808 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 809 the domain "example.com". 811 (2) The "Subject" field matches the pattern *make*money*fast* 812 or *university*dipl*mas* then file it into the "spam" 813 folder. 815 If all else fails then file the message in the "personal" 816 folder. 817 819 ... the actual sieve script ... 821 823 Alternately, displaydata elements can be used to accomplish the same 824 thing: 826 828 829 830 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 831 then file it into the "filter" folder. 833 Otherwise if the address in the "From" or "To" has a domain 834 that is "example.com" then keep it. 836 Otherwise messages meeting with any of these conditions: 838 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 839 the domain "example.com". 841 (2) The "Subject" field matches the pattern *make*money*fast* 842 or *university*dipl*mas* then file it into the "spam" 843 folder. 845 If all else fails then file the message in the "personal" 846 folder. 847 848 850 ... the actual sieve script ... 852 854 Again, structured comments are used to represent this in regular 855 Sieve syntax: 857 /* [| 858 859 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 860 then file it into the "filter" folder. 862 Otherwise if the address in the "From" or "To" has a domain 863 that is "example.com" then keep it. 865 Otherwise messages meeting with any of these conditions: 867 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 868 the domain "example.com". 870 (2) The "Subject" field matches the pattern *make*money*fast* 871 or *university*dipl*mas* then file it into the "spam" 872 folder. 874 If all else fails then file the message in the "personal" 875 folder. 876 877 |] */ 879 ... the actual sieve script ... 881 Appendix B. XML Schema for Sieves in XML 883 This appendix is informative. The following code component is an XML 884 Schema for the XML representation of Sieve scripts. Most of the 885 elements employing a complex content model allow use of elements in 886 other namespaces, subject to lax XML Schema validation rules. 887 Additionally, displaydata elements can be used to encapsulate 888 arbitrary XML content. Finally, displayblock elements can be used as 889 a general-purpose grouping mechanism - arbitrary attributes are 890 allowed on displayblock elements. 892 894 898 899 900 901 902 903 904 905 906 907 908 909 910 911 913 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 939 941 943 944 945 946 947 948 949 950 951 952 953 954 955 957 958 959 960 962 963 964 965 967 968 969 971 973 975 977 978 979 980 981 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 999 1000 1001 1002 1003 1004 1005 1007 1009 Appendix C. Relax NG Schema for Sieves in XML 1011 This appendix is informative. The following code component defines a 1012 Relax NG schema using compact notation OASISRNC [OASISRNC] for the 1013 XML representation of Sieve scripts. Most of the elements employing 1014 a complex content model allow unrestricted use of elements in other 1015 namespaces. Additionally, displaydata elements can be used to 1016 encapsulate arbitrary XML content. Finally, displayblock elements 1017 can be used as a general-purpose grouping mechanism - arbitrary 1018 attributes are allowed on displayblock elements. 1020 namespace sieve = "urn:ietf:params:xml:ns:sieve" 1022 start = element sieve:sieve { ( control | action | displayblock | 1023 displaydata | comment | ext )* } 1025 comment = element sieve:comment { xsd:string } 1027 command = 1028 ( 1029 attribute name { 1030 xsd:token { 1031 pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, 1032 ( str | num | \list | tag | 1033 displaydata | comment | ext )*, 1034 test?, 1035 ( control | action | displayblock | 1036 displaydata | comment | ext )* 1037 ), 1038 empty 1040 control = element sieve:control { command } 1042 action = element sieve:action { command } 1044 test = 1045 element sieve:test 1046 { 1047 attribute name { 1048 xsd:token { 1049 pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, 1050 ( str | num | \list | tag | comment | ext )*, 1051 test* 1052 } 1054 \list = element sieve:list { str+ } 1056 tag = element sieve:tag { 1057 xsd:token { 1058 pattern = "[A-Za-z_][A-Za-z0-9_]*" } } 1060 str = element sieve:str { xsd:string } 1062 num = element sieve:num { xsd:nonNegativeInteger } 1064 any = ( element * { any } | attribute * { text } | text )* 1066 ext = element * - sieve:* { any }* 1068 displayblock = 1069 element sieve:displayblock 1070 { 1071 ( control | action | displayblock | 1072 displaydata | comment | ext )*, 1073 attribute * { text }* 1074 } 1076 displaydata = element sieve:displaydata { any* } 1078 Appendix D. Stylesheet for conversion from XML 1080 This appendix is informative. The following code component is a 1081 stylesheet that can be used to convert the Sieve in XML 1082 representation to regular Sieve format. Content in other namespaces, 1083 displaydata, and displayblock elements are converted to structured 1084 comments as appropriate. 1086 1088 1090 1094 1097 1098 1099 1101 1104 1105 1106 1107 1108 1110 1112 1113 1114 1115 1116 1117 1118 1120 1121 \" 1122 1123 1125 1126 1127 1128 1129 1131 1132 \\ 1133 1134 1136 1137 1138 1139 1140 1141 1143 1145 1147 1148 1149 1150 1151 1152 1153 1155 1156 1157 1160 1161 1162 1163 1164 1165 1166 { 1167 1168 1170 1171 1172 1173 1174 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 } 1186 1187 1188 ; 1189 1190 1192 1194 1195 1196 1197 1199 1200 ( 1201 1202 1203 1204 , 1205 1206 1207 ) 1208 1209 1211 1212 " 1213 1214 1215 1216 " 1217 1219 1220 1221 1222 1223 1224 1225 G 1226 1227 1228 1229 M 1230 1231 1232 1233 K 1234 1235 1236 1237 1238 1239 1240 1241 [ 1242 1243 1244 1245 , 1246 1247 1248 ] 1249 1251 1252 : 1253 1254 1256 1257 1258 1259 1260 1261 /* 1262 1263 1264 */ 1265 1267 1268 1269 1270 1271 1272 1273 /* [* 1274 1275 */ 1276 1277 1278 1279 1280 1281 1282 /* *] */ 1283 1285 1286 1287 1289 1290 1291 /* [| 1292 1293 1295 1296 1297 1298 1299 |] */ 1300 1302 1304 1305 1306 1307 1308 1309 /* [/ 1310 1311 1313 1314 1315 1316 1317 /] */ 1318 1320 1322 1323 1324 1325 1326 1327 < 1328 1329 1330 /> 1331 1333 1334 1335 1336 1337 1338 < 1339 1340 1341 > 1342 1343 1345 1346 1347 1348 1349 1350 1351 </ 1352 1353 > 1354 1356 1357 1358 1359 =" 1360 1361 " 1362 1364 1366 Appendix E. Acknowledgements 1368 The stylesheet copy mode code is loosely based on a sample code 1369 posted to the xsl-list list by Americo Albuquerque. Robert Burrell 1370 Donkin, Andrew McKeon, Alexey Melnikov, and Aaron Stone provided 1371 useful comments on the document. 1373 Authors' Addresses 1375 Ned Freed 1376 Sun Microsystems 1377 800 Royal Oaks 1378 Monrovia, CA 91016-6347 1379 USA 1381 Phone: +1 909 457 4293 1382 Email: ned.freed@mrochek.com 1384 Srinivas Saisatish Vedam 1385 Sun Microsystems 1387 Phone: +91 80669 27577 1388 Email: Srinivas.Sv@Sun.COM