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

Namespace for Sieve Language objects expressed in XML

483

urn:ietf:params:xml:ns:sieve

484

See 485 RFC XXXX. 486

487 488 489 END 491 7. References 493 7.1. Normative References 495 [OASISRNC] 496 Clark, J., "RELAX NG Compact Syntax", OASIS Committee 497 Specification rnc, November 2002. 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 503 the Use of Extensible Markup Language (XML) 504 within IETF Protocols", BCP 70, RFC 3470, January 2003. 506 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 507 January 2004. 509 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 510 Language", RFC 5228, January 2008. 512 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 513 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 514 Edition)", W3C REC-xml-20081126, November 2008, 515 . 517 7.2. Informative References 519 [RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", 520 RFC 5183, May 2008. 522 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 523 RFC 5229, January 2008. 525 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 526 Vacation Extension", RFC 5230, January 2008. 528 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 529 Relational Extension", RFC 5231, January 2008. 531 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 532 Extension", RFC 5232, January 2008. 534 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 535 Extension", RFC 5233, January 2008. 537 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 538 Extensions", RFC 5235, January 2008. 540 [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering: 541 Editheader Extension", RFC 5293, August 2008. 543 Appendix A. Extended Example 545 The example sieve script given in section 9 of [RFC5228] would be 546 represented in XML as the following code component: 548 549 550 Example Sieve Filter 551 Declare any optional features or extensions used by the script 552 554 555 fileinto 556 558 559 Handle messages from known mailing lists 560 Move messages from IETF filter discussion list to filter mailbox 561 562 563 564 is 565 Sender 566 owner-ietf-mta-filters@imc.org 567 568 569 filter 570 move to "filter" mailbox 571 573 574 Keep all messages to or from people in my company 575 576 577 578 domain 579 is 580 581 From 582 To 583 584 example.com 585 586 588 590 591 Try and catch unsolicited email. If a message is not to me, 592 or it contains a subject known to be spam, file it away. 593 594 595 596 597 598 all 599 contains 600 601 To 602 Cc 603 Bcc 604 605 me@example.com 606 607 608 609 matches 610 subject 611 612 *make*money*fast* 613 *university*dipl*mas* 614 615 616 617 618 spam 619 620 621 622 623 Move all other (non-company) mail to "personal" 624 mailbox. 625 626 627 personal 628 629 631 633 The same script could be annotated with graphical display hints in a 634 variety of ways. Three possible code components that do this are: 636 638 639 fileinto 640 642 644 645 646 is 647 Sender 648 owner-ietf-mta-filters@imc.org 649 650 651 filter 652 653 654 656 658 659 660 domain 661 is 662 663 From 664 To 665 666 example.com 667 668 669 670 672 674 675 676 677 678 all 679 contains 680 681 To 682 Cc 683 Bcc 685 686 me@example.com 687 688 689 690 matches 691 subject 692 693 *make*money*fast* 694 *university*dipl*mas* 695 696 697 698 699 spam 700 701 702 704 706 707 708 personal 709 710 711 713 715 Note that since displayblock elements are semantically null as far as 716 the script itself is concerned they can be used to group structures 717 like elsif and else that are tied to statements in other groups. 719 The representation of this script in regular Sieve syntax uses 720 structured comments: 722 require "fileinto"; 723 /* [* name="File filter list mail" order="1" 724 group="FILE_TO_FOLDER" enable="true" */ 725 if header :is "Sender" "owner-ietf-mta-filters@imc.org" 726 { 727 fileinto "filter"; 728 } 729 /* *] */ 730 /* [* name="Keep all company mail" order="2" 731 group="KEEP_MESSAGE" enable="true" */ 732 elsif address :domain :is [ "From", "To" ] "example.com" 733 { 734 keep; 735 } 736 /* *] */ 737 /* [* name="File suspected spam" order="3" 738 group="FILE_TO_FOLDER" enable="true" */ 739 elsif anyof ( not ( address :all :contains [ "To", "Cc", "Bcc" ] 740 "me@example.com" ), 741 header :matches "subject" [ "*make*money*fast*", 742 "*university*dipl*mas*" ] ) 743 { 744 fileinto "spam"; 745 } 746 /* *] */ 747 /* [* name="File noncompany mail as personal" order="4" 748 group="FILE_TO_FOLDER" enable="true" */ 749 else 750 { 751 fileinto "personal"; 752 } 753 /* *] */ 755 A separate namespace can be used to embed text or structured 756 information: 758 761 762 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 763 then file it into the "filter" folder. 765 Otherwise if the address in the "From" or "To" has a domain 766 that is "example.com" then keep it. 768 Otherwise messages meeting with any of these conditions: 770 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 771 the domain "example.com". 773 (2) The "Subject" field matches the pattern *make*money*fast* 774 or *university*dipl*mas* then file it into the "spam" 775 folder. 777 If all else fails then file the message in the "personal" 778 folder. 779 781 ... the actual sieve script ... 783 785 Alternately, displaydata elements can be used to accomplish the same 786 thing: 788 790 791 792 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 793 then file it into the "filter" folder. 795 Otherwise if the address in the "From" or "To" has a domain 796 that is "example.com" then keep it. 798 Otherwise messages meeting with any of these conditions: 800 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 801 the domain "example.com". 803 (2) The "Subject" field matches the pattern *make*money*fast* 804 or *university*dipl*mas* then file it into the "spam" 805 folder. 807 If all else fails then file the message in the "personal" 808 folder. 809 810 812 ... the actual sieve script ... 814 816 Again, structured comments are used to represent this in regular 817 Sieve syntax: 819 /* [| 820 821 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 822 then file it into the "filter" folder. 824 Otherwise if the address in the "From" or "To" has a domain 825 that is "example.com" then keep it. 827 Otherwise messages meeting with any of these conditions: 829 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 830 the domain "example.com". 832 (2) The "Subject" field matches the pattern *make*money*fast* 833 or *university*dipl*mas* then file it into the "spam" 834 folder. 836 If all else fails then file the message in the "personal" 837 folder. 838 839 |] */ 841 ... the actual sieve script ... 843 Appendix B. XML Schema for Sieves in XML 845 This appendix is informative. The following code component is an XML 846 Schema for the XML representation of Sieve scripts. Most of the 847 elements employing a complex content model allow use of elements in 848 other namespaces, subject to lax XML Schema validation rules. 849 Additionally, displaydata elements can be used to encapsulate 850 arbitrary XML content. Finally, displayblock elements can be used as 851 a general-purpose grouping mechanism - arbitrary attributes are 852 allowed on displayblock elements. 854 856 860 861 862 863 864 865 866 867 868 869 870 871 872 873 875 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 901 903 905 906 907 908 909 910 911 912 913 914 915 916 917 919 920 921 922 924 925 926 927 929 930 931 933 935 937 939 940 941 942 943 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 961 962 963 964 965 966 967 969 971 Appendix C. Relax NG Schema for Sieves in XML 973 This appendix is informative. The following code component defines a 974 Relax NG schema using compact notation OASISRNC [OASISRNC] for the 975 XML representation of Sieve scripts. Most of the elements employing 976 a complex content model allow unrestricted use of elements in other 977 namespaces. Additionally, displaydata elements can be used to 978 encapsulate arbitrary XML content. Finally, displayblock elements 979 can be used as a general-purpose grouping mechanism - arbitrary 980 attributes are allowed on displayblock elements. 982 namespace sieve = "urn:ietf:params:xml:ns:sieve" 984 start = element sieve:sieve { ( control | action | displayblock | 985 displaydata | comment | ext )* } 987 comment = element sieve:comment { xsd:string } 989 command = 990 ( 991 attribute name { 992 xsd:token { 993 pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, 994 ( str | num | \list | tag | 995 displaydata | comment | ext )*, 996 test?, 997 ( control | action | displayblock | 998 displaydata | comment | ext )* 999 ), 1000 empty 1002 control = element sieve:control { command } 1004 action = element sieve:action { command } 1006 test = 1007 element sieve:test 1008 { 1009 attribute name { 1010 xsd:token { 1011 pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, 1012 ( str | num | \list | tag | comment | ext )*, 1013 test* 1014 } 1016 \list = element sieve:list { str+ } 1018 tag = element sieve:tag { 1019 xsd:token { 1020 pattern = "[A-Za-z_][A-Za-z0-9_]*" } } 1022 str = element sieve:str { xsd:string } 1024 num = element sieve:num { xsd:nonNegativeInteger } 1026 any = ( element * { any } | attribute * { text } | text )* 1028 ext = element * - sieve:* { any }* 1030 displayblock = 1031 element sieve:displayblock 1032 { 1033 ( control | action | displayblock | 1034 displaydata | comment | ext )*, 1035 attribute * { text }* 1036 } 1038 displaydata = element sieve:displaydata { any* } 1040 Appendix D. Stylesheet for conversion from XML 1042 This appendix is informative. The following code component is a 1043 stylesheet that can be used to convert the Sieve in XML 1044 representation to regular Sieve format. Content in other namespaces, 1045 displaydata, and displayblock elements are converted to structured 1046 comments as appropriate. 1048 1050 1052 1056 1059 1060 1061 1063 1066 1067 1068 1069 1070 1072 1074 1075 1076 1077 1078 1079 1080 1082 1083 \" 1084 1085 1087 1088 1089 1090 1091 1093 1094 \\ 1095 1096 1098 1099 1100 1101 1102 1103 1105 1107 1109 1110 1111 1112 1113 1114 1115 1117 1118 1119 1122 1123 1124 1125 1126 1127 1128 { 1129 1130 1132 1133 1134 1135 1136 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 } 1148 1149 1150 ; 1151 1152 1154 1156 1157 1158 1159 1161 1162 ( 1163 1164 1165 1166 , 1167 1168 1169 ) 1170 1171 1173 1174 " 1175 1176 1177 1178 " 1179 1181 1182 1183 1184 1185 1186 1187 G 1188 1189 1190 1191 M 1192 1193 1194 1195 K 1196 1197 1198 1199 1200 1201 1202 1203 [ 1204 1205 1206 1207 , 1208 1209 1210 ] 1211 1213 1214 : 1215 1216 1218 1219 1220 1221 1222 1223 /* 1224 1225 1226 */ 1227 1229 1230 1231 1232 1233 1234 1235 /* [* 1236 1237 */ 1238 1239 1240 1241 1242 1243 1244 /* *] */ 1245 1247 1248 1249 1251 1252 1253 /* [| 1254 1255 1257 1258 1259 1260 1261 |] */ 1262 1264 1266 1267 1268 1269 1270 1271 /* [/ 1272 1273 1275 1276 1277 1278 1279 /] */ 1280 1282 1284 1285 1286 1287 1288 1289 < 1290 1291 1292 /> 1293 1295 1296 1297 1298 1299 1300 < 1301 1302 1303 > 1304 1305 1307 1308 1309 1310 1311 1312 1313 </ 1314 1315 > 1316 1318 1319 1320 1321 =" 1322 1323 " 1324 1326 1328 Appendix E. Acknowledgements 1330 The stylesheet copy mode code is loosely based on a sample code 1331 posted to the xsl-list list by Americo Albuquerque. Robert Burrell 1332 Donkin, Andrew McKeon, Alexey Melnikov, and Aaron Stone provided 1333 useful comments on the document. 1335 Authors' Addresses 1337 Ned Freed 1338 Sun Microsystems 1339 800 Royal Oaks 1340 Monrovia, CA 91016-6347 1341 USA 1343 Phone: +1 909 457 4293 1344 Email: ned.freed@mrochek.com 1346 Srinivas Saisatish Vedam 1347 Sun Microsystems 1349 Phone: +91 80669 27577 1350 Email: Srinivas.Sv@Sun.COM