doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc5183.txt b/doc/rfc/rfc5183.txt
new file mode 100644
index 0000000..ee14e08
--- /dev/null
+++ b/doc/rfc/rfc5183.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                           N. Freed
+Request for Comments: 5183                              Sun Microsystems
+Category: Standards Track                                       May 2008
+
+
+              Sieve Email Filtering: Environment 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 the "environment" extension to the Sieve
+   email filtering language.  The "environment" extension gives a Sieve
+   script access to information about the Sieve interpreter itself,
+   where it is running, and about any transport connection currently
+   involved in transferring the message.
+
+1.  Introduction
+
+   Sieve [RFC5228] is a language for filtering email messages at or
+   around the time of final delivery.  It is designed to be
+   implementable on either a mail client or mail server.  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 [RFC3501] servers, as it has no user-controlled loops
+   or the ability to run external programs.
+
+   Although Sieve is intended to be independent of access protocol, mail
+   architecture, and operating system, in some cases it is useful to
+   allow scripts to access information about their execution context.
+   The "environment" extension provides a new environment test that can
+   be used to implement scripts that behave differently when moved from
+   one system to another, when messages arrive from different remote
+   sources or when otherwise operated in different contexts.
+
+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 [RFC2119].
+
+
+
+
+
+Freed                       Standards Track                     [Page 1]
+
+RFC 5183              Sieve Environment Extension               May 2008
+
+
+   The terms used to describe the various components of the Sieve
+   language are taken from Section 1.1 of [RFC5228].
+
+   This document refers to the ABNF productions IPv4-address-literal,
+   IPv6-address-literal, and General-address-literal defined in Section
+   4.1.3 of [RFC2821].
+
+   The location item makes use of standard terms for email service
+   components.  Additional information and background on these terms can
+   be found in [EMAIL-ARCH].
+
+3.  Capability Identifiers
+
+   The capability string associated with the extension defined in this
+   document is "environment".
+
+4.  Environment Test
+
+   Usage:   environment [COMPARATOR] [MATCH-TYPE]
+                        <name: string>
+                        <key-list: string-list>
+
+   The environment test retrieves the item of environment information
+   specified by the name string and matches it to the values specified
+   in the key-list argument.  The test succeeds if a match occurs.  The
+   type of match defaults to ":is" and the default comparator is
+   "i;ascii-casemap".
+
+   The current message is not a direct source of information for the
+   environment test; the item of information specified by the name
+   string is extracted from the script's operating environment and the
+   key-list argument comes from the script.
+
+   The environment test MUST fail unconditionally if the specified
+   information item does not exist.  A script MUST NOT fail with an
+   error if the item does not exist.  This allows scripts to be written
+   that handle nonexistent items gracefully.  In particular, the test:
+
+     if environment :contains "item" "" { ... }
+
+   only succeeds if "item" is known to the implementation, and always
+   succeeds if it is.
+
+   The "relational" extension [RFC5231] adds a match type called
+   ":count".  The count of an environment test is 0 if the environment
+   information returned is the empty string, or 1 otherwise.
+
+
+
+
+
+Freed                       Standards Track                     [Page 2]
+
+RFC 5183              Sieve Environment Extension               May 2008
+
+
+   Environment items can be standardized or vendor-defined.  An IANA
+   registry is defined for both types of items.  Extensions designed for
+   interoperable use SHOULD be defined in standards track or
+   experimental RFCs.
+
+4.1.  Initial Standard Environment Items
+
+   The initial set of standardized environment items is as follows:
+
+    "domain"  => The primary DNS domain associated with the Sieve
+                 execution context, usually but not always a proper
+                 suffix of the host name.
+
+    "host"    => The fully-qualified domain name of the host where
+                 the Sieve script is executing.
+
+    "location"
+              => Sieve evaluation can be performed at various
+                 different points as messages are processed.  This item
+                 provides additional information about the type of
+                 service that is evaluating the script.  Possible values
+                 are "MTA", meaning the Sieve is being evaluated by a
+                 Message Transfer Agent, "MDA", meaning evaluation is
+                 being performed by a Mail Delivery Agent, "MUA",
+                 meaning evaluation is being performed by a Mail User
+                 Agent, and "MS", meaning evaluation is being performed
+                 by a Message Store.  Additional information and
+                 background on these terms can be found in
+                 [EMAIL-ARCH].
+
+    "name"    => The product name associated with the Sieve interpreter.
+
+    "phase"   => The point relative to final delivery where the
+                 Sieve script is being evaluated.  Possible values are
+                 "pre", "during", and "post", referring respectively to
+                 processing before, during, and after final delivery
+                 has taken place.
+
+    "remote-host"
+              => Host name of remote SMTP/LMTP/Submission client
+                 expressed as a Fully Qualified Domain Name (FQDN),
+                 if applicable and available.  The empty string will be
+                 returned if for some reason this information cannot be
+                 obtained for the current client.
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 3]
+
+RFC 5183              Sieve Environment Extension               May 2008
+
+
+    "remote-ip"
+              => IP address of remote SMTP/LMTP/Submission client, if
+                 applicable and available.  IPv4, IPv6, and other types
+                 of addresses are respectively represented in the
+                 formats defined by the IPv4-address-literal,
+                 IPv6-address-literal, and General-address-literal
+                 productions defined in Section 4.1.3 of [RFC2821].
+
+    "version" => The product version associated with the Sieve
+                 interpreter.  The meaning of the product version string
+                 is product-specific and should always be considered
+                 in the context of the product name given by the
+                 "name" item.
+
+   Implementations SHOULD support as many of the items on this initial
+   list as possible.  Additional standardized items can only be defined
+   in standards-track or experimental RFCs.
+
+4.2.  Vendor-defined Environment Items
+
+   Environment item names 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.
+
+4.3.  IANA Registration of Environment Items
+
+   A registry of environment items is provided by IANA.  Item names may
+   be registered on a first-come, first-served basis.
+
+   Groups of items defined in a standards track or experimental RFC MAY
+   choose to use a common name prefix of the form "name.", where "name"
+   is a string that identifies the group of related items.
+
+   Items not defined in a standards track or experimental RFC MUST have
+   a name that begins with the "vnd." prefix, and this prefix is
+   followed by the name of the vendor or product, such as
+   "vnd.acme.rocket-sled-status".
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 4]
+
+RFC 5183              Sieve Environment Extension               May 2008
+
+
+4.3.1.  Template for Environment Registrations
+
+   The following template is to be used for registering new Sieve
+   environment item names with IANA.
+
+      To: iana@iana.org
+      Subject: Registration of new Sieve environment item
+
+      Item name: [the string for use in the 'environment' test]
+      Description:     [a brief description of the semantics of the
+                        value the item returns]
+
+      RFC number:      [for extensions published as RFCs]
+      Contact address: [email and/or physical address to contact for
+                        additional information]
+
+   Multiple items and descriptions MAY be specified in a single
+   registration request.  Both standardized and vendor-defined items use
+   this form.
+
+5.  Security Considerations
+
+   The environment extension may be used to obtain information about the
+   system the Sieve implementation is running on.  This information in
+   turn may reveal details about service provider or enterprise
+   infrastructure.
+
+   An implementation can use any technique to determine the remote-host
+   environment item defined in this specification, and the
+   trustworthiness of the result will vary.  One common method will be
+   to perform a PTR DNS lookup on the client IP address.  This
+   information may come from an untrusted source.  For example, the
+   test:
+
+     if environment :matches "remote-host" "*.example.com" { ... }
+
+   is not a good way to test whether the message came from "outside"
+   because anyone who can create a PTR record can create one that refers
+   to whatever domain they choose.
+
+   All of the security considerations given in the base Sieve
+   specification also apply to this extension.
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 5]
+
+RFC 5183              Sieve Environment Extension               May 2008
+
+
+6.  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: environment
+      Description:     The "environment" extension provides a new
+                       environment test that can be used to implement
+                       scripts that behave differently when moved
+                       from one system to another or otherwise
+                       operated in different contexts.
+      RFC number:      RFC 5183
+      Contact address: Sieve discussion list <ietf-mta-filters@imc.org>
+
+   This specification also defines a new IANA registry for Sieve
+   environment item names.  The specifics of this registry are given in
+   Section 4.3.  The initial contents of the registry are given in the
+   following section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 6]
+
+RFC 5183              Sieve Environment Extension               May 2008
+
+
+6.1.  Initial Environment Item Registrations
+
+   The following template specifies the initial IANA registrations for
+   the environment items defined in this document:
+
+      To: iana@iana.org
+      Subject: Registration of new Sieve environment items
+
+      Capability name: domain
+      Description:     The primary DNS domain associated with the Sieve
+                       execution context, usually but not always a
+                       proper suffix of the host name.
+
+      Capability name: host
+      Description:     The fully-qualified domain name of the host
+                       where the Sieve script is executing.
+
+      Capability name: location
+      Description:     Type of service executing the Sieve script.
+
+      Capability name: name
+      Description:     The product name associated with the Sieve
+                       interpreter.
+
+      Capability name: phase
+      Description:     Point relative to final delivery at which the
+                       Sieve script is being evaluated.
+
+      Capability name: remote-host
+      Description:     Host name of remote SMTP client, if applicable
+                       and available.
+
+      Capability name: remote-ip
+      Description:     IP address of remote SMTP client, if applicable
+                       and available.
+
+      Capability name: version
+      Description:     The product version associated with the Sieve
+                       interpreter.
+
+      RFC number:      RFC 5183
+      Contact address: Sieve discussion list <ietf-mta-filters@imc.org>
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 7]
+
+RFC 5183              Sieve Environment Extension               May 2008
+
+
+7.  References
+
+7.1.  Normative references
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2821]     Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+                 April 2001.
+
+   [RFC5228]     Guenther, P. and T. Showalter, "Sieve: An Email
+                 Filtering Language", RFC 5228, January 2008.
+
+   [RFC5231]     Segmuller, W. and B. Leiba, "Sieve Email Filtering:
+                 Relational Extension", RFC 5231, January 2008.
+
+7.2.  Informative references
+
+   [EMAIL-ARCH]  Crocker, D., "Internet Mail Architecture", Work
+                 in Progress, February 2008.
+
+   [RFC3501]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                 VERSION 4rev1", RFC 3501, March 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 8]
+
+RFC 5183              Sieve Environment Extension               May 2008
+
+
+Appendix A.  Acknowledgements
+
+   Brian Carpenter, Dave Crocker, Cyrus Daboo, Philip Guenther, Kjetil
+   Torgrim Homme, John Klensin, Mark Mallett, Alexey Melnikov, and
+   Dilyan Palauzo provided helpful suggestions and corrections.
+
+Author's Address
+
+   Ned Freed
+   Sun Microsystems
+   3401 Centrelake Drive, Suite 410
+   Ontario, CA  92761-1205
+   USA
+
+   Phone: +1 909 457 4293
+   EMail: ned.freed@mrochek.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                     [Page 9]
+
+RFC 5183              Sieve Environment Extension               May 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@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Freed                       Standards Track                    [Page 10]
+