diff options
| author | Thomas Schmid <schmid-thomas@gmx.net> | 2018-11-17 18:04:50 +0300 |
|---|---|---|
| committer | Thomas Schmid <schmid-thomas@gmx.net> | 2018-11-17 18:04:50 +0300 |
| commit | c7968fa58bc19aabe75dc218de6a0f1aa4046127 (patch) | |
| tree | ecdcf605c83cda8648912b8f611bad208db17ea3 /docs | |
| parent | e16701c05a94ed7f3c865e1a6f47f66ee7e8ea4f (diff) | |
Remove outdated files
Diffstat (limited to 'docs')
| -rwxr-xr-x | docs/draft-ietf-sieve-imapflags-05.txt | 736 | ||||
| -rwxr-xr-x | docs/draft-melnikov-sieve-imapflags-03.txt | 434 | ||||
| -rwxr-xr-x | docs/rfc3431.txt | 451 | ||||
| -rwxr-xr-x | docs/rfc3598.txt | 339 |
4 files changed, 0 insertions, 1960 deletions
diff --git a/docs/draft-ietf-sieve-imapflags-05.txt b/docs/draft-ietf-sieve-imapflags-05.txt deleted file mode 100755 index 53436d42..00000000 --- a/docs/draft-ietf-sieve-imapflags-05.txt +++ /dev/null @@ -1,736 +0,0 @@ -Network Working Group -Internet Draft: Sieve -- IMAP flag Extension A. Melnikov -Document: draft-ietf-sieve-imapflags-05.txt Isode Limited -Expires: November 2006 May 2006 - - - SIEVE Email Filtering: IMAP flag Extension - - -Status of this memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress". - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - -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 to set both - IMAP system flags and IMAP keywords. - - -0. Meta-information on this draft - - This information is intended to facilitate discussion. It will be - removed when this document leaves the Internet-Draft stage. - - -0.1. Discussion - - This draft defines an extension to the Sieve mail filtering - language (RFC 3028) being discussed on the MTA Filters - mailing list at <ietf-mta-filters@imc.org>. Subscription requests - can be sent to <ietf-mta-filters-request@imc.org> (send an email - message with the word "subscribe" in the body). More information on - the mailing list along with a WWW archive of back messages is - available at <http://www.imc.org/ietf-mta-filters/>. - - -0.2. Changes from the version submitted to the Sieve mailing list - - 1. Added addflag and removeflag actions - - 2. Changed the semantics of setflag (setflag is not additive any - more) - - 3. Corrected section "Interaction with Other Sieve Actions". - Removed incorrect reference to the forward action as to an - action that prohibits setflag. - - 4. Added paragraph about the mutual order of "fileinto"/"keep" and - "setflag"/"addflag"/"removeflag" actions. - - -0.3. Changes from the revision 00 - - 1. Corrected Capability Identifier section (Section 2) - - 2. Corrected "Interaction with Other Sieve Actions" section - (Section 4) - - 3. Examples were updated to be compatible with Sieve-07 draft - - 4. Added "mark" and "unmark" actions - - -0.4. Changes from the revision 01 - - 1. Some language fixes based on Tony Hansen comments - - 2. Clarified that the extension allows to set both IMAP System - Flags and Keywords - - -0.5. Changes from the revision 02 - - 1. BugFix: all backslashes must be escaped - - 2. Added extended example and more detailed description of - "addflag"/"removeflag" additivity. - - 3. Minor example bugfixes - - -0.6. Changes from the revision 03 - - 1. Added second way to specify flags to be set (via optional tagged - arguments). [Tim Showalter] - - 2. Rules for using Reject with imapflags relaxed. [Randall Gellens] - - 3. Removed ABNF section completely, added syntax description to - action definition. [Tim Showalter] - - 4. Cleaned up the example. [Ken Murchison] - - 5. Added FM (Flag Manupulation) acronym. - - 6. Clarified "mark"/"unmark" bahavior. [Randall Gellens] - - -0.7. Changes from the revision 04 - - 1. "Interaction with Other Sieve Actions" was simplified based on - comments from Tim Showalter. Added sentence saying that - imapflags doesn't change an implicit keep. - - 2. Several editorial comments from Tim Showalter. - -0.8. Changes from the revision 05 - - 1. Updated copyright, author address, section numbers and references. - - 2. Added dependency on Sieve "variables" extension. - - 3. Several editorial comments from Matthew Elvey. - - 4. Removed "mark" and "unmark" actions. - - 5. Added "hasflag" test. - - 6. Dropped ":globalflags" - - 7. An invalid flag name doesn't cause a script execution failure - anymore, as imapflags now depends on variables and a variable - can have an arbitrary value. - -0.9. Changes from the revision 06 (draft-ietf-sieve-imapflags-00.txt) - - 1. Updated boilerplate and references. - - 2. Fixed capability string in the extended example. - - 3. Improved implementation using macros (section 6). - -0.10. Changes from draft-ietf-sieve-imapflags-00.txt - - 1. Added back the internal variable, made the variable parameter - to all actions optional. - - 2. Some editorial suggestions from Mark E. Mallett. - - 3. Updated boilerplate once again. - - -0.11. Changes from draft-ietf-sieve-imapflags-01.txt - - 1. Clarified that if "variables" is not available, then usage of - the explicit variable parameter causes a runtime error. - - 2. Clarified handling of spaces, in particular that leading/ - trailing spaces in a flag variable are to be ignored. - - 3. Clarified that the extension can't be used to set the \Recent - flag. - - 4. Made the variable list parameter to hasflag test optional, for - consistency with all actions. - - 5. Dropped the "Implementation Notes" section. - - 6. Fixed an error in section 5: when the :flags tagged argument is - not specified, the correct behavior is to use flags from the - internal variable. - - 7. Other minor editorial changes. - -0.12. Changes from draft-ietf-sieve-imapflags-02.txt - - 1. Changed "Syntax:" label to "Usage:". - - 2. Updated the Introduction section to mention that hasflag also has - an optional parameter. - - 3. Clarified that a failure to store flags for a message is not - a runtime error. - - 4. Minor editorial nits from Philip. - - 5. Addressed ID nits. - -0.13. Changes from draft-ietf-sieve-imapflags-03.txt - - 1. Minor editorial changes from Ken. - - 2. Added IANA Considerations section. - - 3. Clarified "hasflag" behaviour with :matches, :contains, etc. - - 4. Added optional comparator field to "hasflag" test, for - consistency with other extensions. - - 5. Clarified interaction of hasflag with the relational extension. - -0.14. Changes from draft-ietf-sieve-imapflags-04.txt - - 1. Extended an example in section 4. - - 2. Fixed several typos. - - 3. Changed some examples to show that some parameters are optional - (Cyrus) - - 4. Addressed comments raised during IESG evaluation, in particular: - - Clarified that space is used as delimiter between flag names. - - Described capabilities provided by the extension as they are - visible to end users. - - -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 if a flag belongs to a list. - - From user's prospective this extension provides several - capabilities. First, it allows manipulation of sets of IMAP flags. - Second, it gives 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 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 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]. - -2. 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. - - -2.1. General requirements for flag handling - - The following notes apply to processing of Addflag/Removeflag/Setflag - actions, hasflag test and :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 be - always 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, 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 which 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 space-separated list of flag names. - - Any of 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]. - - 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 2 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. Setflag Action - - 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: - - Example: - if header :contains "from" "boss@frobnitzm.example.edu" { - setflag "flagvar" "\\Flagged"; - fileinto :flags "${flagvar}" "INBOX.From Boss"; - } - - -3.2. Addflag action - - 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. - - The following examples demonstrate requirements described in 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. Removeflag Action - - 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 occurences 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@example.com" { - addflag "flagvar" "$MDNRequired"; - } - if header :contains "from" "imap@cac.washington.example.edu" { - removeflag "flagvar" "$MDNRequired"; - fileinto :flags "${flagvar}" "INBOX.imap-list"; - } - - -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 be also 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. - - 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 - alter 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 message - to the target mailbox. - - Usage: ":flags" <list-of-flags: string-list> - - The copy of the message filed into 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. - - -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 the [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@iana.org - Subject: Registration of new Sieve extension - - Capability name: imap4flags - Capability keyword: imap4flags - Capability arguments: N/A - Standards Track/IESG-approved experimental RFC number: - this RFC - Person and email address to contact for further information: - Alexey Melnikov - <alexey.melnikov@isode.com> - - This information should be 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 - # - if size :over 1M - { - addflag "MyFlags" "Big"; - if header :is "From" "boss@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@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@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 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"] "me@company.example.com", - header :matches "subject" - ["*make*money*fast*", "*university*dipl*mas*"]) - { - 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 which took place on and off the Sieve mailing list. - - The help of those who took the time to review the draft 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. Author's Address - - Alexey Melnikov - Isode Limited - - 5 Castle Business Village - Hampton, Middlesex - United Kingdom, TW12 2BX - - Email: alexey.melnikov@isode.com - - -12. Normative References - - [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering - Language", work in progress, I-D draft-ietf-sieve-3028bis. - - [KEYWORDS] Bradner, S., "Keywords for use in RFCs to Indicate - Requirement Levels", Harvard University, RFC 2119, March 1997. - - [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION - 4rev1", University of Washington, RFC 3501, March 2003. - - [VARIABLES] Homme, K. T., "Sieve -- Variables Extension", University - of Oslo, work in progress, draft-ietf-sieve-variables-XX.txt - - [RELATIONAL] Leiba, B. and Segmuller, W., "Sieve Extension: - Relational Tests", Work in Progress, draft-ietf-sieve-3431bis-XX.txt - - -13. Intellectual Property Statement - - 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@ietf.org. - - -14. Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - 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 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. diff --git a/docs/draft-melnikov-sieve-imapflags-03.txt b/docs/draft-melnikov-sieve-imapflags-03.txt deleted file mode 100755 index f714b44a..00000000 --- a/docs/draft-melnikov-sieve-imapflags-03.txt +++ /dev/null @@ -1,434 +0,0 @@ -Network Working Group -Internet Draft: Sieve -- IMAP flag Extension A. Melnikov -Document: draft-melnikov-sieve-imapflags-03.txt Messaging Direct, Ltd. -Expires: January 2001 July 2000 - - - Sieve -- IMAP flag Extension - - -Status of this memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are - working documents of the Internet Engineering Task Force (IETF), its - areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet- Drafts as - reference material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - The protocol discussed in this document is experimental and subject - to change. Persons planning on either implementing or using this - protocol are STRONGLY URGED to get in touch with the author before - embarking on such a project. - -Copyright - - Copyright (C) The Internet Society 2000. All Rights Reserved. - -Abstract - - Recent discussions have shown that it is desirable to set - different [IMAP] 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 to set both - [IMAP] system flags and [IMAP] keywords. - - -0. Meta-information on this draft - - This information is intended to facilitate discussion. It will be - removed when this document leaves the Internet-Draft stage. - - -0.1. Discussion - - This draft is intended to be compared with the Sieve mail filtering - language, an Internet-Draft being discussed on the MTA Filters - mailing list at <ietf-mta-filters@imc.org>. Subscription requests - can be sent to <ietf-mta-filters-request@imc.org> (send an email - message with the word "subscribe" in the body). More information on - the mailing list along with a WWW archive of back messages is - available at <http://www.imc.org/ietf-mta-filters/>. - - -0.2. Changes from the version submitted to the SIEVE mailing list - - 1. Added addflag and removeflag actions - - 2. Changed the semantics of setflag (setflag is not additive any more) - - 3. Corrected section "Interaction with Other Sieve Actions". - Removed incorrect reference to the forward action as to an - action that prohibits setflag. - - 4. Added paragraph about the mutual order of fileinto/keep and - setflag/addflag/removeflag actions. - - -0.3. Changes from the revision 00 - - 1. Corrected Capability Identifier section (Section 2) - - 2. Corrected "Interaction with Other Sieve Actions" section (Section 4) - - 3. Examples were updated to be compatible with Sieve-07 draft - - 4. Added "mark" and "unmark" actions - - -0.4. Changes from the revision 01 - - 1. Some language fixes based on Tony Hansen comments - - 2. Clarified that the extension allows to set both IMAP System - Flags and Keywords - - -0.5. Changes from the revision 02 - - 1. BugFix: all backslashes must be escaped - - 2. Added extended example and more detailed description of - addflag/removeflag additivity. - - 3. Minor example bugfixes - - -1. Introduction - - This is an extension to the Sieve language defined by [SIEVE] for - setting [IMAP] flags. It defines several new actions "setflag", - "addflag", "removeflag", "mark" and "unmark". - - 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. - - SIEVE interpreters that don't support integration with IMAP - SHOULD ignore this extension. - - Conventions for notations are as in [SIEVE] section 1.1, including - use of [KEYWORDS]. - - -2. Capability Identifier - - The capability string associated with extension defined in this document - is "imapflags". - - -3. Actions - - All actions described in this specification (setflag, addflag, removeflag, - mark, unmark) operate on an internal variable that contains the set - of [IMAP] flags associated with the message being delivered. When - the interpreter starts executing a script this variable contains an - empty set. The 'addflag' action adds flags to the existing set. The - 'removeflag' action removes flags from the existing set. The - 'setflag' action replaces the existing set of flags with a new set. - Whenever the interpreter encounters a 'fileinto' or 'keep' action - it files the message with the current set of flags. - - -3.1. Setflag Action - - Syntax: setflag <list-of-flags> - - Setflag is used for setting [IMAP] system flags or keywords. Setflag - replaces any previously set flags. It should be used - together with keep or fileinto. It MUST be ignored if mailstore - or target mailbox doesn't support the storing of any flags. - - Flags can be set only for the message that is currently being - processed by SIEVE. When called with keep, setflag sets flags in - the user's main mailbox. When called with fileinto, setflag - sets flags in the mailbox indicated by the parameter. - - The order of setflag/fileinto or setflag/keep is important in the - script. Any setflag action applies only to subsequent fileinto/keep - actions in a script till next occurence of - setflag/addflag/removeflag/mark/unmark. - - Server MUST ignore all flags that it can't store permanently. This - means, in particular, that if the user's main mailbox can't store any - flags, then the following SIEVE script produces no actions - - Example: if size :over 500K { - setflag "\\Deleted"; - } - - A more substantial example is: - - Example: - if header :contains "from" "boss@frobnitzm.edu" { - setflag "\\Flagged"; - fileinto "INBOX.From Boss"; - } - - -3.2. Addflag action - - Syntax: addflag <list-of-flags> - - Addflag is used for setting [IMAP] flags. However unlike setflag it - doesn't replace any previously set flags. This means that multiple - occurrences of addflag are treated additively. - - For example, the following two actions - - addflag "\\Deleted"; - addflag "\\Answered"; - - produce the same result as the single action - - addflag ["\\Deleted", "\\Answered"]; - - In all other respects addflag behaves the same way as - setflag. - - -3.3. Removeflag Action - - Syntax: removeflag <list-of-flags> - - Removeflag is used for setting [IMAP] flags. Removeflag clears - flags previously set by setflag/addflag. Calling removeflag with a - flag that wasn't set before is not an error and is ignored. - Multiple occurrences of removeflag are treated additively. - - In all other respects removeflag behaves the same way as - setflag. - - Example: - if header :contains "Disposition-Notification-To" "mel@example.com" { - addflag "$MDNRequired"; - } - if header :contains "from" "imap@cac.washington.edu" { - removeflag "$MDNRequired"; - fileinto "INBOX.imap-list"; - } - - -3.4. Mark and Unmark Actions - - Syntax: mark - - Syntax: unmark - - The mark action allows a message to be marked as urgent. - Implementers are free to choose any flag or any combination of - [IMAP] flags, however it is RECOMMENDED that the [IMAP] - \Flagged flag be used. The mark action is semantically - equivalent to 'addflag "\\Flagged"'. - - The unmark action allows the flag previously set by the Mark - action to be unset. Unmark SHOULD at least clear the [IMAP] \Flagged flag - and MUST clear all flags that could be added with mark. Unmark MAY - clear other flags as well. The unmark action is semantically - equivalent to 'removeflag "\\Flagged"'. - - -3.5 Extended example - - # - # Example Sieve Filter - # Declare any optional features or extension used by the script - # - require ["fileinto", "reject", "imapflags"]; - - # - # Reject any large messages - # - if size :over 1M - { - if header :is "From" "boss@company.com" - { - addflag "\\Flagged $Big"; - # The message will be marked as "\Flagged $Big" when filed into - # mailbox "Big messages" - } - fileinto "Big messages"; - } - - if header :is "From" "grandma@example.net" - { - addflag ["\\Answered", "$MDNSent"]; - # If the message is bigger than 1Mb it will be marked as "\Flagged - # $Big \Answered $MDNSent" - # when filed into mailbox "grandma". If the message is shorter than - # 1Mb it will be marked as "\Answered $MDNSent" - fileinto "GrandMa"; # move to "GrandMa" folder - } - - # - # Handle messages from known mailing lists - # Move messages from IETF filter discussion list to filter folder - # - if header :is "Sender" "owner-ietf-mta-filters@imc.org" - { - setflag "\\Flagged"; - # Message will always have just "\Flagged" flag - keep; - } - - # - # Keep all messages to or from people in my company - # - elsif anyof address :domain :is ["From", "To"] "company.com" - { - keep; # keep in "In" folder - } - # - # 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@company.com", - header :matches "subject" - ["*make*money*fast*", "*university*dipl*mas*"]) - { - removeflag "\\Flagged"; - # If message header does not contain my address, - # it's from a list. - fileinto "spam"; # move to "spam" folder - } - else - { - # Move all other (non-company) mail to "personal" - # folder. - fileinto "personal"; - } - - - -4. Interaction with Other Sieve Actions - - Sieve actions sometimes prohibit each other in order to make - filtering scripts less likely to cause serious problems. - - It is strongly discouraged to use - setflag/addflag/removeflag/mark/unmark actions together with - reject, because that action doesn't allow keeping a received message. - - The SIEVE interpreter MUST ignore any - setflag/addflag/removeflag/mark/unmark commands when they are used - with reject. The SIEVE interpreter MUST ignore these commands when - no keep (implicit or explicit) or fileinto actions will be taken. - - A SIEVE verifier SHOULD reject a script that contains a - setflag/addflag/removeflag/mark/unmark action together with reject. - - -5. Other Considerations - - This extension intentionally doesn't allow setting [IMAP] flags on an - arbitrary message in the [IMAP] message store. - - -6. Security Considerations - - Security considerations are discussed in the [IMAP] and [SIEVE]. - It is belived that this extension doesn't introduce any - additional security concerns. - - -7. Formal Grammar - - The grammar used in this section is the same as the ABNF described in - [ABNF]. - - action =/ setflag / addflag / removeflag / mark / unmark - - setflag = "setflag" WSP string-list - ;; a list of [IMAP] flags - - addflag = "addflag" WSP string-list - ;; a list of [IMAP] flags - - removeflag = "removeflag" WSP string-list - ;; a list of [IMAP] flags - - mark = "mark" - - unmark = "unmark" - - -8. Acknowledgments - - This document has been revised in part based on comments and - discussions which took place on and off the SIEVE mailing list. - The help of those who took the time to review the draft and make - suggestions is appreciated, especially that of Tim Showalter, - Barry Leiba, and Randall Gellens. Special thanks to Tony Hansen, - David Lamb and Roman Migal for helping me explain better the concept. - - -9. Author's Address - - Alexey Melnikov - Messaging Direct, Ltd. - - Address : #900, 10117 Jasper Avenue, Edmonton, Alberta, Canada, - T5J1W8 - - Email: mel@messagingdirect.com - - -Appendices - -Appendix A. References - - [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint, - Work in Progress, draft-showalter-sieve-XX.txt - - [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", - Internet Mail Consortium, RFC 2234, November, 1997. - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", Harvard University, RFC 2119, March 1997. - - [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", - University of Washington, RFC 2060, December 1996. - - -Appendix B. Full Copyright Statement - - Copyright (C) The Internet Society 2000. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. diff --git a/docs/rfc3431.txt b/docs/rfc3431.txt deleted file mode 100755 index 2bf17bdb..00000000 --- a/docs/rfc3431.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group W. Segmuller -Request for Comment: 3431 IBM T.J. Watson Research Center -Category: Standards Track December 2002 - - - Sieve Extension: Relational Tests - -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) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document describes the RELATIONAL extension to the Sieve mail - filtering language defined in RFC 3028. This extension extends - existing conditional tests in Sieve to allow relational operators. - In addition to testing their content, it also allows for testing of - the number of entities in header and envelope fields. - -1 Introduction - - Sieve [SIEVE] is a language for filtering e-mail messages at the time - of final delivery. It is designed to be implementable on either a - mail client or mail server. It is meant to be extensible, simple, - and independent of access protocol, mail architecture, and operating - system. 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 Messages Access Protocol (IMAP) servers, as it has no - variables, loops, nor the ability to shell out to external programs. - - The RELATIONAL extension provides relational operators on the - address, envelope, and header tests. This extension also provides a - way of counting the entities in a message header or address field. - - With this extension, the sieve script may now determine if a field is - greater than or less than a value instead of just equivalent. One - use is for the x-priority field: move messages with a priority - greater than 3 to the "work on later" folder. Mail could also be - sorted by the from address. Those userids that start with 'a'-'m' go - to one folder, and the rest go to another folder. - - - -Segmuller Standards Track [Page 1] - -RFC 3431 Sieve Extension: Relational Tests December 2002 - - - The sieve script can also determine the number of fields in the - header, or the number of addresses in a recipient field. For - example: are there more than 5 addresses in the to and cc 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 BCP 14, RFC 2119. - - Conventions for notations are as in [SIEVE] section 1.1, including - the use of [KEYWORDS] and "Syntax:" label for the definition of - action and tagged arguments syntax, and the use of [ABNF]. - - The capability string associated with extension defined in this - document is "relational". - -3 Comparators - - This document does not define any comparators or exempt any - comparators from the require clause. Any comparator used, other than - "i;octet" and "i;ascii-casemap", MUST be declared a require clause as - defined in [SIEVE]. - - The "i;ascii-numeric" comparator, as defined in [ACAP], MUST be - supported for any implementation of this extension. The comparator - "i;ascii-numeric" MUST support at least 32 bit unsigned integers. - - Larger integers MAY be supported. Note: the "i;ascii-numeric" - comparator does not support negative numbers. - -4 Match Type - - This document defines two new match types. They are the VALUE match - type and the COUNT match type. - - The syntax is: - - MATCH-TYPE =/ COUNT / VALUE - - COUNT = ":count" relational-match - - VALUE = ":value" relational-match - - relational-match = DQUOTE ( "gt" / "ge" / "lt" - / "le" / "eq" / "ne" ) DQUOTE - - - - - -Segmuller Standards Track [Page 2] - -RFC 3431 Sieve Extension: Relational Tests December 2002 - - -4.1 Match Type Value - - The VALUE match type does a relational comparison between strings. - - The VALUE match type may be used with any comparator which returns - sort information. - - Leading and trailing white space MUST be removed from the value of - the message for the comparison. White space is defined as - - SP / HTAB / CRLF - - A value from the message is considered the left side of the relation. - A value from the test expression, the key-list for address, envelope, - and header tests, is the right side of the relation. - - If there are multiple values on either side or both sides, the test - is considered true, if any pair is true. - -4.2 Match Type Count - - The COUNT match type first determines the number of the specified - entities in the message and does a relational comparison of the - number of entities to the values specified in the test expression. - - The COUNT match type SHOULD only be used with numeric comparators. - - The Address Test counts the number of recipients in the specified - fields. Group names are ignored. - - The Envelope Test counts the number of recipients in the specified - envelope parts. The envelope "to" will always have only one entry, - which is the address of the user for whom the sieve script is - running. There is no way a sieve script can determine if the message - was actually sent to someone else using this test. The envelope - "from" will be 0 if the MAIL FROM is blank, or 1 if MAIL FROM is not - blank. - - The Header Test counts the total number of instances of the specified - fields. This does not count individual addresses in the "to", "cc", - and other recipient fields. - - In all cases, if more than one field name is specified, the counts - for all specified fields are added together to obtain the number for - comparison. Thus, specifying ["to", "cc"] in an address COUNT test, - comparing the total number of "to" and "cc" addresses; if separate - counts are desired, they must be done in two comparisons, perhaps - joined by "allof" or "anyof". - - - -Segmuller Standards Track [Page 3] - -RFC 3431 Sieve Extension: Relational Tests December 2002 - - -5 Security Considerations - - Security considerations are discussed in [SIEVE]. - - An implementation MUST ensure that the test for envelope "to" only - reflects the delivery to the current user. It MUST not be possible - for a user to determine if this message was delivered to someone else - using this test. - -6 Example - - Using the message: - - received: ... - received: ... - subject: example - to: foo@example.com.invalid, baz@example.com.invalid - cc: qux@example.com.invalid - - The test: - - address :count "ge" :comparator "i;ascii-numeric" ["to", "cc"] - ["3"] - - would be true and the test - - anyof ( address :count "ge" :comparator "i;ascii-numeric" - ["to"] ["3"], - address :count "ge" :comparator "i;ascii-numeric" - ["cc"] ["3"] ) - - would be false. - - To check the number of received fields in the header, the - following test may be used: - - header :count "ge" :comparator "i;ascii-numeric" - ["received"] ["3"] - - This would return false. But - - header :count "ge" :comparator "i;ascii-numeric" - ["received", "subject"] ["3"] - - would return true. - - - - - - -Segmuller Standards Track [Page 4] - -RFC 3431 Sieve Extension: Relational Tests December 2002 - - - The test: - - header :count "ge" :comparator "i;ascii-numeric" - ["to", "cc"] ["3"] - - will always return false on an RFC 2822 compliant message [RFC2822], - since a message can have at most one "to" field and at most one "cc" - field. This test counts the number of fields, not the number of - addresses. - -7 Extended Example - - require ["relational", "comparator-i;ascii-numeric"]; - - if header :value "lt" :comparator "i;ascii-numeric" - ["x-priority"] ["3"] - { - fileinto "Priority"; - } - - elseif address :count "gt" :comparator "i;ascii-numeric" - ["to"] ["5"] - { - # everything with more than 5 recipients in the "to" field - # is considered SPAM - fileinto "SPAM"; - } - - elseif address :value "gt" :all :comparator "i;ascii-casemap" - ["from"] ["M"] - { - fileinto "From N-Z"; - } else { - fileinto "From A-M"; - } - - if allof ( address :count "eq" :comparator "i;ascii-numeric" - ["to", "cc"] ["1"] , - address :all :comparator "i;ascii-casemap" - ["to", "cc"] ["me@foo.example.com.invalid"] - { - fileinto "Only me"; - } - - - - - - - - -Segmuller Standards Track [Page 5] - -RFC 3431 Sieve Extension: Relational Tests December 2002 - - -8 IANA Considerations - - The following template specifies the IANA registration of the Sieve - extension specified in this document: - - To: iana@iana.org - Subject: Registration of new Sieve extension - - Capability name: RELATIONAL - Capability keyword: relational - Capability arguments: N/A - Standards Track/IESG-approved experimental RFC number: this RFC - Person and email address to contact for further information: - Wolfgang Segmuller - IBM T.J. Watson Research Center - 30 Saw Mill River Rd - Hawthorne, NY 10532 - - Email: whs@watson.ibm.com - - This information should be added to the list of sieve extensions - given on http://www.iana.org/assignments/sieve-extensions. - -9 References - -9.1 Normative References - - [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC - 3028, January 2001. - - [Keywords] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: - ABNF", RFC 2234, November 1997. - - [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April - 2001. - -9.2 Non-Normative References - - [ACAP] Newman, C. and J. G. Myers, "ACAP -- Application - Configuration Access Protocol", RFC 2244, November 1997. - - - - - - - - -Segmuller Standards Track [Page 6] - -RFC 3431 Sieve Extension: Relational Tests December 2002 - - -10 Author's Address - - Wolfgang Segmuller - IBM T.J. Watson Research Center - 30 Saw Mill River Rd - Hawthorne, NY 10532 - - EMail: whs@watson.ibm.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Segmuller Standards Track [Page 7] - -RFC 3431 Sieve Extension: Relational Tests December 2002 - - -11 Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Segmuller Standards Track [Page 8] - diff --git a/docs/rfc3598.txt b/docs/rfc3598.txt deleted file mode 100755 index 3bbc5976..00000000 --- a/docs/rfc3598.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group K. Murchison -Request for Comments: 3598 Oceana Matrix Ltd. -Category: Standards Track September 2003 - - - Sieve Email Filtering -- Subaddress 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. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - On email systems that allow for "subaddressing" or "detailed - addressing" (e.g., "ken+sieve@example.org"), it is sometimes - desirable to make comparisons against these sub-parts of addresses. - This document defines an extension to the Sieve mail filtering - language that allows users to compare against the user and detail - parts of an address. - -Table of Contents - - 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 2 - 3. Subaddress Comparisons. . . . . . . . . . . . . . . . . . . . 2 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 - 6. Normative References. . . . . . . . . . . . . . . . . . . . . 4 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 - 8. Intellectual Property Statement . . . . . . . . . . . . . . . 5 - 9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 5 - 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 6 - - - - - - - - - - - -Murchison Standards Track [Page 1] - -RFC 3598 Sieve Email Filtering September 2003 - - -1. Introduction - - Subaddressing is the practice of appending some "detail" information - to the local-part of an [IMAIL] address to indicate that the message - should be delivered to the mailbox specified by the "detail" - information. The "detail" information is prefixed with a special - "separator character" (typically "+") which forms the boundary - between the "user" (original local-part) and the "detail" sub-parts - of the address, much like the "@" character forms the boundary - between the local-part and domain. - - Typical uses of subaddressing might be: - - - A message addressed to "ken+sieve@example.org" is delivered into a - mailbox called "sieve" belonging to the user "ken". - - - A message addressed to "5551212#123@example.org" is delivered to - the voice mailbox number "123" at phone number "5551212". - - This document describes an extension to the Sieve language defined by - [SIEVE] for comparing against the "user" and "detail" sub-parts of an - address. - - Conventions for notations are as in [SIEVE] section 1.1, including - use of [KEYWORDS]. - -2. Capability Identifier - - The capability string associated with the extension defined in this - document is "subaddress". - -3. Subaddress Comparisons - - Commands that act exclusively on addresses may take the optional - tagged arguments ":user" and ":detail" to specify what sub-part of - the local-part of the address will be acted upon. - - NOTE: In most cases, the envelope "to" address is the preferred - address to examine for subaddress information when the desire is to - sort messages based on how they were addressed so as to get to a - specific recipient. The envelope address is, after all, the reason a - given message is being processed by a given sieve script for a given - user. This is particularly true when mailing lists, aliases, and - "virtual domains" are involved since the envelope may be the only - source of detail information for the specific recipient. - - - - - - -Murchison Standards Track [Page 2] - -RFC 3598 Sieve Email Filtering September 2003 - - - The ":user" argument specifies that sub-part of the local-part which - lies to the left of the separator character (e.g., "ken" in - "ken+sieve@example.org"). If no separator character exists, then - ":user" specifies the entire left-side of the address (equivalent to - ":localpart"). - - The ":detail" argument specifies that sub-part of the local-part - which lies to the right of the separator character (e.g., "sieve" in - "ken+sieve@example.org"). If no separator character exists, the test - evaluates to false. If nothing lies to the right of the separator - character, then ":detail" ":is" the null key (""). Otherwise, the - ":detail" sub-part contains the null key. - - Implementations MUST make sure that the separator character matches - that which is used and/or allowed by the encompassing mail system, - otherwise unexpected results might occur. Implementations SHOULD - allow the separator character to be configurable so that they may be - used with a variety of mail systems. Note that the mechanisms used - to define and/or query the separator character used by the mail - system are outside the scope of this document. - - The ":user" and ":detail" address parts are subject to the same rules - and restrictions as the standard address parts defined in [SIEVE]. - For convenience, the "ADDRESS-PART" syntax element defined in [SIEVE] - is augmented here as follows: - - ADDRESS-PART =/ ":user" / ":detail" - - A diagram showing the ADDRESS-PARTs of a email address utilizing a - separator character of '+' is shown below: - - :user "+" :detail "@" :domain - `-----------------' - :local-part - - Example: - - require "subaddress"; - - # File mailing list messages (subscribed as "ken+mta-filters"). - if envelope :detail "to" "mta-filters" { - fileinto "inbox.ietf-mta-filters"; - } - - # If a message is not to me (ignoring +detail), junk it. - if not allof (address :user ["to", "cc", "bcc"] "ken", - address :domain ["to", "cc", "bcc"] "example.org") { - discard; - - - -Murchison Standards Track [Page 3] - -RFC 3598 Sieve Email Filtering September 2003 - - - } - - # Redirect all mail sent to +foo. - if envelope :detail ["to", "cc", "bcc"] "foo" { - redirect "ken@example.edu"; - } - -4. Security Considerations - - Security considerations are discussed in [SIEVE]. It is believed - that this extension does not introduce any additional security - concerns. - -5. IANA Considerations - - The following template specifies the IANA registration of the Sieve - extension specified in this document: - - To: iana@iana.org - Subject: Registration of new Sieve extension - - Capability name: subaddress - Capability keyword: subaddress - Capability arguments: N/A - Standards Track/RFC 3598 - Person and email address to contact for further information: - - Kenneth Murchison - ken@oceana.com - - This information has been added to the list of sieve extensions given - on http://www.iana.org/assignments/sieve-extensions. - -6. 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. - - [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC - 3028, January 2001. - - - - - - - - -Murchison Standards Track [Page 4] - -RFC 3598 Sieve Email Filtering September 2003 - - -7. Acknowledgments - - Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall - Gellens, Philip Guenther and Jutta Degener for their help with this - document. - -8. Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - -9. Author's Address - - Kenneth Murchison - Oceana Matrix Ltd. - 21 Princeton Place - Orchard Park, NY 14127 - - EMail: ken@oceana.com - - - - - - - - - - - - - - - -Murchison Standards Track [Page 5] - -RFC 3598 Sieve Email Filtering September 2003 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Murchison Standards Track [Page 6] - |