[Pkg-mozext-commits] [sieve-extension] 13/34: Imported Upstream version 0.2.3f+dfsg
Michael Fladischer
fladi at moszumanska.debian.org
Mon Sep 21 09:03:29 UTC 2015
This is an automated email from the git hooks/post-receive script.
fladi pushed a commit to branch master
in repository sieve-extension.
commit fa1622966e728f39a52caa53460f21bb4a47be60
Author: Michael Fladischer <FladischerMichael at fladi.at>
Date: Wed Jul 8 18:30:09 2015 +0200
Imported Upstream version 0.2.3f+dfsg
---
.../content/libs/libSieveDOM/RFC5173/rfc5173.txt | 563 -----
.../content/libs/libSieveDOM/RFC5228/rfc5228.txt | 2355 --------------------
.../content/libs/libSieveDOM/RFC5229/rfc5229.txt | 619 -----
.../content/libs/libSieveDOM/RFC5230/rfc5230.txt | 899 --------
.../content/libs/libSieveDOM/RFC5232/rfc5232.txt | 675 ------
.../content/libs/libSieveDOM/RFC5293/rfc5293.txt | 507 -----
.../content/libs/libSieveDOM/RFC5429/rfc5429.txt | 787 -------
7 files changed, 6405 deletions(-)
diff --git a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5173/rfc5173.txt b/chrome/chromeFiles/content/libs/libSieveDOM/RFC5173/rfc5173.txt
deleted file mode 100644
index 915724c..0000000
--- a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5173/rfc5173.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Degener
-Request for Comments: 5173 P. Guenther
-Updates: 5229 Sendmail, Inc.
-Category: Standards Track April 2008
-
-
-
- Sieve Email Filtering: Body Extension
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document defines a new command for the "Sieve" email filtering
- language that tests for the occurrence of one or more strings in the
- body of an email message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 1]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
-1. Introduction
-
- The "body" test checks for the occurrence of one or more strings in
- the body of an email message. Such a test was initially discussed
- for the [SIEVE] base document, but was subsequently removed because
- it was thought to be too costly to implement.
-
- Nevertheless, several server vendors have implemented some form of
- the "body" test.
-
- This document reintroduces the "body" test as an extension, and
- specifies its syntax and semantics.
-
-2. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [KEYWORDS].
-
- Conventions for notations are as in [SIEVE] Section 1.1, including
- the use of the "Usage:" label for the definition of text and tagged
- argument syntax.
-
- The rules for interpreting the grammar are defined in [SIEVE] and
- inherited by this specification. In particular, readers of this
- document are reminded that according to [SIEVE] Sections 2.6.2 and
- 2.6.3, optional arguments such as COMPARATOR and MATCH-TYPE can
- appear in any order.
-
-3. Capability Identifier
-
- The capability string associated with the extension defined in this
- document is "body".
-
-4. Test body
-
- Usage: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM]
- <key-list: string-list>
-
- The body test matches content in the body of an email message, that
- is, anything following the first empty line after the header. (The
- empty line itself, if present, is not considered to be part of the
- body.)
-
- The COMPARATOR and MATCH-TYPE keyword parameters are defined in
- [SIEVE]. As specified in Sections 2.7.1 and 2.7.3 of [SIEVE], the
- default COMPARATOR is "i;ascii-casemap" and the default MATCH-TYPE is
- ":is".
-
-
-
-Degener & Guenther Standards Track [Page 2]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
- The BODY-TRANSFORM is a keyword parameter that governs how a set of
- strings to be matched against are extracted from the body of the
- message. If a message consists of a header only, not followed by an
- empty line, then that set is empty and all "body" tests return false,
- including those that test for an empty string. (This is similar to
- how the "header" test always fails when the named header fields
- aren't present.) Otherwise, the transform must be followed as
- defined below in Section 5.
-
- Note that the transformations defined here do *not* match against
- each line of the message independently, so the strings will usually
- contain CRLFs. How these can be matched is governed by the
- comparator and match-type. For example, with the default comparator
- of "i;ascii-casemap", they can be included literally in the key
- strings, or be matched with the "*" or "?" wildcards of the :matches
- match-type, or be skipped with :contains.
-
-5. Body Transform
-
- Prior to matching content in a message body, "transformations" can be
- applied that filter and decode certain parts of the body. These
- transformations are selected by a "BODY-TRANSFORM" keyword parameter.
-
- Usage: ":raw"
- / ":content" <content-types: string-list>
- / ":text"
-
- The default transformation is :text.
-
-5.1. Body Transform ":raw"
-
- The ":raw" transform matches against the entire undecoded body of a
- message as a single item.
-
- If the specified body-transform is ":raw", the [MIME] structure of
- the body is irrelevant. The implementation MUST NOT remove any
- transfer encoding from the message, MUST NOT refuse to filter
- messages with syntactic errors (unless the environment it is part of
- rejects them outright), and MUST treat multipart boundaries or the
- MIME headers of enclosed body parts as part of the content being
- matched against, instead of MIME structures to interpret.
-
-
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 3]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
- Example:
-
- require "body";
-
- # This will match a message containing the literal text
- # "MAKE MONEY FAST" in body parts (ignoring any
- # content-transfer-encodings) or MIME headers other than
- # the outermost RFC 2822 header.
-
- if body :raw :contains "MAKE MONEY FAST" {
- discard;
- }
-
-5.2. Body Transform ":content"
-
- If the body transform is ":content", the MIME parts that have the
- specified content types are matched against independently.
-
- If an individual content type begins or ends with a '/' (slash) or
- contains multiple slashes, then it matches no content types.
- Otherwise, if it contains a slash, then it specifies a full
- <type>/<subtype> pair, and matches only that specific content type.
- If it is the empty string, all MIME content types are matched.
- Otherwise, it specifies a <type> only, and any subtype of that type
- matches it.
-
- The search for MIME parts matching the :content specification is
- recursive and automatically descends into multipart and
- message/rfc822 MIME parts. All MIME parts with matching types are
- searched for the key strings. The test returns true if any
- combination of a searched MIME part and key-list argument match.
-
- If the :content specification matches a multipart MIME part, only the
- prologue and epilogue sections of the part will be searched for the
- key strings, treating the entire prologue and the entire epilogue as
- separate strings; the contents of nested parts are only searched if
- their respective types match the :content specification.
-
- If the :content specification matches a message/rfc822 MIME part,
- only the header of the nested message will be searched for the key
- strings, treating the header as a single string; the contents of the
- nested message body parts are only searched if their content type
- matches the :content specification.
-
- For other MIME types, the entire part will be searched as a single
- string.
-
-
-
-
-
-Degener & Guenther Standards Track [Page 4]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
- (Matches against container types with an empty match string can be
- useful as tests for the existence of such parts.)
-
- Example:
-
- From: Whomever
- To: Someone
- Date: Whenever
- Subject: whatever
- Content-Type: multipart/mixed; boundary=outer
-
- & This is a multi-part message in MIME format.
- &
- --outer
- Content-Type: multipart/alternative; boundary=inner
-
- & This is a nested multi-part message in MIME format.
- &
- --inner
- Content-Type: text/plain; charset="us-ascii"
-
- $ Hello
- $
- --inner
- Content-Type: text/html; charset="us-ascii"
-
- % <html><body>Hello</body></html>
- %
- --inner--
- &
- & This is the end of the inner MIME multipart.
- &
- --outer
- Content-Type: message/rfc822
-
- ! From: Someone Else
- ! Subject: hello request
-
- $ Please say Hello
- $
- --outer--
- &
- & This is the end of the outer MIME multipart.
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 5]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
- In the above example, the '&', '$', '%', and '!' characters at the
- start of a line are used to illustrate what portions of the example
- message are used in tests:
-
- - the lines starting with '&' are the ones that are tested when a
- 'body :content "multipart" :contains "MIME"' test is executed.
-
- - the lines starting with '$' are the ones that are tested when a
- 'body :content "text/plain" :contains "Hello"' test is executed.
-
- - the lines starting with '%' are the ones that are tested when a
- 'body :content "text/html" :contains "Hello"' test is executed.
-
- - the lines starting with '$' or '%' are the ones that are tested
- when a 'body :content "text" :contains "Hello"' test is executed.
-
- - the lines starting with '!' are the ones that are tested when a
- 'body :content "message/rfc822" :contains "Hello"' test is
- executed.
-
- Comparisons are performed on octets. Implementations decode the
- content-transfer-encoding and convert text to [UTF-8] as input to the
- comparator. MIME parts that cannot be decoded and converted MAY be
- treated as plain US-ASCII, omitted, or processed according to local
- conventions. A NUL octet (character zero) SHOULD NOT cause early
- termination of the content being compared against. Implementations
- MUST support the "quoted-printable", "base64", "7bit", "8bit", and
- "binary" content transfer encodings. Implementations MUST be capable
- of converting to UTF-8 the US-ASCII, ISO-8859-1, and the US-ASCII
- subset of ISO-8859-* character sets.
-
- Each matched part is matched against independently: search
- expressions MUST NOT match across MIME part boundaries. MIME headers
- of the containing part MUST NOT be included in the data.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 6]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
- Example:
-
- require ["body", "fileinto"];
-
- # Save any message with any text MIME part that contains the
- # words "missile" or "coordinates" in the "secrets" folder.
-
- if body :content "text" :contains ["missile", "coordinates"] {
- fileinto "secrets";
- }
-
- # Save any message with an audio/mp3 MIME part in
- # the "jukebox" folder.
-
- if body :content "audio/mp3" :contains "" {
- fileinto "jukebox";
- }
-
-5.3. Body Transform ":text"
-
- The ":text" body transform matches against the results of an
- implementation's best effort at extracting UTF-8 encoded text from a
- message.
-
- It is unspecified whether this transformation results in a single
- string or multiple strings being matched against. All the text
- extracted from a given non-container MIME part MUST be in the same
- string.
-
- In simple implementations, :text MAY be treated the same as :content
- "text".
-
- Sophisticated implementations MAY strip mark-up from the text prior
- to matching, and MAY convert media types other than text to text
- prior to matching.
-
- (For example, they may be able to convert proprietary text editor
- formats to text or apply optical character recognition algorithms to
- image data.)
-
- Example:
- require ["body", "fileinto"];
-
- # Save messages mentioning the project schedule in the
- # project/schedule folder.
- if body :text :contains "project schedule" {
- fileinto "project/schedule";
- }
-
-
-
-Degener & Guenther Standards Track [Page 7]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
-6. Interaction with Other Sieve Extensions
-
- Any extension that extends the grammar for the COMPARATOR or MATCH-
- TYPE nonterminals will also affect the implementation of "body".
-
- Wildcard expressions used with "body" are exempt from the side
- effects described in [VARIABLES]. That is, they MUST NOT set match
- variables (${1}, ${2}...) to the input values corresponding to
- wildcard sequences in the matched pattern. However, if the extension
- is present, variable references in the key strings or content type
- strings are evaluated as described in this document.
-
-7. IANA Considerations
-
- The following template specifies the IANA registration of the Sieve
- extension specified in this document:
-
- To: iana at iana.org
- Subject: Registration of new Sieve extension
-
- Capability name: body
- Description: Provides a test for matching against the
- body of the message being processed
- RFC number: RFC 5173
- Contact Address: The Sieve discussion list
- <ietf-mta-filters at imc.org>
-
-8. Security Considerations
-
- The system MUST be sized and restricted in such a manner that even
- malicious use of body matching does not deny service to other users
- of the host system.
-
- Filters relying on string matches in the raw body of an email message
- may be more general than intended. Text matches are no replacement
- for a spam, virus, or other security related filtering system.
-
-9. Acknowledgments
-
- This document has been revised in part based on comments and
- discussions that took place on and off the SIEVE mailing list.
- Thanks to Cyrus Daboo, Ned Freed, Bob Johannessen, Simon Josefsson,
- Mark E. Mallett, Chris Markle, Alexey Melnikov, Ken Murchison, Greg
- Shapiro, Tim Showalter, Nigel Swinson, Dowson Tong, and Christian
- Vogt for reviews and suggestions.
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 8]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
-10. References
-
-10.1. Normative References
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
- [SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An
- Email Filtering Language", RFC 5228, January 2008.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
-
-10.2. Informative References
-
- [VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension",
- RFC 5229, January 2008.
-
-Authors' Addresses
-
- Jutta Degener
- 5245 College Ave, Suite #127
- Oakland, CA 94618
-
- EMail: jutta at pobox.com
-
-
- Philip Guenther
- Sendmail, Inc.
- 6425 Christie Ave, 4th Floor
- Emeryville, CA 94608
-
- EMail: guenther at sendmail.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 9]
-
-RFC 5173 Sieve Email Filtering: Body Extension April 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr at ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 10]
-
diff --git a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5228/rfc5228.txt b/chrome/chromeFiles/content/libs/libSieveDOM/RFC5228/rfc5228.txt
deleted file mode 100644
index e5a02c6..0000000
--- a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5228/rfc5228.txt
+++ /dev/null
@@ -1,2355 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Guenther, Ed.
-Request for Comments: 5228 Sendmail, Inc.
-Obsoletes: 3028 T. Showalter, Ed.
-Category: Standards Track January 2008
-
-
- Sieve: An Email Filtering Language
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document describes a language for filtering email messages at
- time of final delivery. It is designed to be implementable on either
- a mail client or mail server. It is meant to be extensible, simple,
- and independent of access protocol, mail architecture, and operating
- system. It is suitable for running on a mail server where users may
- not be allowed to execute arbitrary programs, such as on black box
- Internet Message Access Protocol (IMAP) servers, as the base language
- has no variables, loops, or ability to shell out to external
- programs.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 1]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-Table of Contents
-
- 1. Introduction ....................................................4
- 1.1. Conventions Used in This Document ..........................4
- 1.2. Example Mail Messages ......................................5
- 2. Design ..........................................................6
- 2.1. Form of the Language .......................................6
- 2.2. Whitespace .................................................7
- 2.3. Comments ...................................................7
- 2.4. Literal Data ...............................................7
- 2.4.1. Numbers .............................................7
- 2.4.2. Strings .............................................8
- 2.4.2.1. String Lists ...............................9
- 2.4.2.2. Headers ....................................9
- 2.4.2.3. Addresses .................................10
- 2.4.2.4. Encoding Characters Using
- "encoded-character" .......................10
- 2.5. Tests .....................................................11
- 2.5.1. Test Lists .........................................12
- 2.6. Arguments .................................................12
- 2.6.1. Positional Arguments ...............................12
- 2.6.2. Tagged Arguments ...................................12
- 2.6.3. Optional Arguments .................................13
- 2.6.4. Types of Arguments .................................13
- 2.7. String Comparison .........................................13
- 2.7.1. Match Type .........................................14
- 2.7.2. Comparisons across Character Sets ..................15
- 2.7.3. Comparators ........................................15
- 2.7.4. Comparisons against Addresses ......................16
- 2.8. Blocks ....................................................17
- 2.9. Commands ..................................................17
- 2.10. Evaluation ...............................................18
- 2.10.1. Action Interaction ................................18
- 2.10.2. Implicit Keep .....................................18
- 2.10.3. Message Uniqueness in a Mailbox ...................19
- 2.10.4. Limits on Numbers of Actions ......................19
- 2.10.5. Extensions and Optional Features ..................19
- 2.10.6. Errors ............................................20
- 2.10.7. Limits on Execution ...............................20
- 3. Control Commands ...............................................21
- 3.1. Control if ................................................21
- 3.2. Control require ...........................................22
- 3.3. Control stop ..............................................22
- 4. Action Commands ................................................23
- 4.1. Action fileinto ...........................................23
- 4.2. Action redirect ...........................................23
- 4.3. Action keep ...............................................24
- 4.4. Action discard ............................................25
-
-
-
-Guenther & Showalter Standards Track [Page 2]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- 5. Test Commands ..................................................26
- 5.1. Test address ..............................................26
- 5.2. Test allof ................................................27
- 5.3. Test anyof ................................................27
- 5.4. Test envelope .............................................27
- 5.5. Test exists ...............................................28
- 5.6. Test false ................................................28
- 5.7. Test header ...............................................29
- 5.8. Test not ..................................................29
- 5.9. Test size .................................................29
- 5.10. Test true ................................................30
- 6. Extensibility ..................................................30
- 6.1. Capability String .........................................31
- 6.2. IANA Considerations .......................................31
- 6.2.1. Template for Capability Registrations ..............32
- 6.2.2. Handling of Existing Capability Registrations ......32
- 6.2.3. Initial Capability Registrations ...................32
- 6.3. Capability Transport ......................................33
- 7. Transmission ...................................................33
- 8. Parsing ........................................................34
- 8.1. Lexical Tokens ............................................34
- 8.2. Grammar ...................................................36
- 8.3. Statement Elements ........................................36
- 9. Extended Example ...............................................37
- 10. Security Considerations .......................................38
- 11. Acknowledgments ...............................................39
- 12. Normative References ..........................................39
- 13. Informative References ........................................40
- 14. Changes from RFC 3028 .........................................41
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 3]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-1. Introduction
-
- This memo documents a language that can be used to create filters for
- electronic mail. It is not tied to any particular operating system
- or mail architecture. It requires the use of [IMAIL]-compliant
- messages, but should otherwise generalize to many systems.
-
- The language is powerful enough to be useful but limited in order to
- allow for a safe server-side filtering system. The intention is to
- make it impossible for users to do anything more complex (and
- dangerous) than write simple mail filters, along with facilitating
- the use of graphical user interfaces (GUIs) for filter creation and
- manipulation. The base language was not designed to be Turing-
- complete: it does not have a loop control structure or functions.
-
- Scripts written in Sieve are executed during final delivery, when the
- message is moved to the user-accessible mailbox. In systems where
- the Mail Transfer Agent (MTA) does final delivery, such as
- traditional Unix mail, it is reasonable to filter when the MTA
- deposits mail into the user's mailbox.
-
- There are a number of reasons to use a filtering system. Mail
- traffic for most users has been increasing due to increased usage of
- email, the emergence of unsolicited email as a form of advertising,
- and increased usage of mailing lists.
-
- Experience at Carnegie Mellon has shown that if a filtering system is
- made available to users, many will make use of it in order to file
- messages from specific users or mailing lists. However, many others
- did not make use of the Andrew system's FLAMES filtering language
- [FLAMES] due to difficulty in setting it up.
-
- Because of the expectation that users will make use of filtering if
- it is offered and easy to use, this language has been made simple
- enough to allow many users to make use of it, but rich enough that it
- can be used productively. However, it is expected that GUI-based
- editors will be the preferred way of editing filters for a large
- number of users.
-
-1.1. Conventions Used in This Document
-
- In the sections of this document that discuss the requirements of
- various keywords and operators, the following conventions have been
- adopted.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [KEYWORDS].
-
-
-
-Guenther & Showalter Standards Track [Page 4]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- Each section on a command (test, action, or control) has a line
- labeled "Usage:". This line describes the usage of the command,
- including its name and its arguments. Required arguments are listed
- inside angle brackets ("<" and ">"). Optional arguments are listed
- inside square brackets ("[" and "]"). Each argument is followed by
- its type, so "<key: string>" represents an argument called "key" that
- is a string. Literal strings are represented with double-quoted
- strings. Alternatives are separated with slashes, and parentheses
- are used for grouping, similar to [ABNF].
-
- In the "Usage:" line, there are three special pieces of syntax that
- are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART.
- These are discussed in sections 2.7.1, 2.7.3, and 2.7.4,
- respectively.
-
- The formal grammar for these commands is defined in section 8 and is
- the authoritative reference on how to construct commands, but the
- formal grammar does not specify the order, semantics, number or types
- of arguments to commands, or the legal command names. The intent is
- to allow for extension without changing the grammar.
-
-1.2. Example Mail Messages
-
- The following mail messages will be used throughout this document in
- examples.
-
- Message A
- -----------------------------------------------------------
- Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
- From: coyote at desert.example.org
- To: roadrunner at acme.example.com
- Subject: I have a present for you
-
- Look, I'm sorry about the whole anvil thing, and I really
- didn't mean to try and drop it on you from the top of the
- cliff. I want to try to make it up to you. I've got some
- great birdseed over here at my place--top of the line
- stuff--and if you come by, I'll have it all wrapped up
- for you. I'm really sorry for all the problems I've caused
- for you over the years, but I know we can work this out.
- --
- Wile E. Coyote "Super Genius" coyote at desert.example.org
- -----------------------------------------------------------
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 5]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- Message B
- -----------------------------------------------------------
- From: youcouldberich!@reply-by-postal-mail.invalid
- Sender: b1ff at de.res.example.com
- To: rube at landru.example.com
- Date: Mon, 31 Mar 1997 18:26:10 -0800
- Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$
-
- YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT
- IT! SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS! IT WILL
- GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY!
- MONEY! MONEY! COLD HARD CASH! YOU WILL RECEIVE OVER
- $20,000 IN LESS THAN TWO MONTHS! AND IT'S LEGAL!!!!!!!!!
- !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1 JUST
- SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
- -----------------------------------------------------------
-
-2. Design
-
-2.1. Form of the Language
-
- The language consists of a set of commands. Each command consists of
- a set of tokens delimited by whitespace. The command identifier is
- the first token and it is followed by zero or more argument tokens.
- Arguments may be literal data, tags, blocks of commands, or test
- commands.
-
- With the exceptions of strings and comments, the language is limited
- to US-ASCII characters. Strings and comments may contain octets
- outside the US-ASCII range. Specifically, they will normally be in
- UTF-8, as specified in [UTF-8]. NUL (US-ASCII 0) is never permitted
- in scripts, while CR and LF can only appear as the CRLF line ending.
-
- Note: While this specification permits arbitrary octets to appear
- in Sieve scripts inside strings and comments, this has made it
- difficult to robustly handle Sieve scripts in programs that are
- sensitive to the encodings used. The "encoded-character"
- capability (section 2.4.2.4) provides an alternative means of
- representing such octets in strings using just US-ASCII
- characters. As such, the use of non-UTF-8 text in scripts should
- be considered a deprecated feature that may be abandoned.
-
- Tokens other than strings are considered case-insensitive.
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 6]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-2.2. Whitespace
-
- Whitespace is used to separate tokens. Whitespace is made up of
- tabs, newlines (CRLF, never just CR or LF), and the space character.
- The amount of whitespace used is not significant.
-
-2.3. Comments
-
- Two types of comments are offered. Comments are semantically
- equivalent to whitespace and can be used anyplace that whitespace is
- (with one exception in multi-line strings, as described in the
- grammar).
-
- Hash comments begin with a "#" character that is not contained within
- a string and continue until the next CRLF.
-
- Example: if size :over 100k { # this is a comment
- discard;
- }
-
- Bracketed comments begin with the token "/*" and end with "*/"
- outside of a string. Bracketed comments may span multiple lines.
- Bracketed comments do not nest.
-
- Example: if size :over 100K { /* this is a comment
- this is still a comment */ discard /* this is a comment
- */ ;
- }
-
-2.4. Literal Data
-
- Literal data means data that is not executed, merely evaluated "as
- is", to be used as arguments to commands. Literal data is limited to
- numbers, strings, and string lists.
-
-2.4.1. Numbers
-
- Numbers are given as ordinary decimal numbers. As a shorthand for
- expressing larger values, such as message sizes, a suffix of "K",
- "M", or "G" MAY be appended to indicate a multiple of a power of two.
- To be comparable with the power-of-two-based versions of SI units
- that computers frequently use, "K" specifies kibi-, or 1,024 (2^10)
- times the value of the number; "M" specifies mebi-, or 1,048,576
- (2^20) times the value of the number; and "G" specifies gibi-, or
- 1,073,741,824 (2^30) times the value of the number [BINARY-SI].
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 7]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- Implementations MUST support integer values in the inclusive range
- zero to 2,147,483,647 (2^31 - 1), but MAY support larger values.
-
- Only non-negative integers are permitted by this specification.
-
-2.4.2. Strings
-
- Scripts involve large numbers of string values as they are used for
- pattern matching, addresses, textual bodies, etc. Typically, short
- quoted strings suffice for most uses, but a more convenient form is
- provided for longer strings such as bodies of messages.
-
- A quoted string starts and ends with a single double quote (the <">
- character, US-ASCII 34). A backslash ("\", US-ASCII 92) inside of a
- quoted string is followed by either another backslash or a double
- quote. These two-character sequences represent a single backslash or
- double quote within the value, respectively.
-
- Scripts SHOULD NOT escape other characters with a backslash.
-
- An undefined escape sequence (such as "\a" in a context where "a" has
- no special meaning) is interpreted as if there were no backslash (in
- this case, "\a" is just "a"), though that may be changed by
- extensions.
-
- Non-printing characters such as tabs, CRLF, and control characters
- are permitted in quoted strings. Quoted strings MAY span multiple
- lines. An unencoded NUL (US-ASCII 0) is not allowed in strings; see
- section 2.4.2.4 for how it can be encoded.
-
- As message header data is converted to [UTF-8] for comparison (see
- section 2.7.2), most string values will use the UTF-8 encoding.
- However, implementations MUST accept all strings that match the
- grammar in section 8. The ability to use non-UTF-8 encoded strings
- matches existing practice and has proven to be useful both in tests
- for invalid data and in arguments containing raw MIME parts for
- extension actions that generate outgoing messages.
-
- For entering larger amounts of text, such as an email message, a
- multi-line form is allowed. It starts with the keyword "text:",
- followed by a CRLF, and ends with the sequence of a CRLF, a single
- period, and another CRLF. The CRLF before the final period is
- considered part of the value. In order to allow the message to
- contain lines with a single dot, lines are dot-stuffed. That is,
- when composing a message body, an extra '.' is added before each line
- that begins with a '.'. When the server interprets the script, these
- extra dots are removed. Note that a line that begins with a dot
- followed by a non-dot character is not interpreted as dot-stuffed;
-
-
-
-Guenther & Showalter Standards Track [Page 8]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- that is, ".foo" is interpreted as ".foo". However, because this is
- potentially ambiguous, scripts SHOULD be properly dot-stuffed so such
- lines do not appear.
-
- Note that a hashed comment or whitespace may occur in between the
- "text:" and the CRLF, but not within the string itself. Bracketed
- comments are not allowed here.
-
-2.4.2.1. String Lists
-
- When matching patterns, it is frequently convenient to match against
- groups of strings instead of single strings. For this reason, a list
- of strings is allowed in many tests, implying that if the test is
- true using any one of the strings, then the test is true.
-
- For instance, the test 'header :contains ["To", "Cc"]
- ["me at example.com", "me00 at landru.example.com"]' is true if either a To
- header or Cc header of the input message contains either of the email
- addresses "me at example.com" or "me00 at landru.example.com".
-
- Conversely, in any case where a list of strings is appropriate, a
- single string is allowed without being a member of a list: it is
- equivalent to a list with a single member. This means that the test
- 'exists "To"' is equivalent to the test 'exists ["To"]'.
-
-2.4.2.2. Headers
-
- Headers are a subset of strings. In the Internet Message
- Specification [IMAIL], each header line is allowed to have whitespace
- nearly anywhere in the line, including after the field name and
- before the subsequent colon. Extra spaces between the header name
- and the ":" in a header field are ignored.
-
- A header name never contains a colon. The "From" header refers to a
- line beginning "From:" (or "From :", etc.). No header will match
- the string "From:" due to the trailing colon.
-
- Similarly, no header will match a syntactically invalid header name.
- An implementation MUST NOT cause an error for syntactically invalid
- header names in tests.
-
- Header lines are unfolded as described in [IMAIL] section 2.2.3.
- Interpretation of header data SHOULD be done according to [MIME3]
- section 6.2 (see section 2.7.2 below for details).
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 9]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-2.4.2.3. Addresses
-
- A number of commands call for email addresses, which are also a
- subset of strings. When these addresses are used in outbound
- contexts, addresses must be compliant with [IMAIL], but are further
- constrained within this document. Using the symbols defined in
- [IMAIL], section 3, the syntax of an address is:
-
- sieve-address = addr-spec ; simple address
- / phrase "<" addr-spec ">" ; name & addr-spec
-
- That is, routes and group syntax are not permitted. If multiple
- addresses are required, use a string list. Named groups are not
- permitted.
-
- It is an error for a script to execute an action with a value for use
- as an outbound address that doesn't match the "sieve-address" syntax.
-
-2.4.2.4. Encoding Characters Using "encoded-character"
-
- When the "encoded-character" extension is in effect, certain
- character sequences in strings are replaced by their decoded value.
- This happens after escape sequences are interpreted and dot-
- unstuffing has been done. Implementations SHOULD support "encoded-
- character".
-
- Arbitrary octets can be embedded in strings by using the syntax
- encoded-arb-octets. The sequence is replaced by the octets with the
- hexadecimal values given by each hex-pair.
-
- blank = WSP / CRLF
- encoded-arb-octets = "${hex:" hex-pair-seq "}"
- hex-pair-seq = *blank hex-pair *(1*blank hex-pair) *blank
- hex-pair = 1*2HEXDIG
-
- Where WSP and HEXDIG non-terminals are defined in Appendix B.1 of
- [ABNF].
-
- It may be inconvenient or undesirable to enter Unicode characters
- verbatim, and for these cases the syntax encoded-unicode-char can be
- used. The sequence is replaced by the UTF-8 encoding of the
- specified Unicode characters, which are identified by the hexadecimal
- value of unicode-hex.
-
- encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
- unicode-hex-seq = *blank unicode-hex
- *(1*blank unicode-hex) *blank
- unicode-hex = 1*HEXDIG
-
-
-
-Guenther & Showalter Standards Track [Page 10]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- It is an error for a script to use a hexadecimal value that isn't in
- either the range 0 to D7FF or the range E000 to 10FFFF. (The range
- D800 to DFFF is excluded as those character numbers are only used as
- part of the UTF-16 encoding form and are not applicable to the UTF-8
- encoding that the syntax here represents.)
-
- Note: Implementations MUST NOT raise an error for an out-of-range
- Unicode value unless the sequence containing it is well-formed
- according to the grammar.
-
- The capability string for use with the require command is "encoded-
- character".
-
- In the following script, message B is discarded, since the specified
- test string is equivalent to "$$$".
-
- Example: require "encoded-character";
- if header :contains "Subject" "$${hex:24 24}" {
- discard;
- }
- The following examples demonstrate valid and invalid encodings and
- how they are handled:
-
- "$${hex:40}" -> "$@"
- "${hex: 40 }" -> "@"
- "${HEX: 40}" -> "@"
- "${hex:40" -> "${hex:40"
- "${hex:400}" -> "${hex:400}"
- "${hex:4${hex:30}}" -> "${hex:40}"
- "${unicode:40}" -> "@"
- "${ unicode:40}" -> "${ unicode:40}"
- "${UNICODE:40}" -> "@"
- "${UnICoDE:0000040}" -> "@"
- "${Unicode:40}" -> "@"
- "${Unicode:Cool}" -> "${Unicode:Cool}"
- "${unicode:200000}" -> error
- "${Unicode:DF01} -> error
-
-2.5. Tests
-
- Tests are given as arguments to commands in order to control their
- actions. In this document, tests are given to if/elsif to decide
- which block of code is run.
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 11]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-2.5.1. Test Lists
-
- Some tests ("allof" and "anyof", which implement logical "and" and
- logical "or", respectively) may require more than a single test as an
- argument. The test-list syntax element provides a way of grouping
- tests as a comma-separated list in parentheses.
-
- Example: if anyof (not exists ["From", "Date"],
- header :contains "from" "fool at example.com") {
- discard;
- }
-
-2.6. Arguments
-
- In order to specify what to do, most commands take arguments. There
- are three types of arguments: positional, tagged, and optional.
-
- It is an error for a script, on a single command, to use conflicting
- arguments or to use a tagged or optional argument more than once.
-
-2.6.1. Positional Arguments
-
- Positional arguments are given to a command that discerns their
- meaning based on their order. When a command takes positional
- arguments, all positional arguments must be supplied and must be in
- the order prescribed.
-
-2.6.2. Tagged Arguments
-
- This document provides for tagged arguments in the style of
- CommonLISP. These are also similar to flags given to commands in
- most command-line systems.
-
- A tagged argument is an argument for a command that begins with ":"
- followed by a tag naming the argument, such as ":contains". This
- argument means that zero or more of the next tokens have some
- particular meaning depending on the argument. These next tokens may
- be literal data, but they are never blocks.
-
- Tagged arguments are similar to positional arguments, except that
- instead of the meaning being derived from the command, it is derived
- from the tag.
-
- Tagged arguments must appear before positional arguments, but they
- may appear in any order with other tagged arguments. For simplicity
- of the specification, this is not expressed in the syntax definitions
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 12]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- with commands, but they still may be reordered arbitrarily provided
- they appear before positional arguments. Tagged arguments may be
- mixed with optional arguments.
-
- Tagged arguments SHOULD NOT take tagged arguments as arguments.
-
-2.6.3. Optional Arguments
-
- Optional arguments are exactly like tagged arguments except that they
- may be left out, in which case a default value is implied. Because
- optional arguments tend to result in shorter scripts, they have been
- used far more than tagged arguments.
-
- One particularly noteworthy case is the ":comparator" argument, which
- allows the user to specify which comparator [COLLATION] will be used
- to compare two strings, since different languages may impose
- different orderings on UTF-8 [UTF-8] strings.
-
-2.6.4. Types of Arguments
-
- Abstractly, arguments may be literal data, tests, or blocks of
- commands. In this way, an "if" control structure is merely a command
- that happens to take a test and a block as arguments and may execute
- the block of code.
-
- However, this abstraction is ambiguous from a parsing standpoint.
-
- The grammar in section 8.2 presents a parsable version of this:
- Arguments are string lists (string-lists), numbers, and tags, which
- may be followed by a test or a test list (test-list), which may be
- followed by a block of commands. No more than one test or test list,
- or more than one block of commands, may be used, and commands that
- end with a block of commands do not end with semicolons.
-
-2.7. String Comparison
-
- When matching one string against another, there are a number of ways
- of performing the match operation. These are accomplished with three
- types of matches: an exact match, a substring match, and a wildcard
- glob-style match. These are described below.
-
- In order to provide for matches between character sets and case
- insensitivity, Sieve uses the comparators defined in the Internet
- Application Protocol Collation Registry [COLLATION].
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 13]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- However, when a string represents the name of a header, the
- comparator is never user-specified. Header comparisons are always
- done with the "i;ascii-casemap" operator, i.e., case-insensitive
- comparisons, because this is the way things are defined in the
- message specification [IMAIL].
-
-2.7.1. Match Type
-
- Commands that perform string comparisons may have an optional match
- type argument. The three match types in this specification are
- ":contains", ":is", and ":matches".
-
- The ":contains" match type describes a substring match. If the value
- argument contains the key argument as a substring, the match is true.
- For instance, the string "frobnitzm" contains "frob" and "nit", but
- not "fbm". The empty key ("") is contained in all values.
-
- The ":is" match type describes an absolute match; if the contents of
- the first string are absolutely the same as the contents of the
- second string, they match. Only the string "frobnitzm" is the string
- "frobnitzm". The empty key ("") only ":is" matches with the empty
- value.
-
- The ":matches" match type specifies a wildcard match using the
- characters "*" and "?"; the entire value must be matched. "*"
- matches zero or more characters in the value and "?" matches a single
- character in the value, where the comparator that is used (see
- section 2.7.3) defines what a character is. For example, the
- comparators "i;octet" and "i;ascii-casemap" define a character to be
- a single octet, so "?" will always match exactly one octet when one
- of those comparators is in use. In contrast, a Unicode-based
- comparator would define a character to be any UTF-8 octet sequence
- encoding one Unicode character and thus "?" may match more than one
- octet. "?" and "*" may be escaped as "\\?" and "\\*" in strings to
- match against themselves. The first backslash escapes the second
- backslash; together, they escape the "*". This is awkward, but it is
- commonplace in several programming languages that use globs and
- regular expressions.
-
- In order to specify what type of match is supposed to happen,
- commands that support matching take optional arguments ":matches",
- ":is", and ":contains". Commands default to using ":is" matching if
- no match type argument is supplied. Note that these modifiers
- interact with comparators; in particular, only comparators that
- support the "substring match" operation are suitable for matching
- with ":contains" or ":matches". It is an error to use a comparator
- with ":contains" or ":matches" that is not compatible with it.
-
-
-
-
-Guenther & Showalter Standards Track [Page 14]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- It is an error to give more than one of these arguments to a given
- command.
-
- For convenience, the "MATCH-TYPE" syntax element is defined here as
- follows:
-
- Syntax: ":is" / ":contains" / ":matches"
-
-2.7.2. Comparisons across Character Sets
-
- Messages may involve a number of character sets. In order for
- comparisons to work across character sets, implementations SHOULD
- implement the following behavior:
-
- Comparisons are performed on octets. Implementations convert text
- from header fields in all charsets [MIME3] to Unicode, encoded as
- UTF-8, as input to the comparator (see section 2.7.3).
- Implementations MUST be capable of converting US-ASCII, ISO-8859-
- 1, the US-ASCII subset of ISO-8859-* character sets, and UTF-8.
- Text that the implementation cannot convert to Unicode for any
- reason MAY be treated as plain US-ASCII (including any [MIME3]
- syntax) or processed according to local conventions. An encoded
- NUL octet (character zero) SHOULD NOT cause early termination of
- the header content being compared against.
-
- If implementations fail to support the above behavior, they MUST
- conform to the following:
-
- No two strings can be considered equal if one contains octets
- greater than 127.
-
-2.7.3. Comparators
-
- In order to allow for language-independent, case-independent matches,
- the match type may be coupled with a comparator name. The Internet
- Application Protocol Collation Registry [COLLATION] provides the
- framework for describing and naming comparators.
-
- All implementations MUST support the "i;octet" comparator (simply
- compares octets) and the "i;ascii-casemap" comparator (which treats
- uppercase and lowercase characters in the US-ASCII subset of UTF-8 as
- the same). If left unspecified, the default is "i;ascii-casemap".
-
- Some comparators may not be usable with substring matches; that is,
- they may only work with ":is". It is an error to try to use a
- comparator with ":matches" or ":contains" that is not compatible with
- it.
-
-
-
-
-Guenther & Showalter Standards Track [Page 15]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- Sieve treats a comparator result of "undefined" the same as a result
- of "no-match". That is, this base specification does not provide any
- means to directly detect invalid comparator input.
-
- A comparator is specified by the ":comparator" option with commands
- that support matching. This option is followed by a string providing
- the name of the comparator to be used. For convenience, the syntax
- of a comparator is abbreviated to "COMPARATOR", and (repeated in
- several tests) is as follows:
-
- Syntax: ":comparator" <comparator-name: string>
-
- So in this example,
-
- Example: if header :contains :comparator "i;octet" "Subject"
- "MAKE MONEY FAST" {
- discard;
- }
-
- would discard any message with subjects like "You can MAKE MONEY
- FAST", but not "You can Make Money Fast", since the comparator used
- is case-sensitive.
-
- Comparators other than "i;octet" and "i;ascii-casemap" must be
- declared with require, as they are extensions. If a comparator
- declared with require is not known, it is an error, and execution
- fails. If the comparator is not declared with require, it is also an
- error, even if the comparator is supported. (See section 2.10.5.)
-
- Both ":matches" and ":contains" match types are compatible with the
- "i;octet" and "i;ascii-casemap" comparators and may be used with
- them.
-
- It is an error to give more than one of these arguments to a given
- command.
-
-2.7.4. Comparisons against Addresses
-
- Addresses are one of the most frequent things represented as strings.
- These are structured, and being able to compare against the local-
- part or the domain of an address is useful, so some tests that act
- exclusively on addresses take an additional optional argument that
- specifies what the test acts on.
-
- These optional arguments are ":localpart", ":domain", and ":all",
- which act on the local-part (left side), the domain-part (right
- side), and the whole address.
-
-
-
-
-Guenther & Showalter Standards Track [Page 16]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- If an address is not syntactically valid, then it will not be matched
- by tests specifying ":localpart" or ":domain".
-
- The kind of comparison done, such as whether or not the test done is
- case-insensitive, is specified as a comparator argument to the test.
-
- If an optional address-part is omitted, the default is ":all".
-
- It is an error to give more than one of these arguments to a given
- command.
-
- For convenience, the "ADDRESS-PART" syntax element is defined here as
- follows:
-
- Syntax: ":localpart" / ":domain" / ":all"
-
-2.8. Blocks
-
- Blocks are sets of commands enclosed within curly braces and supplied
- as the final argument to a command. Such a command is a control
- structure: when executed it has control over the number of times the
- commands in the block are executed.
-
- With the commands supplied in this memo, there are no loops. The
- control structures supplied--if, elsif, and else--run a block either
- once or not at all.
-
-2.9. Commands
-
- Sieve scripts are sequences of commands. Commands can take any of
- the tokens above as arguments, and arguments may be either tagged or
- positional arguments. Not all commands take all arguments.
-
- There are three kinds of commands: test commands, action commands,
- and control commands.
-
- The simplest is an action command. An action command is an
- identifier followed by zero or more arguments, terminated by a
- semicolon. Action commands do not take tests or blocks as arguments.
- The actions referenced in this document are:
-
- - keep, to save the message in the default location
- - fileinto, to save the message in a specific mailbox
- - redirect, to forward the message to another address
- - discard, to silently throw away the message
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 17]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- A control command is a command that affects the parsing or the flow
- of execution of the Sieve script in some way. A control structure is
- a control command that ends with a block instead of a semicolon.
-
- A test command is used as part of a control command. It is used to
- specify whether or not the block of code given to the control command
- is executed.
-
-2.10. Evaluation
-
-2.10.1. Action Interaction
-
- Some actions cannot be used with other actions because the result
- would be absurd. These restrictions are noted throughout this memo.
-
- Extension actions MUST state how they interact with actions defined
- in this specification.
-
-2.10.2. Implicit Keep
-
- Previous experience with filtering systems suggests that cases tend
- to be missed in scripts. To prevent errors, Sieve has an "implicit
- keep".
-
- An implicit keep is a keep action (see section 4.3) performed in
- absence of any action that cancels the implicit keep.
-
- An implicit keep is performed if a message is not written to a
- mailbox, redirected to a new address, or explicitly thrown out. That
- is, if a fileinto, a keep, a redirect, or a discard is performed, an
- implicit keep is not.
-
- Some actions may be defined to not cancel the implicit keep. These
- actions may not directly affect the delivery of a message, and are
- used for their side effects. None of the actions specified in this
- document meet that criteria, but extension actions may.
-
- For instance, with any of the short messages offered above, the
- following script produces no actions.
-
- Example: if size :over 500K { discard; }
-
- As a result, the implicit keep is taken.
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 18]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-2.10.3. Message Uniqueness in a Mailbox
-
- Implementations SHOULD NOT deliver a message to the same mailbox more
- than once, even if a script explicitly asks for a message to be
- written to a mailbox twice.
-
- The test for equality of two messages is implementation-defined.
-
- If a script asks for a message to be written to a mailbox twice, it
- MUST NOT be treated as an error.
-
-2.10.4. Limits on Numbers of Actions
-
- Site policy MAY limit the number of actions taken and MAY impose
- restrictions on which actions can be used together. In the event
- that a script hits a policy limit on the number of actions taken for
- a particular message, an error occurs.
-
- Implementations MUST allow at least one keep or one fileinto. If
- fileinto is not implemented, implementations MUST allow at least one
- keep.
-
-2.10.5. Extensions and Optional Features
-
- Because of the differing capabilities of many mail systems, several
- features of this specification are optional. Before any of these
- extensions can be executed, they must be declared with the "require"
- action.
-
- If an extension is not enabled with "require", implementations MUST
- treat it as if they did not support it at all. This protects scripts
- from having their behavior altered by extensions that the script
- author might not have even been aware of.
-
- Implementations MUST NOT execute any Sieve script test or command
- subsequent to "require" if one of the required extensions is
- unavailable.
-
- Note: The reason for this restriction is that prior experiences
- with languages such as LISP and Tcl suggest that this is a
- workable way of noting that a given script uses an extension.
-
- Extensions that define actions MUST state how they interact with
- actions discussed in the base specification.
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 19]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-2.10.6. Errors
-
- In any programming language, there are compile-time and run-time
- errors.
-
- Compile-time errors are ones in syntax that are detectable if a
- syntax check is done.
-
- Run-time errors are not detectable until the script is run. This
- includes transient failures like disk full conditions, but also
- includes issues like invalid combinations of actions.
-
- When an error occurs in a Sieve script, all processing stops.
-
- Implementations MAY choose to do a full parse, then evaluate the
- script, then do all actions. Implementations might even go so far as
- to ensure that execution is atomic (either all actions are executed
- or none are executed).
-
- Other implementations may choose to parse and run at the same time.
- Such implementations are simpler, but have issues with partial
- failure (some actions happen, others don't).
-
- Implementations MUST perform syntactic, semantic, and run-time checks
- on code that is actually executed. Implementations MAY perform those
- checks or any part of them on code that is not reached during
- execution.
-
- When an error happens, implementations MUST notify the user that an
- error occurred and which actions (if any) were taken, and do an
- implicit keep.
-
-2.10.7. Limits on Execution
-
- Implementations may limit certain constructs. However, this
- specification places a lower bound on some of these limits.
-
- Implementations MUST support fifteen levels of nested blocks.
-
- Implementations MUST support fifteen levels of nested test lists.
-
-
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 20]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-3. Control Commands
-
- Control structures are needed to allow for multiple and conditional
- actions.
-
-3.1. Control if
-
- There are three pieces to if: "if", "elsif", and "else". Each is
- actually a separate command in terms of the grammar. However, an
- elsif or else MUST only follow an if or elsif. An error occurs if
- these conditions are not met.
-
- Usage: if <test1: test> <block1: block>
-
- Usage: elsif <test2: test> <block2: block>
-
- Usage: else <block3: block>
-
- The semantics are similar to those of any of the many other
- programming languages these control structures appear in. When the
- interpreter sees an "if", it evaluates the test associated with it.
- If the test is true, it executes the block associated with it.
-
- If the test of the "if" is false, it evaluates the test of the first
- "elsif" (if any). If the test of "elsif" is true, it runs the
- elsif's block. An elsif may be followed by an elsif, in which case,
- the interpreter repeats this process until it runs out of elsifs.
-
- When the interpreter runs out of elsifs, there may be an "else" case.
- If there is, and none of the if or elsif tests were true, the
- interpreter runs the else's block.
-
- This provides a way of performing exactly one of the blocks in the
- chain.
-
- In the following example, both messages A and B are dropped.
-
- Example: require "fileinto";
- if header :contains "from" "coyote" {
- discard;
- } elsif header :contains ["subject"] ["$$$"] {
- discard;
- } else {
- fileinto "INBOX";
- }
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 21]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- When the script below is run over message A, it redirects the message
- to acm at example.com; message B, to postmaster at example.com; any other
- message is redirected to field at example.com.
-
- Example: if header :contains ["From"] ["coyote"] {
- redirect "acm at example.com";
- } elsif header :contains "Subject" "$$$" {
- redirect "postmaster at example.com";
- } else {
- redirect "field at example.com";
- }
-
- Note that this definition prohibits the "... else if ..." sequence
- used by C. This is intentional, because this construct produces a
- shift-reduce conflict.
-
-3.2. Control require
-
- Usage: require <capabilities: string-list>
-
- The require action notes that a script makes use of a certain
- extension. Such a declaration is required to use the extension, as
- discussed in section 2.10.5. Multiple capabilities can be declared
- with a single require.
-
- The require command, if present, MUST be used before anything other
- than a require can be used. An error occurs if a require appears
- after a command other than require.
-
- Example: require ["fileinto", "reject"];
-
- Example: require "fileinto";
- require "vacation";
-
-3.3. Control stop
-
- Usage: stop
-
- The "stop" action ends all processing. If the implicit keep has not
- been cancelled, then it is taken.
-
-
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 22]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-4. Action Commands
-
- This document supplies four actions that may be taken on a message:
- keep, fileinto, redirect, and discard.
-
- Implementations MUST support the "keep", "discard", and "redirect"
- actions.
-
- Implementations SHOULD support "fileinto".
-
- Implementations MAY limit the number of certain actions taken (see
- section 2.10.4).
-
-4.1. Action fileinto
-
- Usage: fileinto <mailbox: string>
-
- The "fileinto" action delivers the message into the specified
- mailbox. Implementations SHOULD support fileinto, but in some
- environments this may be impossible. Implementations MAY place
- restrictions on mailbox names; use of an invalid mailbox name MAY be
- treated as an error or result in delivery to an implementation-
- defined mailbox. If the specified mailbox doesn't exist, the
- implementation MAY treat it as an error, create the mailbox, or
- deliver the message to an implementation-defined mailbox. If the
- implementation uses a different encoding scheme than UTF-8 for
- mailbox names, it SHOULD reencode the mailbox name from UTF-8 to its
- encoding scheme. For example, the Internet Message Access Protocol
- [IMAP] uses modified UTF-7, such that a mailbox argument of "odds &
- ends" would appear in IMAP as "odds &- ends".
-
- The capability string for use with the require command is "fileinto".
-
- In the following script, message A is filed into mailbox
- "INBOX.harassment".
-
- Example: require "fileinto";
- if header :contains ["from"] "coyote" {
- fileinto "INBOX.harassment";
- }
-
-4.2. Action redirect
-
- Usage: redirect <address: string>
-
- The "redirect" action is used to send the message to another user at
- a supplied address, as a mail forwarding feature does. The
- "redirect" action makes no changes to the message body or existing
-
-
-
-Guenther & Showalter Standards Track [Page 23]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- headers, but it may add new headers. In particular, existing
- Received headers MUST be preserved and the count of Received headers
- in the outgoing message MUST be larger than the same count on the
- message as received by the implementation. (An implementation that
- adds a Received header before processing the message does not need to
- add another when redirecting.)
-
- The message is sent back out with the address from the redirect
- command as an envelope recipient. Implementations MAY combine
- separate redirects for a given message into a single submission with
- multiple envelope recipients. (This is not a Mail User Agent (MUA)-
- style forward, which creates a new message with a different sender
- and message ID, wrapping the old message in a new one.)
-
- The envelope sender address on the outgoing message is chosen by the
- sieve implementation. It MAY be copied from the message being
- processed. However, if the message being processed has an empty
- envelope sender address the outgoing message MUST also have an empty
- envelope sender address. This last requirement is imposed to prevent
- loops in the case where a message is redirected to an invalid address
- when then returns a delivery status notification that also ends up
- being redirected to the same invalid address.
-
- A simple script can be used for redirecting all mail:
-
- Example: redirect "bart at example.com";
-
- Implementations MUST take measures to implement loop control,
- possibly including adding headers to the message or counting Received
- headers as specified in section 6.2 of [SMTP]. If an implementation
- detects a loop, it causes an error.
-
- Implementations MUST provide means of limiting the number of
- redirects a Sieve script can perform. See section 10 for more
- details.
-
- Implementations MAY ignore a redirect action silently due to policy
- reasons. For example, an implementation MAY choose not to redirect
- to an address that is known to be undeliverable. Any ignored
- redirect MUST NOT cancel the implicit keep.
-
-4.3. Action keep
-
- Usage: keep
-
- The "keep" action is whatever action is taken in lieu of all other
- actions, if no filtering happens at all; generally, this simply means
- to file the message into the user's main mailbox. This command
-
-
-
-Guenther & Showalter Standards Track [Page 24]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- provides a way to execute this action without needing to know the
- name of the user's main mailbox, providing a way to call it without
- needing to understand the user's setup or the underlying mail system.
-
- For instance, in an implementation where the IMAP server is running
- scripts on behalf of the user at time of delivery, a keep command is
- equivalent to a fileinto "INBOX".
-
- Example: if size :under 1M { keep; } else { discard; }
-
- Note that the above script is identical to the one below.
-
- Example: if not size :under 1M { discard; }
-
-4.4. Action discard
-
- Usage: discard
-
- Discard is used to silently throw away the message. It does so by
- simply canceling the implicit keep. If discard is used with other
- actions, the other actions still happen. Discard is compatible with
- all other actions. (For instance, fileinto+discard is equivalent to
- fileinto.)
-
- Discard MUST be silent; that is, it MUST NOT return a non-delivery
- notification of any kind ([DSN], [MDN], or otherwise).
-
- In the following script, any mail from "idiot at example.com" is thrown
- out.
-
- Example: if header :contains ["from"] ["idiot at example.com"] {
- discard;
- }
-
- While an important part of this language, "discard" has the potential
- to create serious problems for users: Students who leave themselves
- logged in to an unattended machine in a public computer lab may find
- their script changed to just "discard". In order to protect users in
- this situation (along with similar situations), implementations MAY
- keep messages destroyed by a script for an indefinite period, and MAY
- disallow scripts that throw out all mail.
-
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 25]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-5. Test Commands
-
- Tests are used in conditionals to decide which part(s) of the
- conditional to execute.
-
- Implementations MUST support these tests: "address", "allof",
- "anyof", "exists", "false", "header", "not", "size", and "true".
-
- Implementations SHOULD support the "envelope" test.
-
-5.1. Test address
-
- Usage: address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
- <header-list: string-list> <key-list: string-list>
-
- The "address" test matches Internet addresses in structured headers
- that contain addresses. It returns true if any header contains any
- key in the specified part of the address, as modified by the
- comparator and the match keyword. Whether there are other addresses
- present in the header doesn't affect this test; this test does not
- provide any way to determine whether an address is the only address
- in a header.
-
- Like envelope and header, this test returns true if any combination
- of the header-list and key-list arguments match and returns false
- otherwise.
-
- Internet email addresses [IMAIL] have the somewhat awkward
- characteristic that the local-part to the left of the at-sign is
- considered case sensitive, and the domain-part to the right of the
- at-sign is case insensitive. The "address" command does not deal
- with this itself, but provides the ADDRESS-PART argument for allowing
- users to deal with it.
-
- The address primitive never acts on the phrase part of an email
- address or on comments within that address. It also never acts on
- group names, although it does act on the addresses within the group
- construct.
-
- Implementations MUST restrict the address test to headers that
- contain addresses, but MUST include at least From, To, Cc, Bcc,
- Sender, Resent-From, and Resent-To, and it SHOULD include any other
- header that utilizes an "address-list" structured header body.
-
- Example: if address :is :all "from" "tim at example.com" {
- discard;
- }
-
-
-
-
-Guenther & Showalter Standards Track [Page 26]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-5.2. Test allof
-
- Usage: allof <tests: test-list>
-
- The "allof" test performs a logical AND on the tests supplied to it.
-
- Example: allof (false, false) => false
- allof (false, true) => false
- allof (true, true) => true
-
- The allof test takes as its argument a test-list.
-
-5.3. Test anyof
-
- Usage: anyof <tests: test-list>
-
- The "anyof" test performs a logical OR on the tests supplied to it.
-
- Example: anyof (false, false) => false
- anyof (false, true) => true
- anyof (true, true) => true
-
-5.4. Test envelope
-
- Usage: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
- <envelope-part: string-list> <key-list: string-list>
-
- The "envelope" test is true if the specified part of the [SMTP] (or
- equivalent) envelope matches the specified key. This specification
- defines the interpretation of the (case insensitive) "from" and "to"
- envelope-parts. Additional envelope-parts may be defined by other
- extensions; implementations SHOULD consider unknown envelope parts an
- error.
-
- If one of the envelope-part strings is (case insensitive) "from",
- then matching occurs against the FROM address used in the SMTP MAIL
- command. The null reverse-path is matched against as the empty
- string, regardless of the ADDRESS-PART argument specified.
-
- If one of the envelope-part strings is (case insensitive) "to", then
- matching occurs against the TO address used in the SMTP RCPT command
- that resulted in this message getting delivered to this user. Note
- that only the most recent TO is available, and only the one relevant
- to this user.
-
- The envelope-part is a string list and may contain more than one
- parameter, in which case all of the strings specified in the key-list
- are matched against all parts given in the envelope-part list.
-
-
-
-Guenther & Showalter Standards Track [Page 27]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- Like address and header, this test returns true if any combination of
- the envelope-part list and key-list arguments match and returns false
- otherwise.
-
- All tests against envelopes MUST drop source routes.
-
- If the SMTP transaction involved several RCPT commands, only the data
- from the RCPT command that caused delivery to this user is available
- in the "to" part of the envelope.
-
- If a protocol other than SMTP is used for message transport,
- implementations are expected to adapt this command appropriately.
-
- The envelope command is optional. Implementations SHOULD support it,
- but the necessary information may not be available in all cases. The
- capability string for use with the require command is "envelope".
-
- Example: require "envelope";
- if envelope :all :is "from" "tim at example.com" {
- discard;
- }
-
-5.5. Test exists
-
- Usage: exists <header-names: string-list>
-
- The "exists" test is true if the headers listed in the header-names
- argument exist within the message. All of the headers must exist or
- the test is false.
-
- The following example throws out mail that doesn't have a From header
- and a Date header.
-
- Example: if not exists ["From","Date"] {
- discard;
- }
-
-5.6. Test false
-
- Usage: false
-
- The "false" test always evaluates to false.
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 28]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-5.7. Test header
-
- Usage: header [COMPARATOR] [MATCH-TYPE]
- <header-names: string-list> <key-list: string-list>
-
- The "header" test evaluates to true if the value of any of the named
- headers, ignoring leading and trailing whitespace, matches any key.
- The type of match is specified by the optional match argument, which
- defaults to ":is" if not specified, as specified in section 2.6.
-
- Like address and envelope, this test returns true if any combination
- of the header-names list and key-list arguments match and returns
- false otherwise.
-
- If a header listed in the header-names argument exists, it contains
- the empty key (""). However, if the named header is not present, it
- does not match any key, including the empty key. So if a message
- contained the header
-
- X-Caffeine: C8H10N4O2
-
- these tests on that header evaluate as follows:
-
- header :is ["X-Caffeine"] [""] => false
- header :contains ["X-Caffeine"] [""] => true
-
- Testing whether a given header is either absent or doesn't contain
- any non-whitespace characters can be done using a negated "header"
- test:
-
- not header :matches "Cc" "?*"
-
-5.8. Test not
-
- Usage: not <test1: test>
-
- The "not" test takes some other test as an argument, and yields the
- opposite result. "not false" evaluates to "true" and "not true"
- evaluates to "false".
-
-5.9. Test size
-
- Usage: size <":over" / ":under"> <limit: number>
-
- The "size" test deals with the size of a message. It takes either a
- tagged argument of ":over" or ":under", followed by a number
- representing the size of the message.
-
-
-
-
-Guenther & Showalter Standards Track [Page 29]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- If the argument is ":over", and the size of the message is greater
- than the number provided, the test is true; otherwise, it is false.
-
- If the argument is ":under", and the size of the message is less than
- the number provided, the test is true; otherwise, it is false.
-
- Exactly one of ":over" or ":under" must be specified, and anything
- else is an error.
-
- The size of a message is defined to be the number of octets in the
- [IMAIL] representation of the message.
-
- Note that for a message that is exactly 4,000 octets, the message is
- neither ":over" nor ":under" 4000 octets.
-
-5.10. Test true
-
- Usage: true
-
- The "true" test always evaluates to true.
-
-6. Extensibility
-
- New control commands, actions, and tests can be added to the
- language. Sites must make these features known to their users; this
- document does not define a way to discover the list of extensions
- supported by the server.
-
- Any extensions to this language MUST define a capability string that
- uniquely identifies that extension. Capability string are case-
- sensitive; for example, "foo" and "FOO" are different capabilities.
- If a new version of an extension changes the functionality of a
- previously defined extension, it MUST use a different name.
- Extensions may register a set of related capabilities by registering
- just a unique prefix for them. The "comparator-" prefix is an
- example of this. The prefix MUST end with a "-" and MUST NOT overlap
- any existing registrations.
-
- In a situation where there is a script submission protocol and an
- extension advertisement mechanism aware of the details of this
- language, scripts submitted can be checked against the mail server to
- prevent use of an extension that the server does not support.
-
- Extensions MUST state how they interact with constraints defined in
- section 2.10, e.g., whether they cancel the implicit keep, and which
- actions they are compatible and incompatible with. Extensions MUST
- NOT change the behavior of the "require" control command or alter the
- interpretation of the argument to the "require" control.
-
-
-
-Guenther & Showalter Standards Track [Page 30]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- Extensions that can submit new email messages or otherwise generate
- new protocol requests MUST consider loop suppression, at least to
- document any security considerations.
-
-6.1. Capability String
-
- Capability strings are typically short strings describing what
- capabilities are supported by the server.
-
- Capability strings beginning with "vnd." represent vendor-defined
- extensions. Such extensions are not defined by Internet standards or
- RFCs, but are still registered with IANA in order to prevent
- conflicts. Extensions starting with "vnd." SHOULD be followed by the
- name of the vendor and product, such as "vnd.acme.rocket-sled".
-
- The following capability strings are defined by this document:
-
- encoded-character The string "encoded-character" indicates that the
- implementation supports the interpretation of
- "${hex:...}" and "${unicode:...}" in strings.
-
- envelope The string "envelope" indicates that the implementation
- supports the "envelope" command.
-
- fileinto The string "fileinto" indicates that the implementation
- supports the "fileinto" command.
-
- comparator- The string "comparator-elbonia" is provided if the
- implementation supports the "elbonia" comparator.
- Therefore, all implementations have at least the
- "comparator-i;octet" and "comparator-i;ascii-casemap"
- capabilities. However, these comparators may be used
- without being declared with require.
-
-6.2. IANA Considerations
-
- In order to provide a standard set of extensions, a registry is
- maintained by IANA. This registry contains both vendor-controlled
- capability names (beginning with "vnd.") and IETF-controlled
- capability names. Vendor-controlled capability names may be
- registered on a first-come, first-served basis, by applying to IANA
- with the form in the following section. Registration of capability
- prefixes that do not begin with "vnd." REQUIRES a standards track or
- IESG-approved experimental RFC.
-
- Extensions designed for interoperable use SHOULD use IETF-controlled
- capability names.
-
-
-
-
-Guenther & Showalter Standards Track [Page 31]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-6.2.1. Template for Capability Registrations
-
- The following template is to be used for registering new Sieve
- extensions with IANA.
-
- To: iana at iana.org
- Subject: Registration of new Sieve extension
-
- Capability name: [the string for use in the 'require' statement]
- Description: [a brief description of what the extension adds
- or changes]
- RFC number: [for extensions published as RFCs]
- Contact address: [email and/or physical address to contact for
- additional information]
-
-6.2.2. Handling of Existing Capability Registrations
-
- In order to bring the existing capability registrations in line with
- the new template, IANA has modified each as follows:
-
- 1. The "capability name" and "capability arguments" fields have been
- eliminated
- 2. The "capability keyword" field have been renamed to "Capability
- name"
- 3. An empty "Description" field has been added
- 4. The "Standards Track/IESG-approved experimental RFC number" field
- has been renamed to "RFC number"
- 5. The "Person and email address to contact for further information"
- field should be renamed to "Contact address"
-
-6.2.3. Initial Capability Registrations
-
- This RFC updates the following entries in the IANA registry for Sieve
- extensions.
-
- Capability name: encoded-character
- Description: changes the interpretation of strings to allow
- arbitrary octets and Unicode characters to be
- represented using US-ASCII
- RFC number: RFC 5228 (Sieve base spec)
- Contact address: The Sieve discussion list <ietf-mta-filters at imc.org>
-
- Capability name: fileinto
- Description: adds the 'fileinto' action for delivering to a
- mailbox other than the default
- RFC number: RFC 5228 (Sieve base spec)
- Contact address: The Sieve discussion list <ietf-mta-filters at imc.org>
-
-
-
-
-Guenther & Showalter Standards Track [Page 32]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- Capability name: envelope
- Description: adds the 'envelope' test for testing the message
- transport sender and recipient address
- RFC number: RFC 5228 (Sieve base spec)
- Contact address: The Sieve discussion list <ietf-mta-filters at imc.org>
-
- Capability name: comparator-* (anything starting with "comparator-")
- Description: adds the indicated comparator for use with the
- :comparator argument
- RFC number: RFC 5228 (Sieve base spec) and [COLLATION]
- Contact address: The Sieve discussion list <ietf-mta-filters at imc.org>
-
-6.3. Capability Transport
-
- A method of advertising which capabilities an implementation supports
- is difficult due to the wide range of possible implementations. Such
- a mechanism, however, should have the property that the
- implementation can advertise the complete set of extensions that it
- supports.
-
-7. Transmission
-
- The [MIME] type for a Sieve script is "application/sieve".
-
- The registration of this type for RFC 2048 requirements is updated as
- follows:
-
- Subject: Registration of MIME media type application/sieve
-
- MIME media type name: application
- MIME subtype name: sieve
- Required parameters: none
- Optional parameters: none
- Encoding considerations: Most Sieve scripts will be textual,
- written in UTF-8. When non-7bit characters are used,
- quoted-printable is appropriate for transport systems
- that require 7bit encoding.
- Security considerations: Discussed in section 10 of this RFC.
- Interoperability considerations: Discussed in section 2.10.5
- of this RFC.
- Published specification: this RFC.
- Applications that use this media type: sieve-enabled mail
- servers and clients
- Additional information:
- Magic number(s):
- File extension(s): .siv .sieve
- Macintosh File Type Code(s):
-
-
-
-
-Guenther & Showalter Standards Track [Page 33]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- Person & email address to contact for further information:
- See the discussion list at ietf-mta-filters at imc.org.
- Intended usage:
- COMMON
- Author/Change controller:
- The SIEVE WG, delegated by the IESG.
-
-8. Parsing
-
- The Sieve grammar is separated into tokens and a separate grammar as
- most programming languages are. Additional rules are supplied here
- for common arguments to various language facilities.
-
-8.1. Lexical Tokens
-
- Sieve scripts are encoded in UTF-8. The following assumes a valid
- UTF-8 encoding; special characters in Sieve scripts are all US-ASCII.
-
- The following are tokens in Sieve:
-
- - identifiers
- - tags
- - numbers
- - quoted strings
- - multi-line strings
- - other separators
-
- Identifiers, tags, and numbers are case-insensitive, while quoted
- strings and multi-line strings are case-sensitive.
-
- Blanks, horizontal tabs, CRLFs, and comments ("whitespace") are
- ignored except as they separate tokens. Some whitespace is required
- to separate otherwise adjacent tokens and in specific places in the
- multi-line strings. CR and LF can only appear in CRLF pairs.
-
- The other separators are single individual characters and are
- mentioned explicitly in the grammar.
-
- The lexical structure of sieve is defined in the following grammar
- (as described in [ABNF]):
-
- bracket-comment = "/*" *not-star 1*STAR
- *(not-star-slash *not-star 1*STAR) "/"
- ; No */ allowed inside a comment.
- ; (No * is allowed unless it is the last
- ; character, or unless it is followed by a
- ; character that isn't a slash.)
-
-
-
-
-Guenther & Showalter Standards Track [Page 34]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- comment = bracket-comment / hash-comment
-
- hash-comment = "#" *octet-not-crlf CRLF
-
- identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_")
-
- multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
- *(multiline-literal / multiline-dotstart)
- "." CRLF
-
- multiline-literal = [ octet-not-period *octet-not-crlf ] CRLF
-
- multiline-dotstart = "." 1*octet-not-crlf CRLF
- ; A line containing only "." ends the
- ; multi-line. Remove a leading '.' if
- ; followed by another '.'.
-
- not-star = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-FF
- ; either a CRLF pair, OR a single octet
- ; other than NUL, CR, LF, or star
-
- not-star-slash = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-2E /
- %x30-FF
- ; either a CRLF pair, OR a single octet
- ; other than NUL, CR, LF, star, or slash
-
- number = 1*DIGIT [ QUANTIFIER ]
-
- octet-not-crlf = %x01-09 / %x0B-0C / %x0E-FF
- ; a single octet other than NUL, CR, or LF
-
- octet-not-period = %x01-09 / %x0B-0C / %x0E-2D / %x2F-FF
- ; a single octet other than NUL,
- ; CR, LF, or period
-
- octet-not-qspecial = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / %x5D-FF
- ; a single octet other than NUL,
- ; CR, LF, double-quote, or backslash
-
- QUANTIFIER = "K" / "M" / "G"
-
- quoted-other = "\" octet-not-qspecial
- ; represents just the octet-no-qspecial
- ; character. SHOULD NOT be used
-
- quoted-safe = CRLF / octet-not-qspecial
- ; either a CRLF pair, OR a single octet other
- ; than NUL, CR, LF, double-quote, or backslash
-
-
-
-Guenther & Showalter Standards Track [Page 35]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- quoted-special = "\" (DQUOTE / "\")
- ; represents just a double-quote or backslash
-
- quoted-string = DQUOTE quoted-text DQUOTE
-
- quoted-text = *(quoted-safe / quoted-special / quoted-other)
-
- STAR = "*"
-
- tag = ":" identifier
-
- white-space = 1*(SP / CRLF / HTAB) / comment
-
-8.2. Grammar
-
- The following is the grammar of Sieve after it has been lexically
- interpreted. No whitespace or comments appear below. The start
- symbol is "start".
-
- argument = string-list / number / tag
-
- arguments = *argument [ test / test-list ]
-
- block = "{" commands "}"
-
- command = identifier arguments (";" / block)
-
- commands = *command
-
- start = commands
-
- string = quoted-string / multi-line
-
- string-list = "[" string *("," string) "]" / string
- ; if there is only a single string, the brackets
- ; are optional
-
- test = identifier arguments
-
- test-list = "(" test *("," test) ")"
-
-8.3. Statement Elements
-
- These elements are collected from the "Syntax" sections elsewhere in
- this document, and are provided here in [ABNF] syntax so that they
- can be modified by extensions.
-
- ADDRESS-PART = ":localpart" / ":domain" / ":all"
-
-
-
-Guenther & Showalter Standards Track [Page 36]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- COMPARATOR = ":comparator" string
-
- MATCH-TYPE = ":is" / ":contains" / ":matches"
-
-9. Extended Example
-
- The following is an extended example of a Sieve script. Note that it
- does not make use of the implicit keep.
-
- #
- # Example Sieve Filter
- # Declare any optional features or extension used by the script
- #
- require ["fileinto"];
-
- #
- # Handle messages from known mailing lists
- # Move messages from IETF filter discussion list to filter mailbox
- #
- if header :is "Sender" "owner-ietf-mta-filters at imc.org"
- {
- fileinto "filter"; # move to "filter" mailbox
- }
- #
- # Keep all messages to or from people in my company
- #
- elsif address :DOMAIN :is ["From", "To"] "example.com"
- {
- keep; # keep in "In" mailbox
- }
-
- #
- # Try and catch unsolicited email. If a message is not to me,
- # or it contains a subject known to be spam, file it away.
- #
- elsif anyof (NOT address :all :contains
- ["To", "Cc", "Bcc"] "me at example.com",
- header :matches "subject"
- ["*make*money*fast*", "*university*dipl*mas*"])
- {
- fileinto "spam"; # move to "spam" mailbox
- }
- else
- {
- # Move all other (non-company) mail to "personal"
- # mailbox.
- fileinto "personal";
- }
-
-
-
-Guenther & Showalter Standards Track [Page 37]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-10. Security Considerations
-
- Users must get their mail. It is imperative that whatever
- implementations use to store the user-defined filtering scripts
- protect them from unauthorized modification, to preserve the
- integrity of the mail system. An attacker who can modify a script
- can cause mail to be discarded, rejected, or forwarded to an
- unauthorized recipient. In addition, it's possible that Sieve
- scripts might expose private information, such as mailbox names, or
- email addresses of favored (or disfavored) correspondents. Because
- of that, scripts SHOULD also be protected from unauthorized
- retrieval.
-
- Several commands, such as "discard", "redirect", and "fileinto",
- allow for actions to be taken that are potentially very dangerous.
-
- Use of the "redirect" command to generate notifications may easily
- overwhelm the target address, especially if it was not designed to
- handle large messages.
-
- Allowing a single script to redirect to multiple destinations can be
- used as a means of amplifying the number of messages in an attack.
- Moreover, if loop detection is not properly implemented, it may be
- possible to set up exponentially growing message loops. Accordingly,
- Sieve implementations:
-
- (1) MUST implement facilities to detect and break message loops. See
- section 6.2 of [SMTP] for additional information on basic loop
- detection strategies.
-
- (2) MUST provide the means for administrators to limit the ability of
- users to abuse redirect. In particular, it MUST be possible to
- limit the number of redirects a script can perform.
- Additionally, if no use cases exist for using redirect to
- multiple destinations, this limit SHOULD be set to 1. Additional
- limits, such as the ability to restrict redirect to local users,
- MAY also be implemented.
-
- (3) MUST provide facilities to log use of redirect in order to
- facilitate tracking down abuse.
-
- (4) MAY use script analysis to determine whether or not a given
- script can be executed safely. While the Sieve language is
- sufficiently complex that full analysis of all possible scripts
- is computationally infeasible, the majority of real-world scripts
- are amenable to analysis. For example, an implementation might
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 38]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- allow scripts that it has determined are safe to run unhindered,
- block scripts that are potentially problematic, and subject
- unclassifiable scripts to additional auditing and logging.
-
- Allowing redirects at all may not be appropriate in situations where
- email accounts are freely available and/or not trackable to a human
- who can be held accountable for creating message bombs or other
- abuse.
-
- As with any filter on a message stream, if the Sieve implementation
- and the mail agents 'behind' Sieve in the message stream differ in
- their interpretation of the messages, it may be possible for an
- attacker to subvert the filter. Of particular note are differences
- in the interpretation of malformed messages (e.g., missing or extra
- syntax characters) or those that exhibit corner cases (e.g., NUL
- octets encoded via [MIME3]).
-
-11. Acknowledgments
-
- This document has been revised in part based on comments and
- discussions that took place on and off the SIEVE mailing list.
- Thanks to Sharon Chisholm, Cyrus Daboo, Ned Freed, Arnt Gulbrandsen,
- Michael Haardt, Kjetil Torgrim Homme, Barry Leiba, Mark E. Mallett,
- Alexey Melnikov, Eric Rescorla, Rob Siemborski, and Nigel Swinson for
- reviews and suggestions.
-
-12. Normative References
-
- [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 4234, October 2005.
-
- [COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
- Application Protocol Collation Registry", RFC 4790, March
- 2007.
-
- [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822,
- April 2001.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
- [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
- Part Three: Message Header Extensions for Non-ASCII
- Text", RFC 2047, November 1996.
-
-
-
-Guenther & Showalter Standards Track [Page 39]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
- [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
- 2821, April 2001.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
-
-13. Informative References
-
- [BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in
- electrical technology - Part 2: Telecommunications and
- electronics", January 1999.
-
- [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
- for Delivery Status Notifications", RFC 3464, January
- 2003.
-
- [FLAMES] Borenstein, N, and C. Thyberg, "Power, Ease of Use, and
- Cooperative Work in a Practical Multimedia Message
- System", Int. J. of Man-Machine Studies, April, 1991.
- Reprinted in Computer-Supported Cooperative Work and
- Groupware, Saul Greenberg, editor, Harcourt Brace
- Jovanovich, 1991. Reprinted in Readings in Groupware and
- Computer-Supported Cooperative Work, Ronald Baecker,
- editor, Morgan Kaufmann, 1993.
-
- [IMAP] Crispin, M., "Internet Message Access Protocol - version
- 4rev1", RFC 3501, March 2003.
-
- [MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message
- Disposition Notification", RFC 3798, May 2004.
-
- [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC
- 3028, January 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 40]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-14. Changes from RFC 3028
-
- This following list is a summary of the changes that have been made
- in the Sieve language base specification from [RFC3028].
-
- 1. Removed ban on tests having side-effects
- 2. Removed reject extension (will be specified in a separate RFC)
- 3. Clarified description of comparators to match [COLLATION], the
- new base specification for them
- 4. Require stripping of leading and trailing whitespace in "header"
- test
- 5. Clarified or tightened handling of many minor items, including:
- - invalid [MIME3] encoding
- - invalid addresses in headers
- - invalid header field names in tests
- - 'undefined' comparator result
- - unknown envelope parts
- - null return-path in "envelope" test
- 6. Capability strings are case-sensitive
- 7. Clarified that fileinto should reencode non-ASCII mailbox
- names to match the mailstore's conventions
- 8. Errors in the ABNF were corrected
- 9. The references were updated and split into normative and
- informative
- 10. Added encoded-character capability and deprecated (but did not
- remove) use of arbitrary binary octets in Sieve scripts.
- 11. Updated IANA registration template, and added IANA
- considerations to permit capability prefix registrations.
- 12. Added .sieve as a valid extension for Sieve scripts.
-
-Editors' Addresses
-
- Philip Guenther
- Sendmail, Inc.
- 6425 Christie St. Ste 400
- Emeryville, CA 94608
- EMail: guenther at sendmail.com
-
- Tim Showalter
- EMail: tjs at psaux.com
-
-
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 41]
-
-RFC 5228 Sieve: An Email Filtering Language January 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr at ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Guenther & Showalter Standards Track [Page 42]
-
diff --git a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5229/rfc5229.txt b/chrome/chromeFiles/content/libs/libSieveDOM/RFC5229/rfc5229.txt
deleted file mode 100644
index 4468ba1..0000000
--- a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5229/rfc5229.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Homme
-Request for Comments: 5229 University of Oslo
-Updates: 5228 January 2008
-Category: Standards Track
-
-
- Sieve Email Filtering: Variables Extension
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- In advanced mail filtering rule sets, it is useful to keep state or
- configuration details across rules. This document updates the Sieve
- filtering language (RFC 5228) with an extension to support variables.
- The extension changes the interpretation of strings, adds an action
- to store data in variables, and supplies a new test so that the value
- of a string can be examined.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Homme Standards Track [Page 1]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
-1. Introduction
-
- This is an extension to the Sieve language defined by [SIEVE]. It
- adds support for storing and referencing named data. The mechanisms
- detailed in this document will only apply to Sieve scripts that
- include a require clause for the "variables" extension. The require
- clauses themselves are not affected by this extension.
-
- Conventions for notations are as in [SIEVE] section 1.1, including
- use of [KEYWORDS] and [ABNF]. The grammar builds on the grammar of
- [SIEVE]. In this document, "character" means a character from the
- ISO 10646 coded character set [ISO10646], which may consist of
- multiple octets coded in [UTF-8], and "variable" is a named reference
- to data stored or read back using the mechanisms of this extension.
-
-2. Capability Identifier
-
- The capability string associated with the extension defined in this
- document is "variables".
-
-3. Interpretation of Strings
-
- This extension changes the semantics of quoted-string, multi-line-
- literal and multi-line-dotstuff found in [SIEVE] to enable the
- inclusion of the value of variables.
-
- When a string is evaluated, substrings matching variable-ref SHALL be
- replaced by the value of variable-name. Only one pass through the
- string SHALL be done. Variable names are case insensitive, so "foo"
- and "FOO" refer to the same variable. Unknown variables are replaced
- by the empty string.
-
- variable-ref = "${" [namespace] variable-name "}"
- namespace = identifier "." *sub-namespace
- sub-namespace = variable-name "."
- variable-name = num-variable / identifier
- num-variable = 1*DIGIT
-
- Examples:
- "&%${}!" => unchanged, as the empty string is an illegal
- identifier
- "${doh!}" => unchanged, as "!" is illegal in identifiers
-
- The variable "company" holds the value "ACME". No other variables
- are set.
-
- "${full}" => the empty string
- "${company}" => "ACME"
-
-
-
-Homme Standards Track [Page 2]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
- "${BAD${Company}" => "${BADACME"
- "${President, ${Company} Inc.}"
- => "${President, ACME Inc.}"
-
- The expanded string MUST use the variable values that are current
- when control reaches the statement the string is part of.
-
- Strings where no variable substitutions take place are referred to as
- constant strings. Future extensions may specify that passing non-
- constant strings as arguments to its actions or tests is an error.
-
- Namespaces are meant for future extensions that make internal state
- available through variables. These variables SHOULD be put in a
- namespace whose first component is the same as its capability string.
- Such extensions SHOULD state which, if any, of the variables in its
- namespace are modifiable with the "set" action.
-
- References to namespaces without a prior require statement for the
- relevant extension MUST cause an error.
-
- Tests or actions in future extensions may need to access the
- unexpanded version of the string argument and, e.g., do the expansion
- after setting variables in its namespace. The design of the
- implementation should allow this.
-
-3.1. Quoting and Encoded Characters
-
- The semantics of quoting using backslash are not changed: backslash
- quoting is resolved before doing variable substitution. Similarly,
- encoded character processing (see Section 2.4.2.4 of [SIEVE]) is
- performed before doing variable substitution, but after quoting.
-
- Examples:
- "${fo\o}" => ${foo} => the expansion of variable foo.
- "${fo\\o}" => ${fo\o} => illegal identifier => left verbatim.
- "\${foo}" => ${foo} => the expansion of variable foo.
- "\\${foo}" => \${foo} => a backslash character followed by the
- expansion of variable foo.
-
- If it is required to include a character sequence such as
- "${beep}" verbatim in a text literal, the user can define a
- variable to circumvent expansion to the empty string.
-
- Example:
- set "dollar" "$";
- set "text" "regarding ${dollar}{beep}";
-
-
-
-
-
-Homme Standards Track [Page 3]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
- Example:
- require ["encoded-character", "variables"];
- set "name" "Ethelbert"
- if header :contains "Subject" "dear${hex:20 24 7b 4e}ame}" {
- # the test string is "dear Ethelbert"
- }
-
-3.2. Match Variables
-
- A "match variable" has a name consisting only of decimal digits and
- has no namespace component.
-
- The decimal value of the match variable name will index the list of
- matching strings from the most recently evaluated successful match of
- type ":matches". The list is empty if no match has been successful.
-
- Note: Extra leading zeroes are allowed and ignored.
-
- The list will contain one string for each wildcard ("?" and "*") in
- the match pattern. Each string holds the substring from the source
- value that the corresponding wildcard expands to, possibly the empty
- string. The wildcards match as little as possible (non-greedy
- matching).
-
- The first string in the list has index 1. If the index is out of
- range, the empty string will be substituted. Index 0 contains the
- matched part of the source value.
-
- The interpreter MUST short-circuit tests, i.e., not perform more
- tests than necessary to find the result. Evaluation order MUST be
- left to right. If a test has two or more list arguments, the
- implementation is free to choose which to iterate over first.
-
- An extension describing a new match type (e.g., [REGEX]) MAY specify
- that match variables are set as a side effect when the match type is
- used in a script that has enabled the "variables" extension.
-
- Example:
-
- require ["fileinto", "variables"];
-
- if header :matches "List-ID" "*<*@*" {
- fileinto "INBOX.lists.${2}"; stop;
- }
-
-
-
-
-
-
-
-Homme Standards Track [Page 4]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
- # Imagine the header
- # Subject: [acme-users] [fwd] version 1.0 is out
- if header :matches "Subject" "[*] *" {
- # ${1} will hold "acme-users",
- # ${2} will hold "[fwd] version 1.0 is out"
- fileinfo "INBOX.lists.${1}"; stop;
- }
-
- # Imagine the header
- # To: coyote at ACME.Example.COM
- if address :matches ["To", "Cc"] ["coyote@**.com",
- "wile@**.com"] {
- # ${0} is the matching address
- # ${1} is always the empty string
- # ${2} is part of the domain name ("ACME.Example")
- fileinto "INBOX.business.${2}"; stop;
- } else {
- # Control wouldn't reach this block if any match was
- # successful, so no match variables are set at this
- # point.
- }
-
- if anyof (true, address :domain :matches "To" "*.com") {
- # The second test is never evaluated, so there are
- # still no match variables set.
- stop;
- }
-
-4. Action set
-
- Usage: set [MODIFIER] <name: string> <value: string>
-
- The "set" action stores the specified value in the variable
- identified by name. The name MUST be a constant string and conform
- to the syntax of variable-name. Match variables cannot be set. A
- namespace cannot be used unless an extension explicitly allows its
- use in "set". An invalid name MUST be detected as a syntax error.
-
- Modifiers are applied on a value before it is stored in the variable.
- See the next section for details.
-
- Variables are only visible to the currently running script. Note:
- Future extensions may provide different scoping rules for variables.
-
- Variable names are case insensitive.
-
-
-
-
-
-
-Homme Standards Track [Page 5]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
- Example:
- set "honorific" "Mr";
- set "first_name" "Wile";
- set "last_name" "Coyote";
- set "vacation" text:
- Dear ${HONORIFIC} ${last_name},
- I'm out, please leave a message after the meep.
- .
- ;
-
- "set" does not affect the implicit keep. It is compatible with all
- actions defined in [SIEVE].
-
-4.1. Modifiers
-
- Usage: ":lower" / ":upper" / ":lowerfirst" / ":upperfirst" /
- ":quotewildcard" / ":length"
-
- Modifier names are case insensitive. Unknown modifiers MUST yield a
- syntax error. More than one modifier can be specified, in which case
- they are applied according to this precedence list, largest value
- first:
-
- +--------------------------------+
- | Precedence Modifier |
- +--------------------------------+
- | 40 :lower |
- | :upper |
- +--------------------------------+
- | 30 :lowerfirst |
- | :upperfirst |
- +--------------------------------+
- | 20 :quotewildcard |
- +--------------------------------+
- | 10 :length |
- +--------------------------------+
-
- It is an error to use two or more modifiers of the same precedence in
- a single "set" action.
-
- Examples:
- # The value assigned to the variable is printed after the arrow
- set "a" "juMBlEd lETteRS"; => "juMBlEd lETteRS"
- set :length "b" "${a}"; => "15"
- set :lower "b" "${a}"; => "jumbled letters"
- set :upperfirst "b" "${a}"; => "JuMBlEd lETteRS"
- set :upperfirst :lower "b" "${a}"; => "Jumbled letters"
- set :quotewildcard "b" "Rock*"; => "Rock\*"
-
-
-
-Homme Standards Track [Page 6]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
-4.1.1. Modifier ":length"
-
- The value is the decimal number of characters in the expansion,
- converted to a string.
-
-4.1.2. Modifier ":quotewildcard"
-
- This modifier adds the necessary quoting to ensure that the expanded
- text will only match a literal occurrence if used as a parameter to
- :matches. Every character with special meaning ("*", "?", and "\")
- is prefixed with "\" in the expansion.
-
-4.1.3. Case Modifiers
-
- These modifiers change the letters of the text from upper to lower
- case or vice versa. Characters other than "A"-"Z" and "a"-"z" from
- US-ASCII are left unchanged.
-
-4.1.3.1. Modifier ":upper"
-
- All lower case letters are converted to their upper case
- counterparts.
-
-4.1.3.2. Modifier ":lower"
-
- All upper case letters are converted to their lower case
- counterparts.
-
-4.1.3.3. Modifier ":upperfirst"
-
- The first character of the string is converted to upper case if it is
- a letter and set in lower case. The rest of the string is left
- unchanged.
-
-4.1.3.4. Modifier ":lowerfirst"
-
- The first character of the string is converted to lower case if it is
- a letter and set in upper case. The rest of the string is left
- unchanged.
-
-5. Test string
-
- Usage: string [MATCH-TYPE] [COMPARATOR]
- <source: string-list> <key-list: string-list>
-
- The "string" test evaluates to true if any of the source strings
- matches any key. The type of match defaults to ":is".
-
-
-
-
-Homme Standards Track [Page 7]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
- In the "string" test, both source and key-list are taken from the
- script, not the message, and whitespace stripping MUST NOT be done
- unless the script explicitly requests this through some future
- mechanism.
-
- Example:
- set "state" "${state} pending";
- if string :matches " ${state} " "* pending *" {
- # the above test always succeeds
- }
-
- The "relational" extension [RELATIONAL] adds a match type called
- ":count". The count of a single string is 0 if it is the empty
- string, or 1 otherwise. The count of a string list is the sum of the
- counts of the member strings.
-
-6. Implementation Limits
-
- An implementation of this document MUST support at least 128 distinct
- variables. The supported length of variable names MUST be at least
- 32 characters. Each variable MUST be able to hold at least 4000
- characters. Attempts to set the variable to a value larger than what
- the implementation supports SHOULD be reported as an error at
- compile-time if possible. If the attempt is discovered during run-
- time, the value SHOULD be truncated, and it MUST NOT be treated as an
- error.
-
- Match variables ${1} through ${9} MUST be supported. References to
- higher indices than those the implementation supports MUST be treated
- as a syntax error, which SHOULD be discovered at compile-time.
-
-7. Security Considerations
-
- When match variables are used, and the author of the script isn't
- careful, strings can contain arbitrary values controlled by the
- sender of the mail.
-
- Since values stored by "set" that exceed implementation limits are
- silently truncated, it's not appropriate to store large structures
- with security implications in variables.
-
- The introduction of variables makes advanced decision making easier
- to write, but since no looping construct is provided, all Sieve
- scripts will terminate in an orderly manner.
-
- Sieve filtering should not be relied on as a security measure against
- hostile mail messages. Sieve is designed to do simple, mostly static
- tests, and is not suitable for use as a spam or virus checker, where
-
-
-
-Homme Standards Track [Page 8]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
- the perpetrator has a motivation to vary the format of the mail in
- order to avoid filtering rules. See also [SPAMTEST].
-
-8. IANA Considerations
-
- The following template specifies the IANA registration of the
- variables Sieve extension specified in this document:
-
- To: iana at iana.org
- Subject: Registration of new Sieve extension
-
- Capability name: variables
- Description: Adds support for variables to the Sieve filtering
- language.
- RFC number: RFC 5229
- Contact address: The Sieve discussion list <ietf-mta-filters at imc.org>
-
-9. Acknowledgments
-
- Thanks to Cyrus Daboo, Jutta Degener, Ned Freed, Lawrence Greenfield,
- Jeffrey Hutzelman, Mark E. Mallett, Alexey Melnikov, Peder Stray, and
- Nigel Swinson for valuable feedback.
-
-10. References
-
-10.1. Normative References
-
- [ABNF] Crocker, D., Ed., and Overell, P., "Augmented BNF for
- Syntax Specifications: ABNF", RFC 4234, October 2005.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RELATIONAL] Segmuller, W. and B. Leiba, "Sieve Email Filtering:
- Relational Extension", RFC 5231, January 2008.
-
- [SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An
- Email Filtering Language", RFC 5228, January 2008.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode
- and ISO 10646", RFC 3629, November 2003.
-
-10.2. Informative References
-
- [ISO10646] ISO/IEC, "Information Technology - Universal Multiple-
- Octet Coded Character Set (UCS) - Part 1: Architecture
- and Basic Multilingual Plane", May 1993, with
- amendments.
-
-
-
-Homme Standards Track [Page 9]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
- [REGEX] Murchison, K., "Sieve Email Filtering -- Regular
- Expression Extension", Work in Progress, February 2006.
-
- [SPAMTEST] Daboo, C., "Sieve Email Filtering: Spamtest and
- Virustest Extensions", RFC 5235, January 2008.
-
-Author's Address
-
- Kjetil T. Homme
- University of Oslo
- PO Box 1080
- 0316 Oslo, Norway
-
- Phone: +47 9366 0091
- EMail: kjetilho at ifi.uio.no
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Homme Standards Track [Page 10]
-
-RFC 5229 Sieve: Variables Extension January 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr at ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Homme Standards Track [Page 11]
-
diff --git a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5230/rfc5230.txt b/chrome/chromeFiles/content/libs/libSieveDOM/RFC5230/rfc5230.txt
deleted file mode 100644
index 8bbdc48..0000000
--- a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5230/rfc5230.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group T. Showalter
-Request for Comments: 5230
-Category: Standards Track N. Freed, Ed.
- Sun Microsystems
- January 2008
-
-
- Sieve Email Filtering: Vacation Extension
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document describes an extension to the Sieve email filtering
- language for an autoresponder similar to that of the Unix "vacation"
- command for replying to messages. Various safety features are
- included to prevent problems such as message loops.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 1]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
- 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3
- 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 3
- 4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 3
- 4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 4
- 4.3. Subject and From Parameters . . . . . . . . . . . . . . . 6
- 4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6
- 4.5. Address Parameter and Limiting Replies to Personal
- Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.6. Restricting Replies to Automated Processes and Mailing
- Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 8
- 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 5. Response Message Generation . . . . . . . . . . . . . . . . . 9
- 5.1. SMTP MAIL FROM Address . . . . . . . . . . . . . . . . . . 9
- 5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.6. Auto-Submitted . . . . . . . . . . . . . . . . . . . . . . 10
- 5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 10
- 6. Relationship to Recommendations for Automatic Responses to
- Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11
- 7. Internationalization Considerations . . . . . . . . . . . . . 11
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
- Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 2]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
-1. Introduction
-
- This document defines an extension to the Sieve language defined in
- [RFC5228] for notification that messages to a particular recipient
- will not be answered immediately.
-
-2. Conventions Used in This Document
-
- Conventions for notations are as in [RFC5228] section 1.1.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED",
- and "MAY" in this document are to be interpreted as defined in
- [RFC2119].
-
-3. Capability Identifier
-
- Sieve implementations that implement vacation have an identifier of
- "vacation" for use with the capability mechanism.
-
-4. Vacation Action
-
- Usage: vacation [":days" number] [":subject" string]
- [":from" string] [":addresses" string-list]
- [":mime"] [":handle" string] <reason: string>
-
- The "vacation" action implements a vacation autoresponder similar to
- the vacation command available under many versions of Unix. Its
- purpose is to provide correspondents with notification that the user
- is away for an extended period of time and that they should not
- expect quick responses.
-
- "Vacation" is used to respond to a message with another message.
- Vacation's messages are always addressed to the Return-Path address
- (that is, the envelope from address) of the message being responded
- to.
-
-4.1. Days Parameter
-
- The ":days" argument is used to specify the period in which addresses
- are kept and are not responded to, and is always specified in days.
- The minimum value used for this parameter is normally 1. Sites MAY
- define a different minimum value as long as the minimum is greater
- than 0. Sites MAY also define a maximum days value, which MUST be
- greater than 7, and SHOULD be greater than 30.
-
- If ":days" is omitted, the default value is either 7 or the minimum
- value (as defined above), whichever is greater.
-
-
-
-
-Showalter & Freed Standards Track [Page 3]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
- If the parameter given to ":days" is less than the minimum value,
- then the minimum value is used instead.
-
- If ":days" exceeds the site-defined maximum, the site-defined maximum
- is used instead.
-
-4.2. Previous Response Tracking
-
- "Vacation" keeps track of all the responses it has sent to each
- address in some period (as specified by the :days optional argument).
- If vacation has not previously sent the response to this address
- within the given time period, it sends the "reason" argument to the
- SMTP MAIL FROM address [RFC2821] of the message that is being
- responded to. (The SMTP MAIL FROM address should be available in the
- Return-path: header field if Sieve processing occurs after final
- delivery.)
-
- Tracking is not just per address, but must also take the vacation
- response itself into account. A script writer might, for example,
- have a vacation action that will send a general notice only once in
- any two-week period. However, even if a sender has received this
- general notice, it may be important to send a specific notice when a
- message about something timely or something specific has been
- detected.
-
- A particular vacation response can be identified in one of two ways.
- The first way is via an explicit :handle argument, which attaches a
- name to the response. All vacation statements that use the same
- handle will be considered the same response for tracking purposes.
-
- The second way is via a synthesis of the :subject, :from, :mime, and
- reason vacation command arguments. All vacation actions that do not
- contain an explicit handle and that use an identical combination of
- these arguments are considered the same for tracking purposes.
-
- For instance, if coyote at desert.example.org sends mail to
- roadrunner at acme.example.com twice, once with the subject "Cyrus bug"
- and once with the subject "come over for dinner", and
- roadrunner at acme.example.com has the script shown below,
- coyote at desert.example.org would receive two responses, one with the
- first message, one with the second.
-
- require "vacation";
- if header :contains "subject" "cyrus" {
- vacation "I'm out -- send mail to cyrus-bugs";
- } else {
- vacation "I'm out -- call me at +1 304 555 0123";
- }
-
-
-
-Showalter & Freed Standards Track [Page 4]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
- In the above example, coyote at desert.example.org gets the second
- message despite having gotten the first one because separate vacation
- responses have been triggered. This behavior is REQUIRED.
-
- There is one important exception to this rule, however. If the Sieve
- variables extension [RFC5229] is used, the arguments MUST NOT have
- undergone variable expansion prior to their use in response tracking.
- This is so that examples like the following script will only generate
- a single response to each incoming message with a different subject
- line.
-
- require ["vacation", "variables"];
- if header :matches "subject" "*" {
- vacation :subject "Automatic response to: ${1}"
- "I'm away -- send mail to foo in my absence";
- }
-
- As noted above, the optional ":handle" parameter can be used to tell
- the Sieve interpreter to treat two vacation actions with different
- arguments as the same command for purposes of response tracking. The
- argument to ":handle" is a string that identifies the type of
- response being sent. For instance, if tweety at cage.example.org sends
- mail to spike at doghouse.example.com twice, one with the subject
- "lunch?" and once with the subject "dinner?", and
- spike at doghouse.example.com has the script shown below,
- tweety at cage.example.org will only receive a single response. (Which
- response is sent depends on the order in which the messages are
- processed.)
-
- require "vacation";
- if header :contains "subject" "lunch" {
- vacation :handle "ran-away" "I'm out and can't meet for lunch";
- } else {
- vacation :handle "ran-away" "I'm out";
- }
-
- NOTE: One way to implement the necessary mechanism here is to store a
- hash of either the current handle and the recipient address or, if no
- handle is provided, a hash of the vacation action parameters
- specifying the message content and the recipient address. If a
- script is changed, implementations MAY reset the records of who has
- been responded to and when they have been responded to.
-
- IMPLEMENTATION NOTE: Care must be taken in constructing a hash of
- vacation action parameters. In particular, since most parameters are
- optional, it is important not to let the same string used as the
- value for different parameters produce the same hash value. One
-
-
-
-
-Showalter & Freed Standards Track [Page 5]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
- possible way to accomplish this is to apply the hash to a series of
- counted or null terminated strings, one for each possible parameter
- in particular order.
-
- Implementations are free to limit the number of remembered responses;
- however, the limit MUST NOT be less than 1000. When limiting the
- number of tracked responses, implementations SHOULD discard the
- oldest ones first.
-
-4.3. Subject and From Parameters
-
- The ":subject" parameter specifies a subject line to attach to any
- vacation response that is generated. UTF-8 characters can be used in
- the string argument; implementations MUST convert the string to
- [RFC2047] encoded words if and only if non-ASCII characters are
- present. Implementations MUST generate an appropriate default
- subject line as specified below if no :subject parameter is
- specified.
-
- A ":from" parameter may be used to specify an alternate address to
- use in the From field of vacation messages. The string must specify
- a valid [RFC2822] mailbox-list. Implementations SHOULD check the
- syntax and generate an error when a syntactically invalid ":from"
- parameter is specified. Implementations MAY also impose restrictions
- on what addresses can specified in a ":from" parameter; it is
- suggested that values that fail such a validity check simply be
- ignored rather than cause the vacation action to fail.
-
-4.4. MIME Parameter
-
- The ":mime" parameter, if supplied, specifies that the reason string
- is, in fact, a MIME entity as defined in [RFC2045] section 2.4,
- including both MIME headers and content.
-
- If the optional :mime parameter is not supplied, the reason string is
- considered a UTF-8 string.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 6]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
- require "vacation";
- vacation :mime text:
- Content-Type: multipart/alternative; boundary=foo
-
- --foo
-
- I'm at the beach relaxing. Mmmm, surf...
-
- --foo
- Content-Type: text/html; charset=us-ascii
-
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
- "http://www.w3.org/TR/REC-html40/strict.dtd">
- <HTML><HEAD><TITLE>How to relax</TITLE>
- <BASE HREF="http://home.example.com/pictures/"></HEAD>
- <BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
- Mmmm, <A HREF="ocean.gif">surf</A>...
- </BODY></HTML>
-
- --foo--
- .
-
-4.5. Address Parameter and Limiting Replies to Personal Messages
-
- "Vacation" MUST NOT respond to a message unless the recipient user's
- email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
- "Resent-Bcc" line of the original message. An email address is
- considered to belong to the recipient if it is one of:
-
- 1. an email address known by the implementation to be associated
- with the recipient,
-
- 2. the final envelope recipient address if it's available to the
- implementation, or
-
- 3. an address specified by the script writer via the ":addresses"
- argument described in the next paragraph.
-
- Users can supply additional mail addresses that are theirs with the
- ":addresses" argument, which takes a string-list listing additional
- addresses that a user might have. These addresses are considered to
- belong to the recipient user in addition to the addresses known to
- the implementation.
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 7]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
-4.6. Restricting Replies to Automated Processes and Mailing Lists
-
- Implementations MAY refuse to send a vacation response to a message
- that contains any header or content that makes it appear that a
- response would not be appropriate.
-
- Implementations MUST have a list of addresses that "vacation" MUST
- NOT send mail to. However, the contents of this list are
- implementation defined. The purpose of this list is to stop mail
- from going to addresses used by system daemons that would not care if
- the user is actually reading her mail.
-
- Implementations are encouraged, however, to include well-known
- addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
- addresses typically used only by automated systems. Additionally,
- addresses ending in "-request" or beginning in "owner-", i.e.,
- reserved for mailing list software, are also suggested.
-
- Implementors may take guidance from [RFC2142], but should be careful.
- Some addresses, like "POSTMASTER", are generally actually managed by
- people, and people do care if the user is going to be unavailable.
-
- Implementations SHOULD NOT respond to any message that contains a
- "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List-
- Unsubscribe", "List-Post", "List-Owner", or "List-Archive" [RFC2369]
- header field.
-
- Implementations SHOULD NOT respond to any message that has an "Auto-
- submitted" header field with a value other than "no". This header
- field is described in [RFC3834].
-
-4.7. Interaction with Other Sieve Actions
-
- Vacation does not affect Sieve's implicit keep action.
-
- Vacation can only be executed once per script. A script MUST fail
- with an appropriate error if it attempts to execute two or more
- vacation actions.
-
- Implementations MUST NOT consider vacation used with discard, keep,
- fileinto, or redirect an error. The vacation action is incompatible
- with the Sieve reject and refuse actions [REJECT].
-
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 8]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
-4.8. Examples
-
- Here is a simple use of vacation.
-
- require "vacation";
- vacation :days 23 :addresses ["tjs at example.edu",
- "ts4z at landru.example.edu"]
- "I'm away until October 19.
- If it's an emergency, call 911, I guess." ;
-
- By mingling vacation with other rules, users can do something more
- selective.
-
- require "vacation";
- if header :contains "from" "boss at example.edu" {
- redirect "pleeb at isp.example.org";
- } else {
- vacation "Sorry, I'm away, I'll read your
- message when I get around to it.";
- }
-
-5. Response Message Generation
-
- This section details the requirements for the generated response
- message.
-
- It is worth noting that the input message and arguments may be in
- UTF-8, and that implementations MUST deal with UTF-8 input, although
- implementations MAY transcode to other character sets as regional
- taste dictates. When :mime is used, the reason argument also
- contains MIME header information. The headers must conform to MIME
- conventions; in particular, 8bit text is not allowed.
- Implementations SHOULD reject vacation :mime actions containing 8bit
- header material.
-
-5.1. SMTP MAIL FROM Address
-
- The SMTP MAIL FROM address of the message envelope SHOULD be set to
- <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the
- SMTP transaction if the NOTARY SMTP extension [RFC3461] is available.
-
-5.2. Date
-
- The Date field SHOULD be set to the date and time when the vacation
- response was generated. Note that this may not be the same as the
- time the message was delivered to the user.
-
-
-
-
-
-Showalter & Freed Standards Track [Page 9]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
-5.3. Subject
-
- Users can specify the Subject of the reply with the ":subject"
- parameter. If the :subject parameter is not supplied, then the
- subject is generated as follows: The subject is set to the characters
- "Auto: " followed by the original subject. An appropriate fixed
- Subject, such as "Automated reply", SHOULD be used in the event that
- :subject isn't specified and the original message doesn't contain a
- Subject field.
-
-5.4. From
-
- Unless explicitly overridden with a :from parameter, the From field
- SHOULD be set to the address of the owner of the Sieve script.
-
-5.5. To
-
- The To field SHOULD be set to the address of the recipient of the
- response.
-
-5.6. Auto-Submitted
-
- An Auto-Submitted field with a value of "auto-replied" SHOULD be
- included in the message header of any vacation message sent.
-
-5.7. Message Body
-
- The body of the message is taken from the reason string in the
- vacation command.
-
-5.8. In-Reply-To and References
-
- Replies MUST have the In-Reply-To field set to the Message-ID of the
- original message, and the References field SHOULD be updated with the
- Message-ID of the original message.
-
- If the original message lacks a Message-ID, an In-Reply-To need not
- be generated, and References need not be changed.
-
- Section 3.6.4 of [RFC2822] provides a complete description of how
- References fields should be generated.
-
-
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 10]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
-6. Relationship to Recommendations for Automatic Responses to
- Electronic Mail
-
- The vacation extension implements a "Personal Responder" in the
- terminology defined in [RFC3834]. Care has been taken in this
- specification to comply with the recommendations of [RFC3834]
- regarding how personal responders should behave.
-
-7. Internationalization Considerations
-
- Internationalization capabilities provided by the base Sieve language
- are discussed in [RFC5228]. However, the vacation extension is the
- first Sieve extension to be defined that is capable of creating
- entirely new messages. This section deals with internationalization
- issues raised by the use of the vacation extension.
-
- Vacation messages are normally written using the UTF-8 charset,
- allowing text to be written in most of the world's languages.
- Additionally, the :mime parameter allows specification of arbitrary
- MIME content. In particular, this makes it possible to use
- multipart/alternative objects to specify vacation responses in
- multiple languages simultaneously.
-
- The Sieve language itself allows a vacation response to be selected
- based on the content of the original message. For example, the
- Accept-Language or Content-Language header fields [RFC3282] could be
- checked and used to select appropriate text:
-
- require "vacation";
- if header :contains ["accept-language", "content-language"] "en"
- {
- vacation "I am away this week.";
- } else {
- vacation "Estoy ausente esta semana.";
- }
-
- Note that this rather simplistic test of the field values fails to
- take the structure of the fields into account and hence could be
- fooled by some more complex field values. A more elaborate test
- could be used to deal with this problem.
-
- The approach of explicitly coding language selection criteria in
- scripts is preferred because in many cases language selection issues
- are conflated with other selection issues. For example, it may be
- appropriate to use informal text in one language for vacation
- responses sent to a fellow employee while using more formal text in a
- different language in a response sent to a total stranger outside the
- company:
-
-
-
-Showalter & Freed Standards Track [Page 11]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
- require "vacation";
- if address :matches "from" "*@ourdivision.example.com"
- {
- vacation :subject "Gone fishing"
- "Having lots of fun! Back in a day or two!";
- } else {
- vacation :subject "Je suis parti cette semaine"
- "Je lirai votre message quand je retourne.";
- }
-
- IMPLEMENTATION NOTE: A graphical Sieve generation interface could in
- principle be used to hide the complexity of specifying response
- selection criteria from end users. Figuring out the right set of
- options to present in a graphical interface is likely a nontrivial
- proposition, but this is more because of the need to employ a variety
- of criteria to select different sorts of responses to send to
- different classes of people than because of the issues involved in
- selecting a response in an appropriate language.
-
-8. Security Considerations
-
- It is critical that implementations correctly implement the behavior
- and restrictions described throughout this document. Replies MUST
- NOT be sent out in response to messages not sent directly to the
- user, and replies MUST NOT be sent out more often than the :days
- argument states unless the script changes.
-
- If mail is forwarded from a site that uses subaddressing, it may be
- impossible to list all recipient addresses with ":addresses".
-
- Security issues associated with mail auto-responders are fully
- discussed in the security considerations section of [RFC3834]. This
- document is believed not to introduce any additional security
- considerations in this general area.
-
-9. IANA Considerations
-
- The following template specifies the IANA registration of the
- vacation Sieve extension specified in this document:
-
- To: iana at iana.org
- Subject: Registration of new Sieve extension
-
- Capability name: vacation
- Description: adds an action for generating an auto-reply saying
- that the original message will not be read or
- answered immediately
- RFC number: RFC 5230
-
-
-
-Showalter & Freed Standards Track [Page 12]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
- Contact address: The Sieve discussion list <ietf-mta-filters at imc.org>
-
- This information has been added to the list of Sieve extensions given
- on http://www.iana.org/assignments/sieve-extensions.
-
-10. References
-
-10.1. Normative References
-
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
- [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
- Part Three: Message Header Extensions for Non-ASCII Text",
- RFC 2047, November 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
- April 2001.
-
- [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
- Extension for Delivery Status Notifications (DSNs)",
- RFC 3461, January 2003.
-
- [RFC3834] Moore, K., "Recommendations for Automatic Responses to
- Electronic Mail", RFC 3834, August 2004.
-
- [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
- Filtering Language", RFC 5228, January 2008.
-
- [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
- RFC 5229, January 2008.
-
-10.2. Informative References
-
- [REJECT] Stone, A., Elvey, M., and A. Melnikov, "Sieve Email
- Filtering: Reject Extension", Work in Progress,
- October 2007.
-
- [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
- FUNCTIONS", RFC 2142, May 1997.
-
- [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
- for Core Mail List Commands and their Transport through
- Message Header Fields", RFC 2369, July 1998.
-
-
-
-Showalter & Freed Standards Track [Page 13]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
- [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
- April 2001.
-
- [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
- and Namespace for the Identification of Mailing Lists",
- RFC 2919, March 2001.
-
- [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
- May 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 14]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
-Appendix A. Acknowledgements
-
- This extension is obviously inspired by Eric Allman's vacation
- program under Unix. The authors owe a great deal to Carnegie Mellon
- University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil
- Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov,
- Jeffrey Hutzelman, Philip Guenther, and many others whose names have
- been lost during the inexcusably long gestation period of this
- document.
-
-Authors' Addresses
-
- Tim Showalter
-
- EMail: tjs at psaux.com
-
-
- Ned Freed (editor)
- Sun Microsystems
- 3401 Centrelake Drive, Suite 410
- Ontario, CA 92761-1205
- USA
-
- Phone: +1 909 457 4293
- EMail: ned.freed at mrochek.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 15]
-
-RFC 5230 Sieve: Vacation Extension January 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr at ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Showalter & Freed Standards Track [Page 16]
-
diff --git a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5232/rfc5232.txt b/chrome/chromeFiles/content/libs/libSieveDOM/RFC5232/rfc5232.txt
deleted file mode 100644
index 5707267..0000000
--- a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5232/rfc5232.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Melnikov
-Request for Comments: 5232 Isode Limited
-Category: Standards Track January 2008
-
-
- Sieve Email Filtering: Imap4flags Extension
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- Recent discussions have shown that it is desirable to set different
- IMAP (RFC 3501) flags on message delivery. This can be done, for
- example, by a Sieve interpreter that works as a part of a Mail
- Delivery Agent.
-
- This document describes an extension to the Sieve mail filtering
- language for setting IMAP flags. The extension allows setting of
- both IMAP system flags and IMAP keywords.
-
-Table of Contents
-
- 1. Introduction ....................................................2
- 1.1. Conventions Used ...........................................2
- 2. General Requirements for Flag Handling ..........................3
- 3. Actions .........................................................3
- 3.1. Action setflag .............................................4
- 3.2. Action addflag .............................................4
- 3.3. Action removeflag ..........................................5
- 4. Test hasflag ....................................................6
- 5. Tagged Argument :flags ..........................................7
- 6. Interaction with Other Sieve Actions ............................8
- 7. Security Considerations .........................................8
- 8. IANA Considerations .............................................8
- 9. Extended Example ................................................8
- 10. Acknowledgments ...............................................10
- 11. Normative References ..........................................10
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 1]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
-1. Introduction
-
- This is an extension to the Sieve language defined by [SIEVE] for
- setting [IMAP] flags. It adds a new tagged argument to "keep" and
- "fileinto" that describes the list of flags that have to be set when
- the message is delivered to the specified mailbox. It also adds
- several actions to help manipulate list of flags and a test to check
- whether a flag belongs to a list.
-
- From the user's perspective, this extension provides several
- capabilities. First, it allows manipulation of sets of IMAP flags.
- Second, it gives the ability to associate a set of IMAP flags with a
- message that is delivered to a mailstore using the keep/fileinto
- actions. Third, it maintains an internal variable. The internal
- variable contains the default flags that will be associated with a
- message that is delivered using the keep, implicit keep, or fileinto
- actions, when the :flags tagged argument is not specified. When the
- Sieve [VARIABLES] extension is also supported by the Sieve engine, it
- enables support for multiple variables containing sets of IMAP flags.
-
- The capability string associated with the extension defined in this
- document is "imap4flags". All conformant implementations MUST
- implement all Sieve actions (setflag, addflag, removeflag), the
- "hasflag" test, and the ":flags" tagged argument described in this
- document.
-
- The "imap4flags" extension can be used with or without the
- "variables" extension [VARIABLES]. When the "variables" extension is
- enabled in a script using <require "variables">, the script can use
- explicit variable names in setflag/addflag/removeflag actions and the
- hasflag test. See also Section 3 for more details. When the
- "variables" extension is not enabled, the explicit variable name
- parameter to setflag/addflag/removeflag/hasflag MUST NOT be used and
- MUST cause an error according to [SIEVE].
-
-1.1. Conventions Used
-
- Conventions for notations are as in [SIEVE], Section 1.1, including
- use of "Usage:" label for the definition of action and tagged
- arguments syntax.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119.
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 2]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
-2. General Requirements for Flag Handling
-
- The following notes apply to processing of addflag/removeflag/setflag
- actions, the "hasflag" test and the ":flags" tagged argument.
-
- A Sieve interpreter MUST ignore empty strings (i.e., "") in a list-
- of-flags parameter.
-
- A string containing a space-separated list of flag names is
- equivalent to a string list consisting of the flags. This
- requirement is to simplify amalgamation of multiple flag lists.
-
- The Sieve interpreter SHOULD check the list of flags for validity as
- described by [IMAP] ABNF. In particular, according to [IMAP], non-
- ASCII characters are not allowed in flag names. However, spaces MUST
- always be allowed as delimiters in strings representing a list of
- flags. In such strings, multiple spaces between flag names MUST be
- treated as a single space character, and leading and trailing spaces
- MUST be ignored.
-
- If a flag validity check fails, the flag MUST be ignored.
-
- Note that it is not possible to use this extension to set or clear
- the \Recent flag or any other special system flag that is not
- settable in [IMAP]. Any such flags MUST be ignored if included in a
- flag list.
-
-3. Actions
-
- All actions described in this specification (setflag, addflag,
- removeflag) operate on string variables that contain a set of [IMAP]
- flags. On variable substitution, a set of flags is represented as a
- string containing a space-separated list of flag names.
-
- Any setflag/addflag/removeflag action MAY alter the flag list in any
- way that leaves its semantics as a set of case-insensitive words
- unaltered. For example, it may reorder the flags, alter the case of
- the letters in them, or add or remove duplicates or extraneous
- spaces. Scripts MUST NOT make assumptions about the ordering of
- flags in lists or the preservation of their case.
-
- Note that the parameter specifying a variable name to
- setflag/addflag/removeflag actions and the hasflag test is optional.
- If the parameter is not specified, the actions operate on the
- internal variable, which has the empty value when the script starts
- execution. If the SIEVE interpreter doesn't support the "variables"
- extension [VARIABLES], the presence of the variable name parameter
- will cause a runtime error [SIEVE].
-
-
-
-Melnikov Standards Track [Page 3]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
- The "addflag" action adds flags to an existing set. The "removeflag"
- action removes flags from an existing set. The "setflag" action
- replaces an existing set of flags with a new set. The "set" action
- defined in [VARIABLES] can be used to replace an existing set of
- flags with a new set as well. However, it should be noted that the
- "set" action can't perform any flag reordering, duplicate
- elimination, etc.
-
- The :flags tagged argument to "keep" and "fileinto" actions is used
- to associate a set of flags with the current message. If the :flags
- tagged argument is not specified with those two actions, the current
- value of the internal variable is used instead. The value of the
- internal variable also applies to the implicit keep.
-
- Note that when keep/fileinto is used multiple times in a script and
- duplicate message elimination is performed (as described in Section
- 2.10.3 of [SIEVE]), the last flag list value MUST win.
-
-3.1. Action setflag
-
- Usage: setflag [<variablename: string>]
- <list-of-flags: string-list>
-
- Setflag is used for setting [IMAP] system flags or keywords.
- Setflag replaces any previously set flags.
-
-
- Example: if size :over 500K {
- setflag "\\Deleted";
- }
-
- A more substantial example is the following:
-
- Example:
- if header :contains "from" "boss at frobnitzm.example.edu" {
- setflag "flagvar" "\\Flagged";
- fileinto :flags "${flagvar}" "INBOX.From Boss";
- }
-
-3.2. Action addflag
-
- Usage: addflag [<variablename: string>]
- <list-of-flags: string-list>
-
- Addflag is used to add flags to a list of [IMAP] flags. It doesn't
- replace any previously set flags. This means that multiple
- occurrences of addflag are treated additively.
-
-
-
-
-Melnikov Standards Track [Page 4]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
- The following examples demonstrate requirements described in Section
- 2.1. The following two actions
-
- addflag "flagvar" "\\Deleted";
- addflag "flagvar" "\\Answered";
-
- produce the same result as the single action
-
- addflag "flagvar" ["\\Deleted", "\\Answered"];
-
- or
-
- addflag "flagvar" "\\Deleted \\Answered";
-
- or
-
- addflag "flagvar" "\\Answered \\Deleted";
-
-3.3. Action removeflag
-
- Usage: removeflag [<variablename: string>]
- <list-of-flags: string-list>
-
- Removeflag is used to remove flags from a list of [IMAP] flags.
- Removeflag clears flags previously set by "set"/"addflag". Calling
- removeflag with a flag that wasn't set before is not an error and is
- ignored. Note that if an implementation doesn't perform automatic
- duplicate elimination, it MUST remove all occurrences of the flags
- specified in the second parameter to removeflag. Empty strings in
- the list-of-flags MUST be ignored. Also note that flag names are
- case-insensitive, as described in [IMAP]. Multiple removeflag
- actions are treated additively.
-
- Example:
- if header :contains "Disposition-Notification-To"
- "mel at example.com" {
- addflag "flagvar" "$MDNRequired";
- }
- if header :contains "from" "imap at cac.washington.example.edu" {
- removeflag "flagvar" "$MDNRequired";
- fileinto :flags "${flagvar}" "INBOX.imap-list";
- }
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 5]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
-4. Test hasflag
-
- Usage: hasflag [MATCH-TYPE] [COMPARATOR]
- [<variable-list: string-list>]
- <list-of-flags: string-list>
-
- The hasflag test evaluates to true if any of the variables matches
- any flag name. The type of match defaults to ":is". If the list of
- variables is omitted, value of the internal variable is used instead.
-
- The default comparator is "i;ascii-casemap", which is the same case-
- insensitive comparison as defined for IMAP flags by [IMAP].
-
- The "relational" extension [RELATIONAL] adds a match type called
- ":count". The :count of a variable returns the number of distinct
- flags in it. The count of a list of variables is the sum of the
- counts of the member variables.
-
- Example:
- If the internal variable has the value "A B", the following test
-
- hasflag :is "b A"
-
- evaluates to true. The above test can also be written as
-
- hasflag ["b","A"]
-
- Example:
- If the variable "MyVar" has value "NonJunk Junk gnus-forward
- $Forwarded NotJunk JunkRecorded $Junk $NotJunk", the following
- tests evaluate to true:
-
- hasflag :contains "MyVar" "Junk"
- hasflag :contains "MyVar" "forward"
- hasflag :contains "MyVar" ["label", "forward"]
- hasflag :contains "MyVar" ["junk", "forward"]
-
- Note that the last of these tests can be rewritten
- as
-
- hasflag :contains "MyVar" "junk forward"
-
- or
-
- hasflag :contains "MyVar" "forward junk"
-
- However, the last two forms are not recommended.
-
-
-
-
-Melnikov Standards Track [Page 6]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
- And the following tests will evaluate to false:
-
- hasflag :contains "MyVar" "label"
-
- hasflag :contains "MyVar" ["label1", "label2"]
-
- Example:
- If the variable "MyFlags" has the value "A B", the following test
-
- hasflag :count "ge" :comparator "i;ascii-numeric"
- "MyFlags" "2"
-
- evaluates to true, as the variable contains 2 distinct flags.
-
-5. Tagged Argument :flags
-
- This specification adds a new optional tagged argument ":flags" that
- alters the behavior of actions "keep" and "fileinto".
-
- The :flags tagged argument specifies that the flags provided in the
- subsequent argument should be set when fileinto/keep delivers the
- message to the target mailbox/user's main mailbox. If the :flags
- tagged argument is not specified, "keep" or "fileinto" will use the
- current value of the internal variable when delivering the message to
- the target mailbox.
-
- Usage: ":flags" <list-of-flags: string-list>
-
- The copy of the message filed into the mailbox will have only flags
- listed after the :flags tagged argument.
-
- The Sieve interpreter MUST ignore all flags that it can't store
- permanently. This means that the interpreter MUST NOT treat failure
- to store any flag as a runtime failure to execute the Sieve script.
- For example, if the mailbox "INBOX.From Boss" can't store any flags,
- then
-
- fileinto :flags "\\Deleted" "INBOX.From Boss";
-
- and
-
- fileinto "INBOX.From Boss";
-
- are equivalent.
-
- This document doesn't dictate how the Sieve interpreter will set the
- [IMAP] flags. In particular, the Sieve interpreter may work as an
- IMAP client or may have direct access to the mailstore.
-
-
-
-Melnikov Standards Track [Page 7]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
-6. Interaction with Other Sieve Actions
-
- This extension works only on the message that is currently being
- processed by Sieve; it doesn't affect another message generated as a
- side effect of any action or any other message already in the
- mailstore.
-
- The extension described in this document doesn't change the implicit
- keep (see Section 2.10.2 of [SIEVE]).
-
-7. Security Considerations
-
- Security considerations are discussed in [IMAP], [SIEVE], and
- [VARIABLES].
-
- This extension intentionally doesn't allow setting [IMAP] flags on an
- arbitrary message in the [IMAP] message store.
-
- It is believed that this extension doesn't introduce any additional
- security concerns.
-
-8. IANA Considerations
-
- The following template specifies the IANA registration of the
- variables Sieve extension specified in this document:
-
- To: iana at iana.org
- Subject: Registration of new Sieve extension
-
- Capability name: imap4flags
- Description: Adds actions and tests for manipulating IMAP flags
- RFC number: RFC 5232
- Contact address: The Sieve discussion list <ietf-mta-filters at imc.org>
-
- This information has been added to the list of Sieve extensions given
- on http://www.iana.org/assignments/sieve-extensions.
-
-9. Extended Example
-
- #
- # Example Sieve Filter
- # Declare any optional features or extension used by the script
- #
- require ["fileinto", "imap4flags", "variables"];
-
- #
- # Move large messages to a special mailbox
- #
-
-
-
-Melnikov Standards Track [Page 8]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
- if size :over 1M
- {
- addflag "MyFlags" "Big";
- if header :is "From" "boss at company.example.com"
- {
- # The message will be marked as "\Flagged Big" when filed into
- # mailbox "Big messages"
- addflag "MyFlags" "\\Flagged";
- }
- fileinto :flags "${MyFlags}" "Big messages";
- }
-
- if header :is "From" "grandma at example.net"
- {
- addflag "MyFlags" ["\\Answered", "$MDNSent"];
- # If the message is bigger than 1Mb it will be marked as
- # "Big \Answered $MDNSent" when filed into mailbox "grandma".
- # If the message is shorter than 1Mb it will be marked as
- # "\Answered $MDNSent"
- fileinto :flags "${MyFlags}" "GrandMa";
- }
-
- #
- # Handle messages from known mailing lists
- # Move messages from IETF filter discussion list to filter folder
- #
- if header :is "Sender" "owner-ietf-mta-filters at example.org"
- {
- set "MyFlags" "\\Flagged $Work";
- # Message will have both "\Flagged" and $Work flags
- keep :flags "${MyFlags}";
- }
-
- #
- # Keep all messages to or from people in my company
- #
- elsif anyof address :domain :is ["From", "To"] "company.example.com"
- {
- keep :flags "${MyFlags}"; # keep in "Inbox" folder
- }
-
- # Try to catch unsolicited email. If a message is not to me,
- # or it contains a subject known to be spam, file it away.
- #
- elsif anyof (not address :all :contains
- ["To", "Cc"] "me at company.example.com",
- header :matches "subject"
- ["*make*money*fast*", "*university*dipl*mas*"])
-
-
-
-Melnikov Standards Track [Page 9]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
- {
- remove "MyFlags" "\\Flagged";
- fileinto :flags "${MyFlags}" "spam";
- }
- else
- {
- # Move all other external mail to "personal"
- # folder.
- fileinto :flags "${MyFlags}" "personal";
- }
-
-10. Acknowledgments
-
- This document has been revised in part based on comments and
- discussions that took place on and off the Sieve mailing list.
-
- The help of those who took the time to review the document and make
- suggestions is appreciated, especially that of Tim Showalter, Barry
- Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, Matthew Elvey,
- Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson, Kjetil Torgrim
- Homme, Mark E. Mallett, Dave Cridland, Arnt Gulbrandsen, Philip
- Guenther, Rob Austein, Sam Hartman, Eric Gray, and Cullen Jennings.
-
- Special thanks to Tony Hansen and David Lamb for helping me better
- explain the concept.
-
-11. Normative References
-
- [SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An
- Email Filtering Language", RFC 5228, January 2008.
-
- [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
- 4rev1", RFC 3501, March 2003.
-
- [VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension",
- RFC 5229, January 2008.
-
- [RELATIONAL] Segmuller, W. and B. Leiba "Sieve Email Filtering:
- Relational Extension", RFC 5231, January 2008.
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 10]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
-Author's Address
-
- Alexey Melnikov
- Isode Limited
-
- 5 Castle Business Village
- Hampton, Middlesex
- United Kingdom, TW12 2BX
-
- EMail: alexey.melnikov at isode.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 11]
-
-RFC 5232 Sieve: Imap4flags Extension January 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr at ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Standards Track [Page 12]
-
diff --git a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5293/rfc5293.txt b/chrome/chromeFiles/content/libs/libSieveDOM/RFC5293/rfc5293.txt
deleted file mode 100644
index 18f533e..0000000
--- a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5293/rfc5293.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Degener
-Request for Comments: 5293 P. Guenther
-Category: Standards Track Sendmail, Inc.
- August 2008
-
-
- Sieve Email Filtering: Editheader Extension
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document defines two new actions for the "Sieve" email filtering
- language that add and delete email header fields.
-
-1. Introduction
-
- Email header fields are a flexible and easy-to-understand means of
- communication between email processors. This extension enables sieve
- scripts to interact with other components that consume or produce
- header fields by allowing the script to delete and add header fields.
-
-2. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [KEYWORDS].
-
- Conventions for notations are as in Section 1.1 of [SIEVE], including
- use of the "Usage:" label for the definition of action and tagged
- arguments syntax.
-
- The term "header field" is used here as in [IMAIL] to mean a logical
- line of an email message header.
-
-3. Capability Identifier
-
- The capability string associated with the extension defined in this
- document is "editheader".
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 1]
-
-RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
-
-
-4. Action addheader
-
- Usage: "addheader" [":last"] <field-name: string> <value: string>
-
- The addheader action adds a header field to the existing message
- header. If the field-name is not a valid 7-bit US-ASCII header field
- name, as described by the [IMAIL] "field-name" nonterminal syntax
- element, the implementation MUST flag an error. The addheader action
- does not affect Sieve's implicit keep.
-
- If the specified field value does not match the [IMAIL]
- "unstructured" nonterminal syntax element or exceeds a length limit
- set by the implementation, the implementation MUST either flag an
- error or encode the field using folding white space and the encodings
- described in [MIME3] or [MIMEPARAM] to be compliant with [IMAIL].
-
- An implementation MAY impose a length limit onto the size of the
- encoded header field; such a limit MUST NOT be less than 998
- characters, not including the terminating CRLF supplied by the
- implementation.
-
- By default, the header field is inserted at the beginning of the
- existing message header. If the optional flag ":last" is specified,
- it is appended at the end.
-
- Example:
-
- /* Don't redirect if we already redirected */
- if not header :contains "X-Sieve-Filtered"
- ["<kim at job.example.com>", "<kim at home.example.com>"]
- {
- addheader "X-Sieve-Filtered" "<kim at job.example.com>";
- redirect "kim at home.example.com";
- }
-
-5. Action deleteheader
-
- Usage: "deleteheader" [":index" <fieldno: number> [":last"]]
- [COMPARATOR] [MATCH-TYPE]
- <field-name: string>
- [<value-patterns: string-list>]
-
- By default, the deleteheader action deletes all occurrences of the
- named header field. The deleteheader action does not affect Sieve's
- implicit keep.
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 2]
-
-RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
-
-
- The field-name is mandatory and always matched as a case-insensitive
- US-ASCII string. If the field-name is not a valid 7-bit header field
- name as described by the [IMAIL] "field-name" nonterminal syntax
- element, the implementation MUST flag an error.
-
- The value-patterns, if specified, restrict which occurrences of the
- header field are deleted to those whose values match any of the
- specified value-patterns, the matching being according to the match-
- type and comparator and performed as if by the "header" test. In
- particular, leading and trailing whitespace in the field values is
- ignored. If no value-patterns are specified, then the comparator and
- match-type options are silently ignored.
-
- If :index <fieldno> is specified, the attempts to match a value are
- limited to the <fieldno> occurrence of the named header field,
- beginning at 1, the first named header field. If :last is specified,
- the count is backwards; 1 denotes the last named header field, 2 the
- second to last, and so on. The counting happens before the <value-
- patterns> match, if any. For example:
-
- deleteheader :index 1 :contains "Delivered-To"
- "bob at example.com";
-
- deletes the first "Delivered-To" header field if it contains the
- string "bob at example.com" (not the first "Delivered-To" field that
- contains "bob at example.com").
-
- It is not an error if no header fields match the conditions in the
- deleteheader action or if the :index argument is greater than the
- number of named header fields.
-
- The implementation MUST flag an error if :last is specified without
- also specifying :index.
-
-6. Implementation Limitations on Changes
-
- As a matter of local policy, implementations MAY limit which header
- fields may be deleted and which header fields may be added. However,
- implementations MUST NOT permit attempts to delete "Received" and
- "Auto-Submitted" header fields and MUST permit both addition and
- deletion of the "Subject" header field.
-
- If a script tries to make a change that isn't permitted, the attempt
- MUST be silently ignored.
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 3]
-
-RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
-
-
-7. Interaction with Other Sieve Extensions
-
- Actions that generate [MDN], [DSN], or similar disposition messages
- MUST do so using the original, unmodified message header. Similarly,
- if an error terminates processing of the script, the original message
- header MUST be used when doing the implicit keep required by Section
- 2.10.6 of [SIEVE].
-
- All other actions that store, send, or alter the message MUST do so
- with the current set of header fields. This includes the addheader
- and deleteheader actions themselves. For example, the following
- leaves the message unchanged:
-
- addheader "X-Hello" "World";
- deleteheader :index 1 "X-Hello";
-
- Similarly, given a message with three or more "X-Hello" header
- fields, the following example deletes the first and third of them,
- not the first and second:
-
- deleteheader :index 1 "X-Hello";
- deleteheader :index 2 "X-Hello";
-
- Tests and actions such as "exists", "header", or "vacation"
- [VACATION] that examine header fields MUST examine the current state
- of a header as modified by any actions that have taken place so far.
-
- As an example, the "header" test in the following fragment will
- always evaluate to true, regardless of whether or not the incoming
- message contained an "X-Hello" header field:
-
- addheader "X-Hello" "World";
- if header :contains "X-Hello" "World"
- {
- fileinto "international";
- }
-
- However, if the presence or value of a header field affects how the
- implementation parses or decodes other parts of the message, then,
- for the purposes of that parsing or decoding, the implementation MAY
- ignore some or all changes made to those header fields. For example,
- in an implementation that supports the [BODY] extension, "body" tests
- may be unaffected by deleting or adding "Content-Type" or "Content-
- Transfer-Encoding" header fields. This does not rescind the
- requirement that changes to those header fields affect direct tests;
- only the semantic side effects of changes to the fields may be
- ignored.
-
-
-
-
-Degener & Guenther Standards Track [Page 4]
-
-RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
-
-
- For the purpose of weeding out duplicates, a message modified by
- addheader or deleteheader MUST be considered the same as the original
- message. For example, in an implementation that obeys the constraint
- in Section 2.10.3 of [SIEVE] and does not deliver the same message to
- a folder more than once, the following code fragment
-
- keep;
- addheader "X-Flavor" "vanilla";
- keep;
-
- MUST only file one message. It is up to the implementation to pick
- which of the redundant "fileinto" or "keep" actions is executed, and
- which ones are ignored.
-
- The "implicit keep" is thought to be executed at the end of the
- script, after the headers have been modified. (However, a canceled
- "implicit keep" remains canceled.)
-
-8. IANA Considerations
-
- The following template specifies the IANA registration of the Sieve
- extension specified in this document:
-
- To: iana at iana.org
- Subject: Registration of new Sieve extension
-
- Capability name: editheader
- Description: Adds actions 'addheader' and 'deleteheader' that
- modify the header of the message being processed
- RFC number: RFC 5293
- Contact Address: The Sieve discussion list <ietf-mta-filters&imc.org>
-
-9. Security Considerations
-
- Someone with write access to a user's script storage may use this
- extension to generate headers that a user would otherwise be shielded
- from (e.g., by a gateway Mail Transport Agent (MTA) that removes
- them).
-
- This is the first Sieve extension to be standardized that allows
- alteration of messages being processed by Sieve engines. A Sieve
- script that uses Sieve tests defined in [SIEVE], the editheader
- extension, and the redirect action back to the same user can keep
- some state between different invocations of the same script for the
- same message. But note that it would not be possible to introduce an
- infinite loop using any such script, because each iteration adds a
- new Received header field, so email loop prevention described in
- [SMTP] will eventually non deliver the message, and because the
-
-
-
-Degener & Guenther Standards Track [Page 5]
-
-RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
-
-
- editheader extension is explicitly prohibited to alter or delete
- Received header fields (i.e., it can't interfere with loop
- prevention).
-
- A sieve filter that removes header fields may unwisely destroy
- evidence about the path a message has taken.
-
- Any change in message content may interfere with digital signature
- mechanisms that include the header in the signed material. For
- example, changes to (or deletion/addition of) header fields included
- in the "SHOULD be included in the signature" list in Section 5.5 of
- [DKIM] can invalidate DKIM signatures. This also includes DKIM
- signatures that guarantee a header field absence.
-
- The editheader extension doesn't directly affect [IMAIL] header field
- signatures generated using [SMIME] or [OPENPGP], because these
- signature schemes include a separate copy of the header fields inside
- the signed message/rfc822 body part. However, software written to
- detect differences between the inner (signed) copy of header fields
- and the outer (modified by editheader) header fields might be
- affected by changes made by editheader.
-
- Since normal message delivery adds "Received" header fields and other
- trace fields to the beginning of a message, many such digital
- signature mechanisms are impervious to headers prefixed to a message,
- and will work with "addheader" unless :last is used.
-
- Any decision mechanism in a user's filter that is based on headers is
- vulnerable to header spoofing. For example, if the user adds an
- APPROVED header or tag, a malicious sender may add that tag or header
- themselves. One way to guard against this is to delete or rename any
- such headers or stamps prior to processing the message.
-
-10. Acknowledgments
-
- Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Arnt
- Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, Will Lee, William
- Leibzon, Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall
- Schwartz, Aaron Stone, Nigel Swinson, and Rand Wacker for extensive
- corrections and suggestions.
-
-
-
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 6]
-
-RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
-
-
-11. References
-
-11.1. Normative References
-
- [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822,
- April 2001.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
- Part Three: Message Header Extensions for Non-ASCII
- Text", RFC 2047, November 1996.
-
- [MIMEPARAM] Freed, N. and K. Moore, "MIME Parameter Value and
- Encoded Word Extensions: Character Sets, Languages, and
- Continuations", RFC 2231, November 1997.
-
- [SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An
- Email Filtering Language", RFC 5228, January 2008.
-
-11.2. Informative References
-
- [BODY] Degener, J. and P. Guenther, "Sieve Email Filtering:
- Body Extension", RFC 5173, April 2008.
-
- [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
- J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
- Signatures", RFC 4871, May 2007.
-
- [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message
- Format for Delivery Status Notifications", RFC 3464,
- January 2003.
-
- [MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message
- Disposition Notification", RFC 3798, May 2004.
-
- [OPENPGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
- "MIME Security with OpenPGP", RFC 3156, August 2001.
-
- [SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
- Extensions (S/MIME) Version 3.1 Message Specification",
- RFC 3851, July 2004.
-
- [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
- 2821, April 2001.
-
-
-
-
-
-Degener & Guenther Standards Track [Page 7]
-
-RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
-
-
- [VACATION] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering:
- Vacation Extension", RFC 5230, January 2008.
-
-Authors' Addresses
-
- Jutta Degener
- 5245 College Ave, Suite #127
- Oakland, CA 94618
-
- EMail: jutta at pobox.com
-
-
- Philip Guenther
- Sendmail, Inc.
- 6475 Christie Ave., Ste 350
- Emeryville, CA 94608
-
- EMail: guenther at sendmail.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 8]
-
-RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr at ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Degener & Guenther Standards Track [Page 9]
-
diff --git a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5429/rfc5429.txt b/chrome/chromeFiles/content/libs/libSieveDOM/RFC5429/rfc5429.txt
deleted file mode 100644
index 232ba35..0000000
--- a/chrome/chromeFiles/content/libs/libSieveDOM/RFC5429/rfc5429.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Stone, Ed.
-Request for Comments: 5429 Serendipity
-Obsoletes: 3028 March 2009
-Updates: 5228
-Category: Standards Track
-
-
- Sieve Email Filtering: Reject and Extended Reject Extensions
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
- This document may contain material from IETF Documents or IETF
- Contributions published or made publicly available before November
- 10, 2008. The person(s) controlling the copyright in some of this
- material may not have granted the IETF Trust the right to allow
- modifications of such material outside the IETF Standards Process.
- Without obtaining an adequate license from the person(s) controlling
- the copyright in such materials, this document may not be modified
- outside the IETF Standards Process, and derivative works of it may
- not be created outside the IETF Standards Process, except to format
- it for publication as an RFC or to translate it into languages other
- than English.
-
-Abstract
-
- This memo updates the definition of the Sieve mail filtering language
- "reject" extension, originally defined in RFC 3028.
-
- A "Joe-job" is a spam run forged to appear as though it came from an
- innocent party, who is then generally flooded by automated bounces,
- Message Disposition Notifications (MDNs), and personal messages with
-
-
-
-Stone Standards Track [Page 1]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
- complaints. The original Sieve "reject" action defined in RFC 3028
- required use of MDNs for rejecting messages, thus contributing to the
- flood of Joe-job spam to victims of Joe-jobs.
-
- This memo updates the definition of the "reject" action to allow
- messages to be refused during the SMTP transaction, and defines the
- "ereject" action to require messages to be refused during the SMTP
- transaction, if possible.
-
- The "ereject" action is intended to replace the "reject" action
- wherever possible. The "ereject" action is similar to "reject", but
- will always favor protocol-level message rejection.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
- 2. Sieve "reject" and "ereject" Extensions . . . . . . . . . . . 4
- 2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1.1. Rejecting a Message at the SMTP/LMTP Protocol Level . 5
- 2.1.2. Rejecting a Message by Sending a DSN . . . . . . . . . 5
- 2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 6
- 2.2.1. Rejecting a Message by Sending an MDN . . . . . . . . 7
- 2.3. Silent Upgrade from "reject" to "ereject" . . . . . . . . 8
- 2.4. Compatibility with Other Actions . . . . . . . . . . . . . 9
- 2.5. Details of Protocol-Level Refusal . . . . . . . . . . . . 9
- 3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 11
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 5.1. "reject" Extension Registration . . . . . . . . . . . . . 11
- 5.2. "ereject" Extension Registration . . . . . . . . . . . . . 12
- 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
- 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
- Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
- Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stone Standards Track [Page 2]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
-1. Introduction
-
- The Sieve mail filtering language, as originally defined in RFC 3028
- [RFC3028], specified that the "reject" action shall discard a message
- and send a Message Disposition Notification [MDN] to the envelope
- sender along with an explanatory message. The Sieve mail filtering
- language, as updated in RFC 5228 [SIEVE], does not define any
- "reject" action, hence that is the purpose of this document.
-
- This document updates the definition of the "reject" action to permit
- refusal of the message during the SMTP transaction, if possible, and
- defines a new "ereject" action to require refusal of the message
- during the SMTP transaction, if possible.
-
- An important goal of this document is to reduce the risk of Sieve
- scripts being used to perpetrate "Joe-job" spam runs, where the MDN
- is sent notifying the sender of a message of its non-delivery is in
- fact sent to an innocent third-party. The original Sieve "reject"
- action defined in RFC 3028 required use of MDNs for rejecting
- messages, thus contributing to the flood of Joe-job spam to victims
- of Joe-jobs. By rejecting the message at the protocol level, it is
- less likely that an MDN will be needed, and thus less likely that an
- MDN will be misdirected at an innocent third-party.
-
- Implementations are further encouraged to use spam-detection systems
- to determine the level of risk associated with sending an MDN, and
- this document allows implementations to silently drop the MDN if the
- rejected message is deemed likely to be spam.
-
- This document also describes how to use "reject"/"ereject" at varying
- points in the email stack: Mail Transfer Agent (MTA), Mail Delivery
- Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a
- comprehensive discussion of these environments.
-
- In general, an MDN is generated by an MUA, and can be used to
- indicate the status of a message with respect to its recipient, while
- a Delivery Status Notification (DSN) [DSN] is generated by an MTA,
- and can be used to indicate whether or not a message was received and
- delivered by the mail system.
-
- Further discussion highlighting the risks of generating MDNs and the
- benefits of protocol-level refusal can be found in [Joe-DoS].
-
-1.1. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [KEYWORDS].
-
-
-
-Stone Standards Track [Page 3]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
- Conventions for notations are as in Section 1.1 of RFC 5228 [SIEVE].
-
- This document does not attempt to define spam or how it should be
- identified, nor does it attempt to define an email virus or how it
- should be detected. Implementors are advised to follow best
- practices and keep abreast of current research in these fields.
-
-2. Sieve "reject" and "ereject" Extensions
-
-2.1. Action ereject
-
- Usage: ereject <reason: string>
-
- Sieve implementations that implement the "ereject" action must use
- the "ereject" capability string.
-
- The "ereject" action cancels the implicit keep and refuses delivery
- of a message. The "reason" string is a UTF-8 [UTF-8] string
- specifying the reason for refusal. How a message is refused depends
- on the capabilities of the mail component (MDA or MTA) executing the
- Sieve script. The Sieve interpreter MUST carry out one of the
- following actions (listed in order from most to least preferred),
- MUST carry out the most preferable action possible, and MUST fall
- back to lesser actions if a preferred action fails.
-
- 1. Refuse message delivery by sending a 5XX response code over SMTP
- [SMTP] or Local Mail Transfer Protocol (LMTP) [LMTP]. See
- Section 2.1.1 for more details.
-
- 2. Send a non-delivery report to the envelope sender ([REPORT]
- [DSN]), unless the envelope sender address is determined to be a
- forged or otherwise invalid address.
-
- Note that the determination of whether or not an envelope sender is a
- forgery may be performed by site-specific and implementation-specific
- heuristic techniques, such as "return-path verification", details of
- which are outside the scope of this document. Implementations SHOULD
- log instances when a non-delivery report is not sent and the reason
- for not sending the report (e.g., content was spam, return-path
- invalid, etc.).
-
- The "ereject" action MUST NOT be available in environments that do
- not support protocol-level rejection, e.g., an MUA, and MUST be
- available in all other environments that support the "reject" action.
-
-
-
-
-
-
-
-Stone Standards Track [Page 4]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
- Example:
- require ["ereject"];
-
- if address "from" "someone at example.com" {
- ereject "I no longer accept mail from this address";
- }
-
-2.1.1. Rejecting a Message at the SMTP/LMTP Protocol Level
-
- Sieve implementations that are able to reject messages at the SMTP/
- LMTP level MUST do so and SHOULD use the 550 response code. Note
- that if a message is arriving over SMTP and has multiple recipients,
- some of whom have accepted the message, Section 2.1.2 defines how to
- reject such a message.
-
- The risk that these actions will generate blowback spam are minimized
- but cannot be eliminated completely even in the case of "ereject", so
- caution is advised when using these actions to deal with messages
- determined to be spam.
-
- Note that SMTP [SMTP] does not allow non-US-ACSII characters in the
- SMTP response text. If non-US-ACSII characters appear in the
- "reason" string, they can be sent at the protocol level if and only
- if the client and the server use an SMTP extension that allows for
- transmission of non-US-ACSII reply text. (One example of such an
- SMTP extension is described in [UTF8-RESP].) In the absence of such
- an SMTP extension, the Sieve engine MUST replace any "reason" string
- being sent at the protocol level and containing non-US-ACSII
- characters with an implementation-defined US-ACSII-only string.
-
- Users who don't like this behavior should consider using the "reject"
- action described in Section 2.2, if available.
-
- See Section 2.5 for the detailed instructions about performing
- protocol-level rejection.
-
-2.1.2. Rejecting a Message by Sending a DSN
-
- An implementation may receive a message via SMTP that has more than
- one RCPT TO that has been accepted by the server, and at least one
- but not all of them are refusing delivery (whether the refusal is
- caused by a Sieve "ereject" action or for some other reason). In
- this case, the server MUST accept the message and generate DSNs for
- all recipients that are refusing it. Note that this exception does
- not apply to LMTP, as LMTP is able to reject messages on a per-
- recipient basis. (However, the LMTP client may then have no choice
- but to generate a DSN to report the error, which may result in
- blowback spam.)
-
-
-
-Stone Standards Track [Page 5]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
- Note that according to [DSN], Delivery Status Notifications MUST NOT
- be generated if the MAIL FROM (or Return-Path) is empty.
-
- The DSN message MUST follow the requirements of [DSN] and [REPORT].
- The action-value field defined in [DSN], Section 2.3.3, MUST contain
- the value "failed". The human-readable portion of the non-delivery
- report MUST contain the "reason" string from the "ereject" action and
- SHOULD contain additional text alerting the apparent original sender
- that the message was refused by an email filter. This part of the
- report might appear as follows:
-
- ------------------------------------------------------------
- Your message was refused by the recipient's mail filtering program.
- The reason given is as follows:
-
- I am not taking mail from you, and I don't want your birdseed,
- either!
- ------------------------------------------------------------
-
-2.2. Action reject
-
- This section updates the definition of the "reject" action in Section
- 4.1 of RFC 3028 [RFC3028] and is an optional extension to [SIEVE].
-
- Usage: reject <reason: string>
-
- Sieve implementations that implement the "reject" action must use the
- "reject" capability string.
-
- The "reject" action cancels the implicit keep and refuses delivery of
- a message. The "reason" string is a UTF-8 [UTF-8] string specifying
- the reason for refusal. Unlike the "ereject" action described above,
- this action would always favor preserving the exact text of the
- refusal reason. Typically, the "reject" action refuses delivery of a
- message by sending back an MDN to the sender (see Section 2.2.1).
- However, implementations MAY refuse delivery over SMTP/LMTP protocol
- (as detailed in Section 2.5), if and only if all of the following
- conditions are true:
-
- 1. The "reason" string consists of only US-ASCII characters
- or
- The "reason" string contains non-US-ASCII and both the client and
- server support and negotiate use of an SMTP/LMTP extension for
- sending UTF-8 responses.
-
-
-
-
-
-
-
-Stone Standards Track [Page 6]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
- 2. LMTP protocol is used
- or
- SMTP protocol is used and the message has a single recipient
- or
- SMTP protocol is used, the message has multiple recipients, and
- all of them refused message delivery (whether or not Sieve is
- being used).
-
-
- Example:
- require ["reject"];
-
- if size :over 100K {
- reject text:
- Your message is too big. If you want to send me a big attachment,
- put it on a public web site and send me a URL.
- .
- ;
- }
-
- (Pretend that the "reason" string above contains some non-US-ACSII
- text.)
-
- Implementations may use techniques as described in Section 2.1 to
- determine if a non-delivery report should not be sent to a forged
- sender. Implementations SHOULD log instances when a non-delivery
- report is not sent and the reason for not sending the report.
-
-2.2.1. Rejecting a Message by Sending an MDN
-
- The "reject" action resends the received message to the envelope
- sender specified by the MAIL FROM (or Return-Path) address, wrapping
- it in a "reject" form, explaining that it was rejected by the
- recipient.
-
- Note that according to [MDN], Message Disposition Notifications MUST
- NOT be generated if the MAIL FROM (or Return-Path) is empty.
-
- A reject message MUST take the form of a failure MDN as specified by
- [MDN]. The human-readable portion of the message, the first
- component of the MDN, contains the human-readable message describing
- the error, and it SHOULD contain additional text alerting the
- apparent original sender that mail was refused by an email filter.
-
- The MDN disposition-field as defined in the MDN specification MUST be
- "deleted" and MUST have the "MDN-sent-automatically" and "automatic-
- action" modes set (see Section 3.2.6 of [MDN]).
-
-
-
-
-Stone Standards Track [Page 7]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
- In the following script, a message is rejected and returned to the
- sender.
-
- Example:
- require ["reject"];
-
- if header :contains "from" "coyote at desert.example.org" {
- reject text:
- I am not taking mail from you, and I don't
- want your birdseed, either!
- .
- ;
- }
-
- For this script, the first part of the MDN might appear as follows:
-
- ------------------------------------------------------------
- The message was refused by the recipient's mail filtering program.
- The reason given was as follows:
-
- I am not taking mail from you, and I don't want your birdseed,
- either!
- ------------------------------------------------------------
-
-2.3. Silent Upgrade from "reject" to "ereject"
-
- Implementations MUST NOT silently upgrade "reject" actions to
- "ereject" actions in a Sieve script because this might lead to
- unpleasant changes of behavior not expected by the script owner.
-
- User interfaces that present a generic rejection option, and generate
- Sieve script output, MAY switch from generating "reject" to "ereject"
- actions, so long as doing so does not create a confusing change for
- the script owner.
-
- Script generators SHOULD ensure that a rejection action being
- executed as a result of an anti-spam/anti-virus positive test be done
- using the "ereject" action, as it is more suitable for such
- rejections.
-
- Script generators MAY automatically upgrade scripts that previously
- used the "reject" action for anti-spam/anti-virus related rejections.
- Note that such generators MUST make sure that the target environment
- can support the "ereject" action.
-
-
-
-
-
-
-
-Stone Standards Track [Page 8]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
-2.4. Compatibility with Other Actions
-
- This section applies equally to "reject" and "ereject" actions. All
- references to the "reject" action in this section can be replaced
- with the "ereject" action.
-
- A "reject" action cancels the implicit keep.
-
- Implementations MUST prohibit the execution of more than one "reject"
- in a Sieve script.
-
- "reject" MUST be incompatible with the "vacation" [VACATION] action.
- It is NOT RECOMMENDED that implementations permit the use of "reject"
- with actions that cause mail delivery, such as "keep", "fileinto",
- and "redirect".
-
- Making "reject" compatible with actions that cause mail delivery
- violates the RFC 5321 [SMTP] principle that a message is either
- delivered or bounced back to the sender. So bouncing a message back
- (rejecting) and delivering it will make the sender believe that the
- message was not delivered.
-
- However, there are existing laws requiring certain organizations to
- archive all received messages, even the rejected ones. Also, it can
- be quite useful to save copies of rejected messages for later
- analysis.
-
- Any action that would modify the message body will not have an effect
- on the body of any message refused by "reject" using an SMTP response
- code and MUST NOT have any effect on the content of generated DSN/
- MDNs.
-
-2.5. Details of Protocol-Level Refusal
-
- If the "reason" string consists of multiple CRLF separated lines,
- then the reason text MUST be returned as a multiline SMTP/LMTP
- response, per Section 4.2.1 of [SMTP]. Any line MUST NOT exceed the
- SMTP limit on the maximal line length. To make the "reason" string
- conform to any such limits, the server MAY insert CRLFs and turn the
- response into a multiline response.
-
- In the following script (which assumes support for the "spamtest"
- [SPAMTEST] and "fileinto" extensions), messages that test highly
- positive for spam are refused.
-
-
-
-
-
-
-
-Stone Standards Track [Page 9]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
- Example:
- require ["ereject", "spamtest", "fileinto",
- "comparator-i;ascii-numeric"];
-
- if spamtest :value "ge"
- :comparator "i;ascii-numeric" "6" {
- ereject text:
- AntiSpam engine thinks your message is spam.
- It is therefore being refused.
- Please call 1-900-PAY-US if you want to reach us.
- .
- ;
- } elsif spamtest :value "ge"
- :comparator "i;ascii-numeric" "4" {
- fileinto "Suspect";
- }
-
- The following excerpt from an SMTP session shows it in action.
-
- ...
- C: DATA
- S: 354 Send message, ending in CRLF.CRLF.
- ...
- C: .
- S: 550-AntiSpam engine thinks your message is spam.
- S: 550-It is therefore being refused.
- S: 550 Please call 1-900-PAY-US if you want to reach us.
-
- If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES], it MUST
- prepend an appropriate Enhanced Error Code to the "reason" text.
- Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED.
- With an Enhanced Error Code, the response to a DATA command in the
- SMTP example below will look like:
-
- S: 550-5.7.1 AntiSpam engine thinks your message is spam.
- S: 550-5.7.1 It is therefore being refused.
- S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us.
-
- if the server selected "5.7.1" as appropriate.
-
- If a Sieve implementation that supports "ereject" does not wish to
- immediately disclose the reason for rejection (for example, that it
- detected spam), it may delay immediately sending of the 550 error
- code by sending a 4XX error code on the first attempt to receive the
- message.
-
-
-
-
-
-
-Stone Standards Track [Page 10]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
-3. Changes from RFC 3028
-
- Clarified that the "reject" action cancels the implicit keep.
- Extended the list of allowable actions on "reject" to include
- protocol-level message rejection.
-
- Added the "ereject" action that is similar to "reject", but will
- always favor protocol-level message rejection.
-
-4. Security Considerations
-
- The introduction to this document discusses why rejecting messages
- before delivery is better than accepting and bouncing them.
-
- While the details of techniques that can be used to determine when to
- silently drop a non-delivery report are outside the scope of this
- document, the explicit permission this document gives to take such
- action may enable denial-of-service situations. Techniques such as
- spam-checking, return-path verification, and others, can and do have
- false-positives. Care should be exercised to prevent the loss of
- legitimate messages by failing to notify the sender of non-delivery.
-
- Security issues associated with email auto-responders are fully
- discussed in the Security Considerations section of [RFC3834]. This
- document is not believed to introduce any additional security
- considerations in this general area.
-
- The "ereject" extension does not raise any other security
- considerations that are not already present in the base [SIEVE]
- specification, and these issues are discussed in [SIEVE].
-
-5. IANA Considerations
-
- The following section provides the IANA registrations for the Sieve
- extensions specified in this document.
-
-5.1. "reject" Extension Registration
-
- IANA is requested to update the registration for the Sieve "reject"
- extension as detailed below:
-
- Capability name: reject
- Description: adds the "reject" action for refusing delivery
- of a message. The exact reason for refusal is
- conveyed back to the client.
- RFC number: RFC 5429
- Contact address: the Sieve discussion list <ietf-mta-filters at imc.org>
-
-
-
-
-Stone Standards Track [Page 11]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
-5.2. "ereject" Extension Registration
-
- IANA is requested to replace the preliminary registration of the
- Sieve refuse extension with the following registration:
-
- Capability name: ereject
- Description: adds the "ereject" action for refusing delivery
- of a message. The refusal should happen as early
- as possible (e.g., at the protocol level) and might
- not preserve the exact reason for refusal if it
- contains non-US-ASCII text.
- RFC number: RFC 5429
- Contact address: the Sieve discussion list <ietf-mta-filters at imc.org>
-
-6. References
-
-6.1. Normative References
-
- [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message
- Format for Delivery Status Notifications",
- RFC 3464, January 2003.
-
- [ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning
- Enhanced Error Codes", RFC 2034, October 1996.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [LMTP] Myers, J., "Local Mail Transfer Protocol",
- RFC 2033, October 1996.
-
- [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition
- Notification", RFC 3798, May 2004.
-
- [REPORT] Vaudreuil, G., "The Multipart/Report Content Type
- for the Reporting of Mail System Administrative
- Messages", RFC 3462, January 2003.
-
- [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email
- Filtering Language", RFC 5228, January 2008.
-
- [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
- RFC 5321, October 2008.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
-
-
-
-
-
-Stone Standards Track [Page 12]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
- [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering:
- Vacation Extension", RFC 5230, January 2008.
-
-6.2. Informative References
-
- [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work
- in Progress, October 2008.
-
- [Joe-DoS] Frei, S., Silvestri, I., and G. Ollman, "Mail Non-
- Delivery Notice Attacks", April 2004, <http://
- www.techzoom.net/papers/
- mail_non_delivery_notice_attacks_2004.pdf>.
-
- [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language",
- RFC 3028, January 2001.
-
- [RFC3834] Moore, K., "Recommendations for Automatic Responses
- to Electronic Mail", RFC 3834, August 2004.
-
- [SPAMTEST] Daboo, C., "Sieve Email Filtering: Spamtest and
- Virustest Extensions", RFC 5235, January 2008.
-
- [UTF8-RESP] Melnikov, A., "SMTP Language Extension", Work
- in Progress, June 2007.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stone Standards Track [Page 13]
-
-RFC 5429 Sieve Extension: Reject March 2009
-
-
-Appendix A. Acknowledgements
-
- Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner,
- Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens
- for comments and corrections.
-
- The authors gratefully acknowledge the extensive work of Tim
- Showalter as the author of the RFC 3028, which originally defined the
- "reject" action.
-
-Appendix B. Contributors
-
- Matthew Elvey
- The Elvey Partnership, LLC
- 1819 Polk Street, Suite 133
- San Francisco, CA 94109
- USA
-
- EMail: matthew at elvey.com
-
-
- Alexey Melnikov
- Isode Limited
- 5 Castle Business Village
- 36 Station Road
- Hampton, Middlesex TW12 2BX
- UK
-
- EMail: Alexey.Melnikov at isode.com
-
-Author's Address
-
- Aaron Stone (editor)
- Serendipity
- 260 El Verano Ave
- Palo Alto, CA 94306
- USA
-
- EMail: aaron at serendipity.palo-alto.ca.us
-
-
-
-
-
-
-
-
-
-
-
-
-Stone Standards Track [Page 14]
-
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-mozext/sieve-extension.git
More information about the Pkg-mozext-commits
mailing list