Sieve Specs Uploaded

10 files changed, 6795 insertions, 0 deletions

diff --git a/docs/Cyrus IMAP Server Protocol Specifications.URL b/docs/Cyrus IMAP Server Protocol Specifications.URL
new file mode 100644
index 00000000..76949fa9
--- /dev/null
+++ b/docs/Cyrus IMAP Server Protocol Specifications.URL
@@ -0,0 +1,2 @@
+[InternetShortcut]

+URL=http://asg.web.cmu.edu/cyrus/download/imapd/specs.html

diff --git a/docs/draft-martin-managesieve-04.txt b/docs/draft-martin-managesieve-04.txt
new file mode 100644
index 00000000..3795ba36
--- /dev/null
+++ b/docs/draft-martin-managesieve-04.txt
@@ -0,0 +1,1180 @@
+
+
+
+
+
+
+
+Network Working Group                                         Tim Martin
+Document: draft-ietf-managesieve-03.txt                   Mirapoint Inc.
+Expires January 21, 2003                                    16 July 2002
+
+
+               A Protocol for Remotely Managing Sieve Scripts
+
+                      <draft-martin-managesieve-04.txt>
+
+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."
+
+    To view the list Internet-Draft Shadow Directories, see
+    http://www.ietf.org/shadow.html.
+
+    Distribution of this memo is unlimited.
+
+
+Abstract
+
+    Sieve scripts allow users to filter incoming email. Message stores
+    are commonly sealed servers so users cannot log into them, yet users
+    must be able to update their scripts on them.  This document
+    describes a protocol "sieve" for securely managing Sieve scripts on
+    a remote server.  This protocol allows a user to have multiple
+    scripts, and also alerts a user to syntactically flawed scripts.
+
+    This an interim measure as it is hoped that eventually Sieve scripts
+    will be stored on ACAP. This document is intended to proceed on the
+    experimental track.
+
+
+
+
+
+
+
+
+
+
+
+Expires January 21, 2003        Martin                          [Page 1]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+                           Table of Contents
+
+
+
+Status of this Memo  . . . . . . . . . . . . . . . . . . . . . . . .   1
+
+Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
+
+1.     Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+1.1.   Changes . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+1.2.   Conventions Used in the Document  . . . . . . . . . . . . . .   4
+1.3.   Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+1.4.   Response Codes  . . . . . . . . . . . . . . . . . . . . . . .   5
+1.5.   Active Script . . . . . . . . . . . . . . . . . . . . . . . .   6
+1.6.   Quotas  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+1.7.   Script Names  . . . . . . . . . . . . . . . . . . . . . . . .   7
+1.8.   Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   7
+
+2.     Commands  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
+2.1.   AUTHENTICATE Command  . . . . . . . . . . . . . . . . . . . .   8
+2.2.   STARTTLS Command  . . . . . . . . . . . . . . . . . . . . . .  10
+2.3.   LOGOUT Command  . . . . . . . . . . . . . . . . . . . . . . .  10
+2.4.   CAPABILITY Command  . . . . . . . . . . . . . . . . . . . . .  11
+2.5.   HAVESPACE Command . . . . . . . . . . . . . . . . . . . . . .  11
+2.6.   PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . . .  11
+2.7.   LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . . .  13
+2.8.   SETACTIVE Command . . . . . . . . . . . . . . . . . . . . . .  13
+2.9.   GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . . .  13
+2.10.   DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . .  14
+
+3.     Sieve URL Scheme  . . . . . . . . . . . . . . . . . . . . . .  14
+
+4.     Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  15
+
+5.     Security Considerations . . . . . . . . . . . . . . . . . . .  18
+
+6.     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
+
+7.     Copyright . . . . . . . . . . . . . . . . . . . . . . . . . .  18
+
+8.     References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
+
+9.     Author's Address  . . . . . . . . . . . . . . . . . . . . . .  19
+
+
+
+
+
+
+
+
+Expires January 21, 2003        Martin                          [Page 2]
+
+Internet Draft             Managing Sieve Scripts            July 16, 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires January 21, 2003        Martin                          [Page 3]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+1.  Introduction
+
+
+
+1.1.  Changes
+
+    Changes since 03
+
+    -Add referals and Sieve URLs
+
+    -Lots of spelling/grammer fixes
+
+    -Don't give capabilities after successful STARTTLS. This is because
+    it isn't consistant with AUTHENTICATE. There is language specifying
+    that a client should re-issue a CAPABILITY command after
+    AUTHENTICATE/STARTTLS.
+
+    -Putting a script of length 0 doesn't remove the script. If this
+    functionality is desired, the DELETESCRIPT command should be used.
+
+    Changes since 02
+
+    -add BYE response
+
+    -typo on line 588
+
+    -allow ANONYMOUS access for sieve script verification
+
+    -updated SIEVE spec reference
+
+    Changes since 01
+
+    -changed contact info
+
+    Changes since 00
+
+    -added response codes (from ACAP)
+
+    -removed special-ok response from authenticate command (response
+    codes obsolete it)
+
+    -changed service name to "sieve"
+
+    -ABNF fixes
+
+    -Alexey's wording changes
+
+    -Eliminated lame PLAIN paragraph
+
+
+
+Expires January 21, 2003        Martin                          [Page 3]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    Changes since PRE
+
+    -dropped synchronized literals. added HAVESPACE command
+
+    -changed capability response syntax. added CAPABILITY command
+
+    -allowed pipelining
+
+    - "sieve" -> "Sieve". Other minor fixes
+
+    -made script names more flexible
+
+    -added starttls support
+
+
+
+
+1.2.  Conventions Used in the 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].
+
+    In examples, "C:" and "S:" indicate lines sent by the client and
+    server respectively. Line breaks that do not start a new "C:" or
+    "S:" exist for editorial reasons.
+
+
+
+
+1.3.  Syntax
+
+    This a line oriented protocol much like [IMAP4rev1] or [ACAP]. There
+    are three types: ATOMS, numbers and strings. Strings may be quoted
+    or literal. See [ACAP] for detailed descriptions of these types.
+
+    Each command consists of an atom followed by zero or more strings
+    and numbers terminated by a newline.
+
+    All client queries are replied to with either an OK, NO, or BYE
+    response. Each response may be followed by a response code (see
+    response codes section) and by a string consisting of human readable
+    text in the local language. The contents of the string SHOULD be
+    shown to the user and implementations MUST NOT attempt to parse the
+    message for meaning.
+
+    The BYE command may be used if the server wishes to close the
+    connection. A server may wish to do this because the client was idle
+
+
+
+Expires January 21, 2003        Martin                          [Page 4]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    too long or there were too many failed authentication attempts. This
+    command can be issued at any time and should be immediately followed
+    by a server hang-up of the connection. If a server has a inactivity
+    timeout resulting in client autologout it MUST be no less than 30
+    minutes.
+
+    IANA registration is pending. Current implementations generally use
+    port number 2000.
+
+
+
+1.4.  Response Codes
+
+    An OK, NO, or BYE response from the server MAY contain a response
+    code to describe the event in a more detailed machine parsable
+    fashion. A response code consists of data inside parentheses in the
+    form of an atom, possibly followed by a space and arguments.
+    Response codes are defined when there is a specific action that a
+    client can take based upon the additional information. In order to
+    support future extension, the response code is represented as a
+    slash-separated hierarchy with each level of hierarchy representing
+    increasing detail about the error. Clients MUST tolerate additional
+    hierarchical response code detail which they don't understand.
+
+    The currently defined response codes are:
+
+    AUTH-TOO-WEAK
+
+    This response code is returned on a tagged NO result from an
+    AUTHENTICATE command. It indicates that site security policy forbids
+    the use of the requested mechanism for the specified authentication
+    identity.
+
+    ENCRYPT-NEEDED
+
+    This response code is returned on NO result from an AUTHENTICATE
+    command. It indicates that site security policy requires the use of
+    a strong encryption mechanism for the specified authentication
+    identity and mechanism.
+
+    QUOTA
+
+    The command would have placed the user above the site-defined quota
+    constraints.
+
+    REFERRAL
+
+    This response code may be returned with a BYE result from any
+
+
+
+Expires January 21, 2003        Martin                          [Page 5]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    command, and includes a mandatory parameter that indicates what
+    server to access to manage this user's sieve scripts.  The server
+    will be specified by a Sieve URL (see "Sieve URL Scheme" section).
+    The scriptname portion of the URL MUST NOT be specified. The client
+    should authenticate to the specified server and use it for all
+    further commands in the current session.
+
+    SASL
+
+    This response code can occur in the OK response to a successful
+    AUTHENTICATE command and includes the optional final server response
+    data from the server as specified by [SASL].
+
+    TRANSITION-NEEDED
+
+    This response code occurs on a NO response to an AUTHENTICATE
+    command. It indicates that the user name is valid, but the entry in
+    the authentication database needs to be updated in order to permit
+    authentication with the specified mechanism. This can happen if a
+    user has an entry in a system authentication database such as Unix
+    /etc/passwd, but does not have credentials suitable for use by the
+    specified mechanism.
+
+
+    TRYLATER
+
+    A command failed due to a temporary server failure. The client MAY
+    continue using local information and try the command later.
+
+    Client implementations MUST tolerate response codes that they do not
+    recognize.
+
+
+
+1.5.  Active Script
+
+    A user may have multiple Sieve scripts on the server, yet only one
+    script may be used for filtering of incoming messages. This is the
+    active script. Users may have zero or one active scripts and MUST
+    use the SETACTIVE command described below for changing the active
+    script or disabling Sieve processing. For example, a user may have
+    an everyday script they normally use and a special script they use
+    when they go on vacation. Users can change which script is being
+    used without having to download and upload a script stored somewhere
+    else.
+
+
+
+
+
+
+Expires January 21, 2003        Martin                          [Page 6]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+1.6.  Quotas
+
+    Servers SHOULD impose quotas to prevent malicious users from
+    overflowing available storage. If a command would place a user over
+    a quota setting, servers MUST reply with a NO response. Client
+    implementations MUST be able to handle commands failing because of
+    quota restrictions.
+
+
+
+1.7.  Script Names
+
+    Sieve script names may contain any valid UTF8 characters, but names
+    must be at least one octet long. Script names zero octets in length
+    have special meaning. (see SETACTIVE command section) Servers MUST
+    allow names of up to 128 UTF8 octets in length, and may allow longer
+    names.
+
+
+
+1.8.  Capabilities
+
+    Server capabilities are sent by the server upon a client connection.
+    Clients may request the capabilities at a later time by issuing the
+    CAPABILITY command described later. The capabilities consist of a
+    series of lines each with one or two strings. The first string is
+    the name of the capability. The second optional string is the value
+    associated with that capability.
+
+    The following capabilities are defined here:
+
+    IMPLEMENTATION - Name of implementation and version
+
+    SASL - List of SASL mechanisms supported by the server, each
+    separated by a space
+
+    SIEVE - List of space separated Sieve extensions supported
+
+    STARTTLS - If TLS[TLS] is supported by this implementation
+
+    A client implementation MUST ignore any other capabilities given
+    that it does not understand.
+
+    Example:
+
+    S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
+    S: "SASL" "KERBEROS_V4 GSSAPI"
+    S: "SIEVE" "FILEINTO VACATION"
+
+
+
+Expires January 21, 2003        Martin                          [Page 7]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    S: "STARTTLS"
+    S: OK
+
+
+
+2.  Commands
+
+    The following commands are valid. Prior to successful authentication
+    only the AUTHENTICATE, CAPABILITY, STARTTLS, and LOGOUT commands are
+    valid. Servers MUST reject all other commands with a NO response.
+    Clients may pipeline commands (send more than one command at a time
+    without waiting for completion of the first command ). However, a
+    group of commands sent together MUST NOT have a HAVESPACE command
+    anywhere but the last command in the list.
+
+
+
+2.1.  AUTHENTICATE Command
+
+    Arguments:
+         String - mechanism
+         String - initial data (optional)
+
+    The AUTHENTICATE command indicates a SASL [SASL] authentication
+    mechanism to the server.  If the server supports the requested
+    authentication mechanism, it performs an authentication protocol
+    exchange to authenticate and identify the user.  Optionally, it also
+    negotiates a security layer for subsequent protocol interactions.
+    If the requested authentication mechanism is not supported, the
+    server rejects the AUTHENTICATE command by sending a NO response.
+
+    The authentication protocol exchange consists of a series of server
+    challenges and client answers that are specific to the
+    authentication mechanism.  A server challenge consists of a string
+    followed by an endline. The contents of the string is a base-64
+    encoding of the SASL data. The client answer consists of a string
+    with the base-64 encoding of the SASL data followed by an endline.
+    If the mechanism dictates that the final response be sent by the
+    server this data MAY be placed within the data portion of the SASL
+    response code to save a round trip.
+
+    The optional initial-response argument to the AUTHENTICATE command
+    is used to save a round trip when using authentication mechanisms
+    that are defined to send no data in the initial challenge.  When the
+    initial-response argument is used with such a mechanism, the initial
+    empty challenge is not sent to the client and the server uses the
+    data in the initial-response argument as if it were sent in response
+    to the empty challenge.  If the initial-response argument to the
+
+
+
+Expires January 21, 2003        Martin                          [Page 8]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    AUTHENTICATE command is used with a mechanism that sends data in the
+    initial challenge, the server rejects the AUTHENTICATE command by
+    sending a tagged NO response.
+
+    The service name specified by this protocol's profile of SASL is
+    "sieve"
+
+    If a security layer is negotiated through the SASL authentication
+    exchange, it takes effect immediately following the CRLF that
+    concludes the authentication exchange for the client, and the CRLF
+    of the OK response for the server.
+
+    Implementations MAY advertise the ANONYMOUS SASL mechanism [SASL-
+    ANON]. This indicates that the server supports ANONYMOUS sieve
+    script syntax verification. Only the CAPABILITY, PUTSCRIPT and
+    LOGOUT commands are available to the anonymous user. All other
+    commands MUST give NO responses. Furthermore the PUTSCRIPT command
+    SHOULD NOT store any data. In this mode a positive response to the
+    PUTSCRIPT command indicates that the given script does not have any
+    syntax errors.
+
+    Server implementations SHOULD support authorization so that an
+    administrator can administer a user's scripts. Authorization is when
+    a user authenticates as himself but logs in as another user.
+
+    If an AUTHENTICATE command fails with a NO response, the client may
+    try another authentication mechanism by issuing another AUTHENTICATE
+    command.  In other words, the client may request authentication
+    types in decreasing order of preference.
+
+
+
+    Examples:
+
+    S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
+    S: "SASL" "KERBEROS_V4 GSSAPI"
+    S: "SIEVE" "FILEINTO VACATION"
+    S: "STARTTLS"
+    S: OK
+    C: Authenticate "KERBEROS_V4"
+    S: "6UM4Ig=="
+    C: "BAYBQU5EUkVXLkNNVS5FRFUAOCjDCH77GOzSSOF1Df2Kb0zzPe
+    QJIrweAPyo6Q1T9xuYtCGylDqRYlbUFa77esDOtBJdDE5qRXcwHXQE5Dg
+    amqj0LqecZtKUCc8g2xpcqxn1fc/CH6QdZLOAGVpHTN1AX2Y="
+    S: "cmnEYo1x6wc="
+    C: "kjuaMkUeg2okQh+we2uiJw=="
+    S: OK
+
+
+
+
+Expires January 21, 2003        Martin                          [Page 9]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
+    S: BYE "Too many failed authentication attempts"
+    Server closes connection
+
+
+
+2.2.  STARTTLS Command
+
+    The STARTTLS command requests to commencement of a TLS negotiation.
+    The negotiation begins immediately after the CRLF in the OK
+    response. After a client issues a STARTTLS command, it MUST NOT
+    issue further commands until a server response is seen and the TLS
+    negotiation is complete.
+
+     The STARTTLS command is only valid in non-authenticated state. The
+    server remains in non-authenticated state, even if client
+    credentials are supplied during the TLS negotiation. The SASL [SASL]
+    EXTERNAL mechanism MAY be used to authenticate once TLS clie nt
+    credentials are successfully exchanged, but servers supporting the
+    STARTTLS command are not required to support the EXTERNAL mechanism.
+
+    After the TLS layer is established, the server MUST re-issue the
+    capability results. This is necessary to protect against man-in-the-
+    middle attacks which alter the capabilities list prior to STARTTLS.
+    The client MUST discard cached capability information and replace it
+    with the new information. The server MAY advertise different
+    capabilities after STARTTLS.
+
+    Example:
+
+    C: STARTTLS
+    S: OK
+    <TLS negotiation, further commands are under TLS layer>
+
+
+
+2.3.  LOGOUT Command
+
+    The client sends the LOGOUT command when it is finished with a
+    connection and wishes to terminate it. The server MUST reply with an
+    OK response and terminate the connection. The server MUST ignore
+    commands issued by the client after the LOGOUT command.
+
+    Example:
+
+    C: Logout
+    S: OK
+    <connection terminated>
+
+
+
+Expires January 21, 2003        Martin                         [Page 10]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+2.4.  CAPABILITY Command
+
+    The CAPABILITY command requests the server capabilities as described
+    earlier in this document. While the capabilities are sent upon
+    connection, they may change during authentication. The client SHOULD
+    issue a CAPABILITY command after successful authentication or after
+    negotiating a security layer using STARTTLS.
+
+
+    Example:
+
+    S: "IMPLEMENTATION" "CMU Cyrus Sieved v001"
+    S: "SASL" "PLAIN KERBEROS_V4 GSSAPI"
+    S: "SIEVE" "FILEINTO VACATION"
+    S: "STARTTLS"
+    S: OK
+
+
+
+
+2.5.  HAVESPACE Command
+
+    Arguments:
+         String - name
+         Number - size
+
+    The HAVESPACE command is used to query the server for available
+    space. Clients specify the name they wish to save the script as and
+    it's size in octets. Servers respond with an NO if storing a script
+    with that name and size would fail or OK otherwise. Clients should
+    issue this command before attempting to place a script on the
+    server.
+
+    Example:
+
+    C: HAVESPACE "myscript" 999999
+    S: NO "Quota exceeded"
+
+    C: HAVESPACE "foobar" 435
+    S: OK
+
+
+
+
+2.6.  PUTSCRIPT Command
+
+    Arguments:
+         String - Script name
+
+
+
+Expires January 21, 2003        Martin                         [Page 11]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+         String - Script content
+
+    The PUTSCRIPT command is used by the client to submit a Sieve script
+    to the server.
+
+    If the script already exists upon success the old script will be
+    overwritten. The old script MUST NOT be overwritten if PUTSCRIPT
+    fails in any way. A script of zero length SHOULD be disallowed.
+
+    This command places the script on the server. It does not affect
+    whether the script is processed on incoming mail. The SETACTIVE
+    command is used to mark a script as active.
+
+    When submitting large scripts clients SHOULD use the HAVESPACE
+    command beforehand to query if the server is willing to accept a
+    script of that size.
+
+    The server MUST check the submitted script for syntactic validity.
+    If the script fails this test the server MUST reply with a NO
+    response. Any script that fails the validity test MUST NOT be stored
+    on the server. The message given with a NO response MUST be human
+    readable and SHOULD contain a specific error message giving line
+    number of the first error. Implementors should strive to produce
+    helpful error messages similar to those given by programming
+    language compilers. Client implementations should note that this may
+    be a multiline literal string with more than one error message
+    separated by newlines.
+
+    Example:
+
+    C: Putscript "foo" {31+}
+    C: #comment
+    C: InvalidSieveCommand
+    C:
+    S: NO "line 2: Syntax error"
+
+    C: Putscript "mysievescript" {110+}
+    C: require ["fileinto"];
+    C:
+    C: if envelope :contains "to" "tmartin+sent" {
+    C:   fileinto "INBOX.sent";
+    C: }
+    S: OK
+
+
+
+
+
+
+
+
+Expires January 21, 2003        Martin                         [Page 12]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+2.7.  LISTSCRIPTS Command
+
+    This command lists the scripts the user has on the server. Upon
+    success a list of linebreak separated script names is returned
+    followed by an OK response. If there exists an active script the
+    atom ACTIVE is appended to the line of that script. The ACTIVE
+    string MUST NOT appear on more than one response line.
+
+    Example:
+
+    C: Listscripts
+    S: "summer_script"
+    S: "vacation_script"
+    S: "main_script" ACTIVE
+    S: OK
+
+
+
+2.8.  SETACTIVE Command
+
+    Arguments:
+         String - script name
+
+    This command sets a script active. If the script name is the empty
+    string (i.e. "") then any active script is disabled. If the script
+    does not exist on the server then the server MUST reply with a NO
+    response.
+
+    Examples:
+
+    C: Setactive "vacationscript"
+    S: Ok
+
+    C: Setactive ""
+    S: Ok
+
+    C: Setactive "baz"
+    S: No "There is no script by that name"
+
+
+
+2.9.  GETSCRIPT Command
+
+    Arguments:
+         String - Script name
+
+    This command gets the contents of the specified script. If the
+    script does not exist the server MUST reply with a NO response. Upon
+
+
+
+Expires January 21, 2003        Martin                         [Page 13]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    success a string with the contents of the script is returned
+    followed by a OK response.
+
+    Example:
+
+    C: Getscript "myscript"
+    S: {48+}
+    S: #this is my wonderful script
+    S: reject "I reject all";
+    S:
+    S: OK
+
+
+
+
+2.10.  DELETESCRIPT Command
+
+    Parameters:
+         sieve-name - Script name
+
+    This command is used to delete a user's Sieve script. Servers MUST
+    reply with a NO response if the script does not exist. The server
+    MUST NOT allow the client to delete an active script and reply with
+    a NO response if attempted. If a client wishes to delete an active
+    script it should use the SETACTIVE command to disable the script
+    first.
+
+    Example:
+
+    C: Deletescript "foo"
+    S: Ok
+
+    C: Deletescript "baz"
+    S: No "You may not delete an active script"
+
+
+
+3.  Sieve URL Scheme
+
+    URL scheme name: "sieve"
+
+    URL scheme syntax:
+
+      Described using ABNF [RFC 2234] and ABNF entities from RFC 2396.
+
+      sieveurl = "sieve://" [ hostport ] "/" scriptname
+
+      scriptname = *pchar
+
+
+
+Expires January 21, 2003        Martin                         [Page 14]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+      Character encoding considerations: The script name, if present,
+      is in UTF-8.  Non-ASCII characters must be escaped as described
+      in RFC 2396.
+
+    Intended usage: A sieve URL identifies a sieve server or a sieve
+      script on a sieve server.  The latter always have the
+      application/sieve MIME type.
+
+    Applications and/or protocols which use this URL scheme name:
+      The protocol is described in this document.
+
+    Interoperability considerations:  None.
+
+    Security considerations:  None.
+
+    Relevant publications:  This document and RFC 3028.
+
+    Person & email address to contact for further information:
+      Author of this document.
+
+    Author/Change controller:  Author of this document.
+
+
+
+4.  Formal Syntax
+
+    The following syntax specification uses the augmented Backus-Naur
+    Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
+    rules as specified in Appendix A of the ABNF specification [ABNF].
+
+    Except as noted otherwise, all alphabetic characters are case-
+    insensitive. The use of upper or lower case characters to define
+    token strings is for editorial clarity only. Implementations MUST
+    accept these strings in a case-insensitive fashion.
+
+
+    SAFE-CHAR             = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / %x5D-7F
+                            ;; any TEXT-CHAR except QUOTED-SPECIALS
+
+    QUOTED-CHAR           = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
+
+    QUOTED-SPECIALS       = <"> / "\"
+
+    SAFE-UTF8-CHAR        = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 /
+                            UTF8-5 / UTF8-6
+
+    UTF8-1                = %x80-BF
+
+
+
+
+Expires January 21, 2003        Martin                         [Page 15]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    UTF8-2                = %xC0-DF UTF8-1
+
+    UTF8-3                = %xE0-EF 2UTF8-1
+
+    UTF8-4                = %xF0-F7 3UTF8-1
+
+    UTF8-5                = %xF8-FB 4UTF8-1
+
+    UTF8-6                = %xFC-FD 5UTF8-1
+
+    auth-type             = <"> auth-type-name <">
+
+    auth-type-name        = iana-token
+                            ;; as defined in SASL [SASL]
+
+    command               = command-authenticate / command-logout / command-getscript /
+                            command-setactive / command-listscripts / command-deletescript /
+                            command-putscript / command-capability / command-havespace /
+                            command-starttls
+
+    command-authenticate  = "AUTHENTICATE" SP auth-type [SP string]  *(CRLF string)
+
+    command-capability    = "CAPABILITY" CRLF
+
+    command-deletescript  = "DELETESCRIPT" SP sieve-name CRLF
+
+    command-getscript     = "GETSCRIPT" SP sieve-name CRLF
+
+    command-havespace     = "HAVESPACE" SP sieve-name SP number CRLF
+
+    command-listscripts   = "LISTSCRIPTS" CRLF
+
+    command-logout        = "LOGOUT" CRLF
+
+    command-putscript     = "PUTSCRIPT" SP sieve-name SP string CRLF
+
+    command-setactive     = "SETACTIVE" SP sieve-name CRLF
+
+    command-starttls      = "STARTTLS" CRLF
+
+    literal               = "{" number  "+}" CRLF *OCTET
+                            ;; The number represents the number of octets
+                            ;; MUST be literal-utf8 except for values
+
+    number                = *DIGIT
+                            ;; A 32-bit unsigned number.
+                            ;; (0 <= n < 4,294,967,296)
+
+
+
+
+Expires January 21, 2003        Martin                         [Page 16]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    quoted                = <"> *QUOTED-CHAR <">
+                            ;; limited to 1024 octets between the <">s
+
+    resp-code             = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" /
+                            "QUOTA" / resp-code-sasl / resp-code-referral
+                            "TRANSITION-NEEDED" / "TRYLATER" /
+                            resp-code-ext
+
+    resp-code-referral   = "REFERRAL" SP sieveurl
+
+    resp-code-sasl        = "SASL" SP string
+
+    resp-code-ext         = iana-token [SP extension-data]
+                            ;; unknown codes MUST be tolerated by the client
+
+    response              = response-authenticate / response-logout / response-getscript /
+                            response-setactive / response-listscripts / response-deletescript /
+                            response-putscript / response-capability / response-havespace /
+                            response-starttls
+
+    response-authenticate = *(string CRLF) (response-oknobye)
+
+    response-capability   = *(string [SP string] CRLF) response-oknobye
+
+    response-deletescript = response-oknobye
+
+    response-getscript    = [string CRLF] response-oknobye
+
+    response-havespace    = response-oknobye
+
+    response-listscripts  = *(sieve-name [SP "ACTIVE"] CRLF) response-oknobye
+                   ;; ACTIVE may only occur with one sieve-name
+
+    response-logout       = response-oknobye
+
+    response-oknobye      = ("OK" / "NO" / "BYE") [SP "(" resp-code ")"] [SP string] CRLF
+
+    response-putscript    = response-oknobye
+
+    response-setactive    = response-oknobye
+
+    response-starttls     = response-oknobye
+
+    sieve-name            = string
+
+    string                = quoted / literal
+
+
+
+
+
+Expires January 21, 2003        Martin                         [Page 17]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+5.  Security Considerations
+
+    The AUTHENTICATE command uses SASL [SASL] and TLS [TLS] to provide
+    basic authentication, authorization, integrity and privacy services.
+    When a SASL mechanism is used the security considerations for that
+    mechanism apply.
+
+    This protocol transactions are susceptible to passive observers or
+    man in the middle attacks which alter the data, unless the optional
+    encryption and integrity services of the AUTHENTICATE command are
+    enabled, or an external security mechanism is used for protection.
+    It may be useful to allow configuration of both clients and servers
+    to refuse to transfer sensitive information in the absence of strong
+    encryption.
+
+
+6.  Acknowledgments
+
+    Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
+    Newman, Lyndon Nerenberg, Alexey Melnikov, Tim Showalter, Sarah
+    Robeson, and Walter Wong for help with this document.
+
+
+
+7.  Copyright
+
+    Copyright (C) The Internet Society 1999. 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
+
+
+
+Expires January 21, 2003        Martin                         [Page 18]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    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.
+
+8.  References
+
+     [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
+         Requirement Levels", RFC 2119, March 1997
+
+         <ftp://ftp.isi.edu/in-notes/rfc2119.txt>
+
+
+[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
+ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November
+1997.
+
+[ACAP] Newman, Myers, "ACAP -- Application Configuration Access Proto-
+col", RFC 2244, Innosoft, Netscape, November 1997.
+
+[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
+4rev1", RFC 2060, October 1996.
+
+[IMAP-URL] Newman, C.; "IMAP URL Scheme"; RFC 2192; Innosoft; September,
+1997
+
+[PLAIN] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
+Innosoft, June 1999.
+
+[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
+2222, Netscape Communications, October 1997.
+
+[SASL-ANON] Newman, C., "Anonymous SASL Mechanism", RFC 2245, November
+1997.
+
+[SIEVE] Showalter, T.; "Sieve: A Mail Filtering Language"; RFC 3028;
+Mirapoint, Inc.; January 2001
+
+[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
+January 1999.
+
+
+9.  Author's Address
+
+    Tim Martin
+    Mirapoint Inc.
+    909 Hermosa Court
+    Sunnyvale, CA 94085
+
+
+
+
+Expires January 21, 2003        Martin                         [Page 19]
+
+Internet Draft           Managing Sieve Scripts            July 16, 2002
+
+
+    Phone: (408) 720-3835
+    EMail: tmartin@mirapoint.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires January 21, 2003        Martin                         [Page 20]
+
diff --git a/docs/draft-melnikov-sieve-imapflags-03.txt b/docs/draft-melnikov-sieve-imapflags-03.txt
new file mode 100644
index 00000000..f714b44a
--- /dev/null
+++ b/docs/draft-melnikov-sieve-imapflags-03.txt
@@ -0,0 +1,434 @@
+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/draft-murchison-sieve-regex-07.txt b/docs/draft-murchison-sieve-regex-07.txt
new file mode 100644
index 00000000..e5ee1b1a
--- /dev/null
+++ b/docs/draft-murchison-sieve-regex-07.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+
+Internet Draft                                               K. Murchison
+Category: Standards Track                              Oceana Matrix Ltd.
+Expires: May 23, 2004                                    18 November 2003
+
+
+            Sieve Email Filtering -- Regular Expression Extension
+
+                    <draft-murchison-sieve-regex-07.txt>
+
+Status of this Memo
+
+    This document is an Internet-Draft and is subject to 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/1id-abstracts.html
+
+    The list of Internet-Draft Shadow Directories can be accessed at
+    http://www.ietf.org/shadow.html
+
+Copyright Notice
+
+    Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+
+Abstract
+
+    In some cases, it is desirable to have a string matching mechanism
+    which is more powerful than a simple exact match, a substring match
+    or a glob-style wildcard match.  The regular expression matching
+    mechanism defined in this draft should allow users to isolate just
+    about any string or address in a message header or envelope.
+
+
+
+
+
+
+
+
+
+Expires: May 23, 2004         Murchison                         [Page 1]
+
+Internet Draft          Sieve -- Regex Extension       November 18, 2004
+
+
+                           Table of Contents
+
+
+
+0.     Meta-information on this draft  . . . . . . . . . . . . . . .   3
+
+0.1.   Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+
+0.2.   Noted Changes Since -06 . . . . . . . . . . . . . . . . . . .   3
+
+0.3.   Open Issues . . . . . . . . . . . . . . . . . . . . . . . . .   3
+
+1.     Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+
+2.     Capability Identifier . . . . . . . . . . . . . . . . . . . .   4
+
+3.     Regex Match Type  . . . . . . . . . . . . . . . . . . . . . .   4
+
+4.     Security Considerations . . . . . . . . . . . . . . . . . . .   6
+
+5.     IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+
+6.     Normative References  . . . . . . . . . . . . . . . . . . . .   7
+
+7.     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
+
+8.     Intellectual Property Statement . . . . . . . . . . . . . . .   7
+
+9.     Author's Address  . . . . . . . . . . . . . . . . . . . . . .   8
+
+10.    Full Copyright Statement  . . . . . . . . . . . . . . . . . .   8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires: May 23, 2004         Murchison                         [Page 2]
+
+Internet Draft          Sieve -- Regex Extension       November 18, 2004
+
+
+
+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 an extension to the Sieve mail filtering
+    language, available from the RFC repository as
+    <ftp://ftp.ietf.org/rfc/rfc3028.txt>.
+
+    This draft and the Sieve language itself are 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.   Noted Changes Since -06
+
+    Added more open issues.
+
+    Added IANA considerations.
+
+    Editorial changes.
+
+
+0.3.   Open Issues
+
+    The major open issue with this draft is what to do, if anything,
+    about localization/internationalization.  Are [POSIX.2] collating
+    sequences and character equivalents sufficient?  Should we reference
+    the unicode technical specification?  Should we punt and publish the
+    document as experimental?
+
+    Should we allow shorthands such as \b (word boundary) and \w (word
+    character)?
+
+    Should we allow backreferences (useful for matching double words,
+    etc.)?
+
+    Should we integrate with variables, so that $1, $2, ...  correspond
+    to the first, second, ... groups within the regex?
+
+
+
+
+
+Expires: May 23, 2004         Murchison                         [Page 3]
+
+Internet Draft          Sieve -- Regex Extension       November 18, 2004
+
+
+1.  Introduction
+
+    This is an extension to the Sieve language defined by [SIEVE] for
+    comparing strings to regular expressions.
+
+    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 "regex".
+
+
+3.  Regex Match Type
+
+    Commands that support matching may take the optional tagged argument
+    ":regex" to specify that a regular expression match should be
+    performed.  The ":regex" match type is subject to the same rules and
+    restrictions as the standard match types defined in [SIEVE].  For
+    convenience, the "MATCH-TYPE" syntax element defined in [SIEVE] is
+    augmented here as follows:
+
+         MATCH-TYPE  =/  ":regex"
+
+    Example:
+
+          require "regex";
+
+          # Try to catch unsolicited email.
+          if anyof (
+            # if a message is not to me (with optional +detail),
+            not address :regex ["to", "cc", "bcc"]
+              "me(\\+.*)?@company\\.com",
+
+            # or the subject is all uppercase (no lowercase)
+            header :regex :comparator "i;octet" "subject"
+              "^[^[:lower:]]+$" ) {
+
+            discard;     # junk it
+          }
+
+    The ":regex" match type is compatible with both the "i;octet" and
+    "i;ascii-casemap" comparators and may be used with them.
+
+    Implementations MUST support extended regular expressions (EREs) as
+    defined by [POSIX.2].  Any regular expression not defined by
+
+
+
+Expires: May 23, 2004         Murchison                         [Page 4]
+
+Internet Draft          Sieve -- Regex Extension       November 18, 2004
+
+
+    [POSIX.2], as well as [POSIX.2] basic regular expressions, word
+    boundaries and backreferences are not supported by this extension.
+    Implementations SHOULD reject regular expressions that are
+    unsupported by this specification as a syntax error.
+
+    The following table provides a brief summary of the regular
+    expressions that MUST be supported.  This table is presented here
+    only as a guideline.  [POSIX.2] should be used as the definitive
+    reference.
+
+
+    +------------+-----------------------------------------------------+
+    | Expression |  Pattern                                            |
+    +------------+-----------------------------------------------------+
+    |                Items to match a single character                 |
+    +------------+-----------------------------------------------------+
+    |     .      |  Match any single character except newline.         |
+    |    [ ]     |  Bracket expression.  Match any one of the enclosed |
+    |            |  characters.  A hypen (-) indicates a range of      |
+    |            |  consecutive characters.                            |
+    |   [^  ]    |  Negated bracket expression.  Match any one         |
+    |            |  character NOT in the enclosed list.  A hypen (-)   |
+    |            |  indicates a range of consecutive characters.       |
+    |    \\      |  Escape the following special character (match      |
+    |            |  the literal character).  Undefined for other       |
+    |            |  characters.                                        |
+    |            |  NOTE: Unlike [POSIX.2], a double-backslash is      |
+    |            |  required as per section 2.4.2 of [SIEVE].          |
+    +------------+-----------------------------------------------------+
+    |   Items to be used within a bracket expression (localization)    |
+    +------------+-----------------------------------------------------+
+    |   [: :]    |  Character class (alnum, alpha, blank, cntrl,       |
+    |            |  digit, graph, lower, print, punct, space,          |
+    |            |  upper, xdigit).                                    |
+    |   [= =]    |  Character equivalents.                             |
+    |   [. .]    |  Collating sequence.                                |
+    +------------+-----------------------------------------------------+
+    |  Quantifiers - Items to count the preceding regular expression   |
+    +------------+-----------------------------------------------------+
+    |     ?      |  Match zero or one instances.                       |
+    |     *      |  Match zero or more instances.                      |
+    |     +      |  Match one or more instances.                       |
+    |   {n,m}    |  Match any number of instances between              |
+    |            |  n and m (inclusive).  {n} matches exactly n        |
+    |            |  instances.  {n,} matches n or more instances.      |
+    +------------+-----------------------------------------------------+
+
+
+
+
+
+Expires: May 23, 2004         Murchison                         [Page 5]
+
+Internet Draft          Sieve -- Regex Extension       November 18, 2004
+
+
+    +------------+-----------------------------------------------------+
+    | Expression |  Pattern                                            |
+    +------------+-----------------------------------------------------+
+    |              Anchoring - Items to match positions                |
+    +------------+-----------------------------------------------------+
+    |     ^      |  Match the beginning of the line or string.         |
+    |     $      |  Match the end of the line or string.               |
+    +------------+-----------------------------------------------------+
+    |                        Other constructs                          |
+    +------------+-----------------------------------------------------+
+    |     |      |  Alternation.  Match either of the separated        |
+    |            |  regular expressions.                               |
+    |    ( )     |  Group the enclosed regular expression(s).          |
+    +------------+-----------------------------------------------------+
+
+
+4.  Security Considerations
+
+    Security considerations are discussed in [SIEVE].  It is believed
+    that this extension doesn't introduce any additional security
+    concerns.
+
+    However, a poor implementation COULD introduce security problems
+    ranging from degradation of performance to denial of service.  If an
+    implementation uses a third-party regular expression library, that
+    library should be checked for potentially problematic regular
+    expressions, such as "(.*)*".
+
+
+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: regex
+    Capability keyword: regex
+    Capability arguments: N/A
+    Standards Track/IESG-approved experimental RFC number: this RFC
+    Person and email address to contact for further information:
+
+    Kenneth Murchison
+    ken@oceana.com
+
+    This information should be added to the list of sieve extensions
+    given on http://www.iana.org/assignments/sieve-extensions.
+
+
+
+Expires: May 23, 2004         Murchison                         [Page 6]
+
+Internet Draft          Sieve -- Regex Extension       November 18, 2004
+
+
+6.
+    Normative References
+
+     [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+         Requirement Levels", RFC 2119, March 1997.
+
+
+     [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language",
+         RFC 3028, January 2001.
+
+
+     [POSIX.2], "Portable Operating System Interface (POSIX). Part 2,
+         Shell and utilities", National Institute of Standards and
+         Technology (U.S.).
+
+
+
+7.  Acknowledgments
+
+    Thanks to Tim Showalter, Alexey Melnikov, Tony Hansen, Phil Pennock,
+    Jutta Degener and Ned Freed 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 per­
+    tain 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 pro­
+    prietary 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.
+
+
+
+
+
+
+
+Expires: May 23, 2004         Murchison                         [Page 7]
+
+Internet Draft          Sieve -- Regex Extension       November 18, 2004
+
+
+9.  Author's Address
+
+    Kenneth Murchison
+    Oceana Matrix Ltd.
+    21 Princeton Place
+    Orchard Park, NY  14127
+
+    Phone: (716) 662-8973
+
+    EMail: ken@oceana.com
+
+
+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 implmentation 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires: May 23, 2004         Murchison                         [Page 8]
diff --git a/docs/draft-showalter-sieve-vacation-05.txt b/docs/draft-showalter-sieve-vacation-05.txt
new file mode 100644
index 00000000..2b04870d
--- /dev/null
+++ b/docs/draft-showalter-sieve-vacation-05.txt
@@ -0,0 +1,64 @@
+<head>
+<TITLE> Page Not Found </TITLE>
+</head>
+<!-- begin new headers and page layout -->
+<body bgcolor="#ffffff" > 
+<center>
+<table border=0 cellpadding=0 cellspacing=0>
+<tr>
+<td><a href="/home.html"><img src="/images/header/ietflogo_sm.gif" border="0"></a></td>
+<td><a href="/home.html"><img src="/images/header/home11.gif" border="0"></a></td>
+<td><img src="/images/header/separator.gif" border="0"></td>
+<td><a href="/html.charters/wg-dir.html"><img src="/images/header/wg11.gif" border="0"></a></td>
+<td><img src="/images/header/separator.gif" border="0"></td>
+<td><a href="/meetings/meetings.html"><img src="/images/header/meetings11.gif" border="0"></a></td>
+<td><img src="/images/header/separator.gif" border="0"></td>
+<td><a href="/proceedings/directory.html"><img src="/images/header/proceed11.gif"  border="0"></a></td>
+<td><img src="/images/header/separator.gif" border="0"></td>
+<td><a href="/ID.html"><img src="/images/header/id-index11.gif" border="0"></a></td>
+<td><img src="/images/header/separator.gif" border="0"></td>
+<td><a href="rfc.html"><img src="/images/header/rfc11.gif" border="0"></a></td>
+</tr>
+</table>
+</center>
+<hr>
+<!-- end new headers and layout -->
+
+<html>
+<head>
+<title>Page Not Found</title>
+</head>
+<body bgcolor="#ffffff" >
+
+<center>
+<img src="/images/ietflogo2e.gif" height="160" width="280">
+<br clear=all>
+
+<center><h1>The Internet Engineering Task Force</h1></center>
+<table border=0 cellspacing=5 cellpadding=5>
+
+<br>
+<font size = 3>
+<center><img alt="" src="/images/blue-line.jpg"></center>
+<br clear=all>
+<h3>The page you are looking for cannot be found.</h3><br>
+If it is an Internet-Draft, the version may have expired.<br>
+Please visit <A HREF="http://search.ietf.org"> search.ietf.org</A> and enter in keywords or the name of the draft without the version numbers. 
+<br>
+<br>
+For other Web page issues, please contact <a href="mailto:webmaster@ietf.org">webmaster@ietf.org</a>. <br>
+<br>
+<font size = 3>
+<center><img alt="Blue Line" src="/images/blue-line.jpg"></center>
+<br clear=all>
+The IETF is an organized activity of the <a href="http://www.isoc.org"><img alt="ISOC" src="/images/isoc-small.gif" hspace="3" border="0"></A>
+
+<br>
+
+<hr>
+<i>The <A HREF="/secretariat.html">IETF Secretariat</A> is hosted by the NeuStar Secretariat Services, a wholly owned subsidiary of <a href="http://www.neustar.biz/"><img src="/images/NS_logo_100px.gif" alt="NeuStar Logo" border="0">
+</i>
+
+</body>
+</html>
+
diff --git a/docs/rfc2221.txt b/docs/rfc2221.txt
new file mode 100644
index 00000000..78f73c90
--- /dev/null
+++ b/docs/rfc2221.txt
@@ -0,0 +1,284 @@
+
+
+
+
+
+Network Working Group                                           M. Gahrns
+Request for Comments: 2221                                      Microsoft
+Category: Standards Track                                    October 1997
+
+
+                         IMAP4 Login Referrals
+
+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 (1997).  All Rights Reserved.
+
+1. Abstract
+
+   When dealing with large amounts of users and many IMAP4 [RFC-2060]
+   servers, it is often necessary to move users from one IMAP4 server to
+   another.  For example, hardware failures or organizational changes
+   may dictate such a move.
+
+   Login referrals allow clients to transparently connect to an
+   alternate IMAP4 server, if their home IMAP4 server has changed.
+
+   A referral mechanism can provide efficiencies over the alternative
+   'proxy method', in which the local IMAP4 server contacts the remote
+   server on behalf of the client, and then transfers the data from the
+   remote server to itself, and then on to the client.  The referral
+   mechanism's direct client connection to the remote server is often a
+   more efficient use of bandwidth, and does not require the local
+   server to impersonate the client when authenticating to the remote
+   server.
+
+2. Conventions used in this document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   A home server, is an IMAP4 server that contains the user's inbox.
+
+   A remote server is a server that contains remote mailboxes.
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 1]
+
+RFC 2221                 IMAP4 Login Referrals              October 1997
+
+
+   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].
+
+3. Introduction and Overview
+
+   IMAP4 servers that support this extension MUST list the keyword
+   LOGIN-REFERRALS in their CAPABILITY response.  No client action is
+   needed to invoke the LOGIN-REFERRALS capability in a server.
+
+   A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
+   to a server that will return a referral. A client MUST NOT follow
+   more than 10 levels of referral without consulting the user.
+
+   A LOGIN-REFERRALS response code MUST contain as an argument a valid
+   IMAP server URL as defined in [IMAP-URL].
+
+   A home server referral consists of either a tagged NO or OK, or an
+   untagged BYE response that contains a LOGIN-REFERRALS response code.
+
+   Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
+
+   NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
+   client falling back to anonymous login.
+
+4. Home Server Referrals
+
+   A home server referral may be returned in response to an AUTHENTICATE
+   or LOGIN command, or it may appear in the connection startup banner.
+   If a server returns a home server referral in a tagged NO response,
+   that server does not contain any mailboxes that are accessible to the
+   user.  If a server returns a home server referral in a tagged OK
+   response, it indicates that the user's personal mailboxes are
+   elsewhere, but the server contains public mailboxes which are
+   readable by the user.  After receiving a home server referral, the
+   client can not make any assumptions as to whether this was a
+   permanent or temporary move of the user.
+
+4.1.  LOGIN and AUTHENTICATE Referrals
+
+   An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
+   home server referral if it wishes to direct the user to another IMAP4
+   server.
+
+   Example:  C: A001 LOGIN MIKE PASSWORD
+             S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
+                     is invalid on this server. Try SERVER2.
+
+
+
+
+Gahrns                      Standards Track                     [Page 2]
+
+RFC 2221                 IMAP4 Login Referrals              October 1997
+
+
+   Example:  C: A001 LOGIN MATTHEW PASSWORD
+             S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
+                     user's personal mailboxes located on Server2, but
+                     public mailboxes are available.
+
+   Example:  C: A001 AUTHENTICATE GSSAPI
+             <authentication exchange>
+             S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
+                     Specified user is invalid on this server. Try
+                     SERVER2.
+
+4.2. BYE at connection startup referral
+
+   An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
+   response code that contains an IMAP URL to a home server if it is not
+   willing to accept connections and wishes to direct the client to
+   another IMAP4 server.
+
+   Example:  S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
+                  accepting connections.  Try SERVER2
+
+5. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in [ABNF].
+
+   This amends the "resp_text_code" element of the IMAP4 grammar
+   described in [RFC-2060]
+
+   resp_text_code =/ "REFERRAL" SPACE <imapurl>
+      ; See [IMAP-URL] for definition of <imapurl>
+      ; See [RFC-2060] for base definition of resp_text_code
+
+6. Security Considerations
+
+   The IMAP4 login referral mechanism makes use of IMAP URLs, and as
+   such, have the same security considerations as general internet URLs
+   [RFC-1738], and in particular IMAP URLs [IMAP-URL].
+
+   A server MUST NOT give a login referral if authentication for that
+   user fails. This is to avoid revealing information about the user's
+   account to an unauthorized user.
+
+   With the LOGIN-REFERRALS capability, it is potentially easier to
+   write a rogue 'password catching' server that collects login data and
+   then refers the client to their actual IMAP4 server.  Although
+   referrals reduce the effort to write such a server, the referral
+   response makes detection of the intrusion easier.
+
+
+
+Gahrns                      Standards Track                     [Page 3]
+
+RFC 2221                 IMAP4 Login Referrals              October 1997
+
+
+7. References
+
+   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
+   4rev1", RFC 2060, December 1996.
+
+   [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
+   September 1997.
+
+   [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+   Resource Locators  (URL)", RFC 1738, December 1994.
+
+   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, March 1997.
+
+   [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
+   Syntax Specifications: ABNF", Work in Progress.
+
+8.  Acknowledgments
+
+   Many valuable suggestions were received from private discussions and
+   the IMAP4 mailing list.  In particular, Raymond Cheng, Mark Crispin,
+   Mark Keasling Chris Newman and Larry Osterman made significant
+   contributions to this document.
+
+9. Author's Address
+
+   Mike Gahrns
+   Microsoft
+   One Microsoft Way
+   Redmond, WA, 98072
+
+   Phone: (206) 936-9833
+   EMail: mikega@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 4]
+
+RFC 2221                 IMAP4 Login Referrals              October 1997
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  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 implmentation may be prepared, copied, published
+   andand 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."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns                      Standards Track                     [Page 5]
+
+
+
diff --git a/docs/rfc2298.txt b/docs/rfc2298.txt
new file mode 100644
index 00000000..62836512
--- /dev/null
+++ b/docs/rfc2298.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                          R. Fajman
+Request for Comments: 2298                 National Institutes of Health
+Category: Standards Track                                     March 1998
+
+
+                      An Extensible Message Format
+                 for Message Disposition Notifications
+
+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 (1998).  All Rights Reserved.
+
+Abstract
+
+   This memo defines a MIME content-type that may be used by a mail user
+   agent (UA) or electronic mail gateway to report the disposition of a
+   message after it has been sucessfully delivered to a recipient.  This
+   content-type is intended to be machine-processable.  Additional
+   message headers are also defined to permit Message Disposition
+   Notifications (MDNs) to be requested by the sender of a message.  The
+   purpose is to extend Internet Mail to support functionality often
+   found in other messaging systems, such as X.400 and the proprietary
+   "LAN-based" systems, and often referred to as "read receipts,"
+   "acknowledgements," or "receipt notifications."  The intention is to
+   do this while respecting the privacy concerns that have often been
+   expressed when such functions have been discussed in the past.
+
+   Because many messages are sent between the Internet and other
+   messaging systems (such as X.400 or the proprietary "LAN-based"
+   systems), the MDN protocol is designed to be useful in a multi-
+   protocol messaging environment.  To this end, the protocol described
+   in this memo provides for the carriage of "foreign" addresses, in
+   addition to those normally used in Internet Mail.  Additional
+   attributes may also be defined to support "tunneling" of foreign
+   notifications through Internet Mail.
+
+
+
+
+
+
+
+
+Fajman                      Standards Track                     [Page 1]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+Table of Contents
+
+   1.   Introduction ............................................  2
+   2.   Requesting Message Disposition Notifications ............  3
+   3.   Format of a Message Disposition Notification ............  7
+   4.   Timeline of events ...................................... 17
+   5.   Conformance and Usage Requirements ...................... 18
+   6.   Security Considerations ................................. 19
+   7.   Collected Grammar ....................................... 20
+   8.   Guidelines for Gatewaying MDNs .......................... 22
+   9.   Example ................................................. 24
+   10.  IANA Registration Forms ................................. 25
+   11.  Acknowledgments ......................................... 26
+   12.  References .............................................. 26
+   13.  Author's Address ........................................ 27
+   14.  Copyright ............................................... 28
+
+1.  Introduction
+
+   This memo defines a MIME content-type [5] for message disposition
+   notifications (MDNs).  An MDN can be used to notify the sender of a
+   message of any of several conditions that may occur after successful
+   delivery, such as display of the message contents, printing of the
+   message, deletion (without display) of the message, or the
+   recipient's refusal to provide MDNs.  The "message/disposition-
+   notification" content-type defined herein is intended for use within
+   the framework of the "multipart/report" content type defined in RFC
+   1892 [7].
+
+   This memo defines the format of the notifications and the RFC 822
+   headers used to request them.
+
+   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.
+
+1.1 Purposes
+
+   The MDNs defined in this memo are expected to serve several purposes:
+
+   (a)  Inform human beings of the disposition of messages after
+        succcessful delivery, in a manner which is largely independent
+        of human language;
+
+   (b)  Allow mail user agents to keep track of the disposition of
+        messages sent, by associating returned MDNs with earlier message
+        transmissions;
+
+
+
+
+Fajman                      Standards Track                     [Page 2]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   (c)  Convey disposition notification requests and disposition
+        notifications between Internet Mail and "foreign" mail systems
+        via a gateway;
+
+   (d)  Allow "foreign" notifications to be tunneled through a MIME-
+        capable message system and back into the original messaging
+        system that issued the original notification, or even to a third
+        messaging system;
+
+   (e)  Allow language-independent, yet reasonably precise, indications
+        of the disposition of a message to be delivered.
+
+1.2 Requirements
+
+   These purposes place the following constraints on the notification
+   protocol:
+
+   (a)  It must be readable by humans, as well as being machine-
+        parsable.
+
+   (b)  It must provide enough information to allow message senders (or
+        their user agents) to unambiguously associate an MDN with the
+        message that was sent and the original recipient address for
+        which the MDN is issued (if such information is available), even
+        if the message was forwarded to another recipient address.
+
+   (c)  It must also be able to describe the disposition of a message
+        independent of any particular human language or of the
+        terminology of any particular mail system.
+
+   (d)  The specification must be extensible in order to accomodate
+        future requirements.
+
+2.  Requesting Message Disposition Notifications
+
+   Message disposition notifications are requested by including a
+   Disposition-Notification-To header in the message.  Further
+   information to be used by the recipient's UA in generating the MDN
+   may be provided by including Original-Recipient and/or Disposition-
+   Notification-Options headers in the message.
+
+2.1 The Disposition-Notification-To Header
+
+   A request that the receiving user agent issue message disposition
+   notifications is made by placing a Disposition-Notification-To header
+   into the message.  The syntax of the header, using the ABNF of RFC
+   822 [2], is
+
+
+
+
+Fajman                      Standards Track                     [Page 3]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+     mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
+
+   The mailbox token is as specified in RFC 822 [2].
+
+   The presence of a Disposition-Notification-To header in a message is
+   merely a request for an MDN.  The recipients' user agents are always
+   free to silently ignore such a request.  Alternatively, an explicit
+   denial of the request for information about the disposition of the
+   message may be sent using the "denied" disposition in an MDN.
+
+   An MDN MUST NOT itself have a Disposition-Notification-To header.
+   An MDN MUST NOT be generated in response to an MDN.
+
+   At most one MDN may be issued on behalf of each particular recipient
+   by their user agent.  That is, once an MDN has been issued on behalf
+   of a recipient, no further MDNs may be issued on behalf of that
+   recipient, even if another disposition is performed on the message.
+   However, if a message is forwarded, an MDN may been issued for the
+   recipient doing the forwarding and the recipient of the forwarded
+   message may also cause an MDN to be generated.
+
+   While Internet standards normally do not specify the behavior of user
+   interfaces, it is strongly recommended that the user agent obtain the
+   user's consent before sending an MDN.  This consent could be obtained
+   for each message through some sort of prompt or dialog box, or
+   globally through the user's setting of a preference.  The user might
+   also indicate globally that MDNs are never to be sent or that a
+   "denied" MDN is always sent in response to a request for an MDN.
+
+   MDNs SHOULD NOT be sent automatically if the address in the
+   Disposition-Notification-To header differs from the address in the
+   Return-Path header (see RFC 822 [2]).  In this case, confirmation
+   from the user SHOULD be obtained, if possible.  If obtaining consent
+   is not possible (e.g., because the user is not online at the time),
+   then an MDN SHOULD NOT be sent.
+
+   Confirmation from the user SHOULD be obtained (or no MDN sent) if
+   there is no Return-Path header in the message, or if there is more
+   than one distinct address in the Disposition-Notification-To header.
+
+   The comparison of the addresses should be done using only the addr-
+   spec (local-part "@" domain) portion, excluding any phrase and route.
+   The comparison MUST be case-sensitive for the local-part and case-
+   insensitive for the domain part.
+
+   If the message contains more than one Return-Path header, the
+   implementation may pick one to use for the comparison, or treat the
+   situation as a failure of the comparison.
+
+
+
+Fajman                      Standards Track                     [Page 4]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   The reason for not automatically sending an MDN if the comparison
+   fails or more than one address is specified is to reduce the
+   possibilities for mail loops and use of MDNs for mail bombing.
+
+   A message that contains a Disposition-Notification-To header SHOULD
+   also contain a Message-ID header as specified in RFC 822 [2].  This
+   will permit automatic correlation of MDNs with original messages by
+   user agents.
+
+   If it is desired to request message disposition notifications for
+   some recipients and not others, two copies of the message should be
+   sent, one with an Disposition-Notification-To header and one without.
+   Many of the other headers of the message (e.g., To, cc) will be the
+   same in both copies.  The recipients in the respective message
+   envelopes determine for whom message disposition notifications are
+   requested and for whom they are not.  If desired, the Message-ID
+   header may be the same in both copies of the message.  Note that
+   there are other situations (e.g., bcc) in which it is necessary to
+   send multiple copies of a message with slightly different headers.
+   The combination of such situations and the need to request MDNs for a
+   subset of all recipients may result in more than two copies of a
+   message being sent, some with a Disposition- Notification-To header
+   and some without.
+
+   Messages posted to newsgroups SHOULD NOT have a Disposition-
+   Notification-To header.
+
+2.2 The Disposition-Notification-Options Header
+
+   Future extensions to this specification may require that information
+   be supplied to the recipient's UA for additional control over how and
+   what MDNs are generated.  The Disposition-Notification-Options header
+   provides an extensible mechanism for such information.  The syntax of
+   this header, using the ABNF of RFC 822 [2], is
+
+     Disposition-Notification-Options =
+          "Disposition-Notification-Options" ":"
+          disposition-notification-parameters
+
+     disposition-notification-parameters = parameter *(";" parameter)
+
+     parameter = attribute "=" importance "," 1#value
+
+     importance = "required" / "optional"
+
+   The definitions of attribute and value are as in the definition of
+   the Content-Type header in RFC 2045 [4].
+
+
+
+
+Fajman                      Standards Track                     [Page 5]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   An importance of "required" indicates that interpretation of the
+   parameter is necessary for proper generation of an MDN in response to
+   this request.  If a UA does not understand the meaning of the
+   parameter, it MUST NOT generate an MDN with any disposition type
+   other than "failed" in response to the request.  An importance of
+   "optional" indicates that a UA that does not understand the meaning
+   of this parameter MAY generate an MDN in response anyway, ignoring
+   the value of the parameter.
+
+   No parameters are defined in this specification.  Parameters may be
+   defined in the future by later revisions or extensions to this
+   specification.  Parameter attribute names beginning with "X-" will
+   never be defined as standard names; such names are reserved for
+   experimental use.  MDN parameter names not beginning with "X-" MUST
+   be registered with the Internet Assigned Numbers Authority (IANA) and
+   described in a standards-track RFC or an experimental RFC approved by
+   the IESG.  See Section 10 for a registration form.
+
+   If a required parameter is not understood or contains some sort of
+   error, the receiving UA SHOULD issue an MDN with a disposition type
+   of "failed" (see Section 3.2.6) and include a Failure field (see
+   Section 3.2.7) that further describes the problem.  MDNs with the a
+   disposition type of "failed" and a "Failure" field MAY also be
+   generated when other types of errors are detected in the parameters
+   of the Disposition-Notification-Options header.
+
+   However, an MDN with a disposition type of "failed" MUST NOT be
+   generated if the user has indicated a preferance that MDNs are not to
+   be sent.  If user consent would be required for an MDN of some other
+   disposition type to be sent, user consent SHOULD also be obtained
+   before sending an MDN with a disposition type of "failed".
+
+2.3 The Original-Recipient Header
+
+   Since electronic mail addresses may be rewritten while the message is
+   in transit, it is useful for the original recipient address to be
+   made available by the delivering MTA.  The delivering MTA may be able
+   to obtain this information from the ORCPT parameter of the SMTP RCPT
+   TO command, as defined in RFC 1891 [8].  If this information is
+   available, the delivering MTA SHOULD insert an Original-Recipient
+   header at the beginning of the message (along with the Return-Path
+   header).  The delivering MTA MAY delete any other Original-Recipient
+   headers that occur in the message.  The syntax of this header, using
+   the ABNF of RFC 822 [2], is as follows
+
+     original-recipient-header =
+          "Original-Recipient" ":" address-type ";" generic-address
+
+
+
+
+Fajman                      Standards Track                     [Page 6]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   The address-type and generic-address token are as as specified in the
+   description of the Original-Recipient field in section 3.2.3.
+
+   The purpose of carrying the original recipient information and
+   returning it in the MDN is to permit automatic correlation of MDNs
+   with the original message on a per-recipient basis.
+
+2.4 Use with the Message/Partial Content Type
+
+   The use of the headers Disposition-Notification-To, Disposition-
+   Notification-Options, and Original-Recipient with the MIME
+   Message/partial content type (RFC 2046 [5]) requires further
+   definition.
+
+   When a message is segmented into two or more message/partial
+   fragments, the three headers mentioned in the above paragraph SHOULD
+   be placed in the "inner" or "enclosed" message (using the terms of
+   RFC 2046 [5]).  These headers SHOULD NOT be used in the headers of
+   any of the fragments themselves.
+
+   When the multiple message/partial fragments are reassembled, the
+   following applies.  If these headers occur along with the other
+   headers of a message/partial fragment message, they pertain to an MDN
+   to be generated for the fragment.  If these headers occur in the
+   headers of the "inner" or "enclosed" message (using the terms of RFC
+   2046 [5]), they pertain to an MDN to be generated for the reassembled
+   message.  Section 5.2.2.1 of RFC 2046 [5]) is amended to specify
+   that, in addition to the headers specified there, the three headers
+   described in this specification are to be appended, in order, to the
+   headers of the reassembled message.  Any occurances of the three
+   headers defined here in the headers of the initial enclosing message
+   must not be copied to the reassembled message.
+
+3.  Format of a Message Disposition Notification
+
+   A message disposition notification is a MIME message with a top-
+   level content-type of multipart/report (defined in RFC 1892 [7]).
+   When a multipart/report content is used to transmit an MDN:
+
+   (a)  The report-type parameter of the multipart/report content is
+        "disposition-notification".
+
+   (b)  The first component of the multipart/report contains a human-
+        readable explanation of the MDN, as described in RFC 1892 [7].
+
+   (c)  The second component of the multipart/report is of content-type
+        message/disposition-notification, described in section 3.1 of
+        this document.
+
+
+
+Fajman                      Standards Track                     [Page 7]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   (d)  If the original message or a portion of the message is to be
+        returned to the sender, it appears as the third component of the
+        multipart/report.  The decision of whether or not to return the
+        message or part of the message is up to the UA generating the
+        MDN.  However, in the case of encrypted messages requesting
+        MDNs, encrypted message text MUST be returned, if it is returned
+        at all, only in its original encrypted form.
+
+        NOTE:  For message dispostion notifications gatewayed from
+        foreign systems, the headers of the original message may not be
+        available.  In this case the third component of the MDN may be
+        omitted, or it may contain "simulated" RFC 822 headers which
+        contain equivalent information.  In particular, it is very
+        desirable to preserve the subject and date fields from the
+        original message.
+
+   The MDN MUST be addressed (in both the message header and the
+   transport envelope) to the address(es) from the Disposition-
+   Notification-To header from the original message for which the MDN is
+   being generated.
+
+   The From field of the message header of the MDN MUST contain the
+   address of the person for whom the message disposition notification
+   is being issued.
+
+   The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
+   null (<>), specifying that no Delivery Status Notification messages
+   or other messages indicating successful or unsuccessful delivery are
+   to be sent in response to an MDN.
+
+   A message disposition notification MUST NOT itself request an MDN.
+   That is, it MUST NOT contain a Disposition-Notification-To header.
+
+   The Message-ID header (if present) for an MDN MUST be different from
+   the Message-ID of the message for which the MDN is being issued.
+
+   A particular MDN describes the disposition of exactly one message for
+   exactly one recipient.  Multiple MDNs may be generated as a result of
+   one message submission, one per recipient.  However, due to the
+   circumstances described in Section 2.1, MDNs may not be generated for
+   some recipients for which MDNs were requested.
+
+3.1 The message/disposition-notification content-type
+
+   The message/disposition-notification content-type is defined as
+   follows:
+
+     MIME type name:                message
+
+
+
+Fajman                      Standards Track                     [Page 8]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+     MIME subtype name:             disposition-notification
+     Optional parameters:           none
+     Encoding considerations:       "7bit" encoding is sufficient and
+                                    MUST be used to maintain readability
+                                    when viewed by non-MIME mail
+                                    readers.
+     Security considerations:       discussed in section 6 of this memo.
+
+   The message/disposition-notification report type for use in the
+   multipart/report is "disposition-notification".
+
+   The body of a message/disposition-notification consists of one or
+   more "fields" formatted according to the ABNF of RFC 822 header
+   "fields" (see [2]).  Using the ABNF of RFC 822, the syntax of the
+   message/disposition-notification content is as follows:
+
+     disposition-notification-content = [ reporting-ua-field CRLF ]
+          [ mdn-gateway-field CRLF ]
+          [ original-recipient-field CRLF ]
+          final-recipient-field CRLF
+          [ original-message-id-field CRLF ]
+          disposition-field CRLF
+          *( failure-field CRLF )
+          *( error-field CRLF )
+          *( warning-field CRLF )
+          *( extension-field CRLF )
+
+3.1.1 General conventions for fields
+
+   Since these fields are defined according to the rules of RFC 822 [2],
+   the same conventions for continuation lines and comments apply.
+   Notification fields may be continued onto multiple lines by beginning
+   each additional line with a SPACE or HTAB.  Text which appears in
+   parentheses is considered a comment and not part of the contents of
+   that notification field.  Field names are case-insensitive, so the
+   names of notification fields may be spelled in any combination of
+   upper and lower case letters.  Comments in notification fields may
+   use the "encoded-word" construct defined in RFC 2047 [6].
+
+3.1.2 "*-type" subfields
+
+   Several fields consist of a "-type" subfield, followed by a semi-
+   colon, followed by "*text".  For these fields, the keyword used in
+   the address-type or MTA-type subfield indicates the expected format
+   of the address or MTA-name that follows.
+
+   The "-type" subfields are defined as follows:
+
+
+
+
+Fajman                      Standards Track                     [Page 9]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   (a)  An "address-type" specifies the format of a mailbox address.
+        For example, Internet Mail addresses use the "rfc822" address-
+        type.
+
+         address-type = atom
+
+   (b)  An "MTA-name-type" specifies the format of a mail transfer
+        agent name.  For example, for an SMTP server on an Internet
+        host, the MTA name is the domain name of that host, and the
+        "dns" MTA-name-type is used.
+
+         mta-name-type = atom
+
+   Values for address-type and mta-name-type are case-insensitive.  Thus
+   address-type values of "RFC822" and "rfc822" are equivalent.
+
+   The Internet Assigned Numbers Authority (IANA) will maintain a
+   registry of address-type and mta-name-type values, along with
+   descriptions of the meanings of each, or a reference to a one or more
+   specifications that provide such descriptions.  (The "rfc822"
+   address-type is defined in RFC 1891 [8].) Registration forms for
+   address-type and mta-name-type appear in RFC 1894 [9].
+
+   IANA will not accept registrations for any address-type name that
+   begins with "X-".  These type names are reserved for experimental
+   use.
+
+3.1.3 Lexical tokens imported from RFC 822
+
+   The following lexical tokens, defined in RFC 822 [2], are used in the
+   ABNF grammar for MDNs:  atom, CRLF, mailbox, msg-id, text.
+
+3.2 Message/disposition-notification Fields
+
+3.2.1 The Reporting-UA field
+
+     reporting-ua-field = "Reporting-UA" ":" ua-name
+                          [ ";" ua-product ]
+
+     ua-name = *text
+
+     ua-product = *text
+
+   The Reporting-UA field is defined as follows:
+
+   A MDN describes the disposition of a message after it has been
+   delivered to a recipient.  In all cases, the Reporting-UA is the UA
+   that performed the disposition described in the MDN.  This field is
+
+
+
+Fajman                      Standards Track                    [Page 10]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   optional, but recommended.  For Internet Mail user agents, it is
+   recommended that this field contain both the DNS name of the
+   particular instance of the UA that generated the MDN and the name of
+   the product.  For example,
+
+     Reporting-UA:  rogers-mac.dcrt.nih.gov; Foomail 97.1
+
+   If the reporting UA consists of more than one component (e.g., a base
+   program and plug-ins), this may be indicated by including a list of
+   product names.
+
+3.2.2 The MDN-Gateway field
+
+   The MDN-Gateway field indicates the name of the gateway or MTA that
+   translated a foreign (non-Internet) message disposition notification
+   into this MDN.  This field MUST appear in any MDN which was
+   translated by a gateway from a foreign system into MDN format, and
+   MUST NOT appear otherwise.
+
+        mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
+
+        mta-name = *text
+
+   For gateways into Internet Mail, the MTA-name-type will normally be
+   "smtp", and the mta-name will be the Internet domain name of the
+   gateway.
+
+3.2.3 Original-Recipient field
+
+   The Original-Recipient field indicates the original recipient address
+   as specified by the sender of the message for which the MDN is being
+   issued.  For Internet Mail messages the value of the
+
+   Original-Recipient field is obtained from the Original-Recipient
+   header from the message for which the MDN is being generated.  If
+   there is no Original-Recipient header in the message, then the
+   Original-Recipient field MUST be omitted, unless the same information
+   is reliably available some other way.  If there is an Original-
+   Recipient header in the original message (or original recipient
+   information is reliably available some other way), then the
+   Original-Recipient field must be supplied.  If there is more than one
+   Original-Recipient header in the message, the UA may choose the one
+   to use or act as if no Original-Recipient header is present.
+
+     original-recipient-field =
+          "Original-Recipient" ":" address-type ";" generic-address
+
+     generic-address = *text
+
+
+
+Fajman                      Standards Track                    [Page 11]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   The address-type field indicates the type of the original recipient
+   address.  If the message originated within the Internet, the
+   address-type field field will normally be "rfc822", and the address
+   will be according to the syntax specified in RFC 822 [2].  The value
+   "unknown" should be used if the Reporting UA cannot determine the
+   type of the original recipient address from the message envelope.
+   This address is the same as that provided by the sender and can be
+   used to automatically correlate MDN reports with original messages on
+   a per recipient basis.
+
+3.2.4 Final-Recipient field
+
+   The Final-Recipient field indicates the recipient for which the MDN
+   is being issued.  This field MUST be present.
+
+   The syntax of the field is as follows:
+
+     final-recipient-field =
+          "Final-Recipient" ":" address-type ";" generic-address
+
+   The generic-address subfield of the Final-Recipient field MUST
+   contain the mailbox address of the recipient (from the From header of
+   the MDN) as it was when the MDN was generated by the UA.
+
+   The Final-Recipient address may differ from the address originally
+   provided by the sender, because it may have been transformed during
+   forwarding and gatewaying into an totally unrecognizable mess.
+   However, in the absence of the optional Original-Recipient field, the
+   Final-Recipient field and any returned content may be the only
+   information available with which to correlate the MDN with a
+   particular message recipient.
+
+   The address-type subfield indicates the type of address expected by
+   the reporting MTA in that context.  Recipient addresses obtained via
+   SMTP will normally be of address-type "rfc822".
+
+   Since mailbox addresses (including those used in the Internet) may be
+   case sensitive, the case of alphabetic characters in the address MUST
+   be preserved.
+
+3.2.5 Original-Message-ID field
+
+   The Original-Message-ID field indicates the message-ID of the message
+   for which the MDN is being issued.  It is obtained from the Message-
+   ID header of the message for which the MDN is issued.  This field
+   MUST be present if the original message contained a Message-ID
+   header.  The syntax of the field is
+
+
+
+
+Fajman                      Standards Track                    [Page 12]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+        original-message-id-field = "Original-Message-ID" ":" msg-id
+
+   The msg-id token is as specified in RFC 822 [2].
+
+3.2.6 Disposition field
+
+   The Disposition field indicates the action performed by the
+   Reporting-UA on behalf of the user.  This field MUST be present.
+
+   The syntax for the Disposition field is:
+
+     disposition-field = "Disposition" ":" disposition-mode ";"
+                         disposition-type
+                         [ '/' disposition-modifier
+                           *( "," dispostion-modifier ) ]
+
+     disposition-mode = action-mode "/" sending-mode
+
+     action-mode = "manual-action" / "automatic-action"
+
+     sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
+
+     disposition-type = "displayed"
+                      / "dispatched"
+                      / "processed"
+                      / "deleted"
+                      / "denied"
+                      / "failed"
+
+     disposition-modifier = ( "error" / "warning" )
+                          / ( "superseded" / "expired" /
+                              "mailbox-terminated" )
+                          / disposition-modifier-extension
+
+     disposition-modifier-extension = atom
+
+   The disposition-mode, disposition-type and disposition-modifier may
+   be spelled in any combination of upper and lower case characters.
+
+3.2.6.1 Disposition modes
+
+   The following disposition modes are defined:
+
+   "manual-action"            The disposition described by the
+                              disposition type was a result of an
+                              explicit instruction by the user rather
+                              than some sort of automatically performed
+                              action.
+
+
+
+Fajman                      Standards Track                    [Page 13]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   "automatic-action"         The disposition described by the
+                              disposition type was a result of an
+                              automatic action, rather than an explicit
+                              instruction by the user for this message.
+
+                              "Manual-action" and "automatic-action" are
+                              mutually exclusive.  One or the other must
+                              be specified.
+
+   "MDN-sent-manually"        The user explicity gave permission for
+                              this particular MDN to be sent.
+
+   "MDN-sent-automatically"   The MDN was sent because the UA had
+                              previously been configured to do so
+                              automatically.
+
+                              "MDN-sent-manually" and "MDN-sent-
+                              automatically" are mutually exclusive.
+                              One or the other must be specified.
+
+3.2.6.2 Disposition types
+
+   The following disposition-types are defined:
+
+   "displayed"    The message has been displayed by the UA to someone
+                              reading the recipient's mailbox.  There is
+                              no guarantee that the content has been
+                              read or understood.
+
+
+   "dispatched"   The message has been sent somewhere in some manner
+                              (e.g., printed, faxed, forwarded) without
+                              necessarily having been previously
+                              displayed to the user.  The user may or
+                              may not see the message later.
+
+   "processed"    The message has been processed in some manner (i.e.,
+                              by some sort of rules or server) without
+                              being displayed to the user.  The user may
+                              or may not see the message later, or there
+                              may not even be a human user associated
+                              with the mailbox.
+
+   "deleted"      The message has been deleted.  The recipient may or
+                              may not have seen the message.  The
+                              recipient might "undelete" the message at
+                              a later time and read the message.
+
+
+
+
+Fajman                      Standards Track                    [Page 14]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   "denied"       The recipient does not wish the sender to be informed
+                              of the message's disposition.  A UA may
+                              also siliently ignore message disposition
+                              requests in this situation.
+
+   "failed"       A failure occurred that prevented the proper
+                              generation of an MDN.  More information
+                              about the cause of the failure may be
+                              contained in a Failure field.  The
+                              "failed" disposition type is not to be
+                              used for the situation in which there is
+                              is some problem in processing the message
+                              other than interpreting the request for an
+                              MDN.  The "processed" or other disposition
+                              type with appropriate disposition
+                              modifiers is to be used in such
+                              situations.
+
+3.2.6.3 Disposition modifiers
+
+   The following disposition modifiers are defined:
+
+   "error"                            An error of some sort occurred
+                                      that prevented successful
+                                      processing of the message.
+                                      Further information is contained
+                                      in an Error field.
+
+   "warning"                          The message was successfully
+                                      processed but some sort of
+                                      exceptional condition occurred.
+                                      Further information is contained
+                                      in a Warning field.
+
+   "superseded"                       The message has been
+                                      automatically rendered obsolete by
+                                      another message received.  The
+                                      recipient may still access and
+                                      read the message later.
+
+   "expired"                          The message has reached its
+                                      expiration date and has been
+                                      automatically removed from the
+                                      recipient's mailbox.
+
+   "mailbox-terminated"               The recipient's mailbox has been
+                                      terminated and all message in it
+                                      automatically removed.
+
+
+
+Fajman                      Standards Track                    [Page 15]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+                                      "Obsoleted", "expired", and
+                                      "terminated" are to be used with
+                                      the "deleted" disposition type and
+                                      the "autoaction" and "autosent"
+                                      disposition modifiers.
+
+   disposition-modifier-extension     Additional disposition modifiers
+                                      may be defined in the future by
+                                      later revisions or extensions to
+                                      this specification.  Disposition
+                                      value names beginning with "X-"
+                                      will never be defined as standard
+                                      values; such names are reserved
+                                      for experimental use.  MDN
+                                      disposition value names NOT
+                                      beginning with "X-" MUST be
+                                      registered with the Internet
+                                      Assigned Numbers Authority (IANA)
+                                      and described in a standards-
+                                      track RFC or an experimental RFC
+                                      approved by the IESG.  See Section
+                                      10 for a registration form.  MDNs
+                                      with disposition modifier names
+                                      not understood by the receiving UA
+                                      MAY be silently ignored or placed
+                                      in the user's mailbox without
+                                      special inter- pretation.  They
+                                      MUST not cause any error message
+                                      to be sent to the sender of the
+                                      MDN.
+
+                                      If an UA developer does not wish
+                                      to register the meanings of such
+                                      disposition modifier extensions,
+                                      "X-" modifiers may be used for
+                                      this purpose.  To avoid name
+                                      collisions, the name of the UA
+                                      implementation should follow the
+                                      "X-", (e.g. "X-Foomail-fratzed").
+
+   It is not required that a UA be able to generate all of the possible
+   values of the Disposition field.
+
+   One and only one MDN may be issued on behalf of each particular
+   recipient by their user agent.  That is, once an MDN has been issued
+   on behalf of a recipient, no further MDNs may be issued on behalf of
+   that recipient, even if another disposition is performed on the
+   message.  However, if a message is forwarded, a "dispatched" MDN may
+
+
+
+Fajman                      Standards Track                    [Page 16]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   been issued for the recipient doing the forwarding and the recipient
+   of the forwarded message may also cause an MDN to be generated.
+
+3.2.7 Failure, Error and Warning fields
+
+   The Failure, Error and Warning fields are used to supply additional
+   information in the form of text messages when the "failure"
+   disposition type, "error" disposition modifier, and/or the "warning"
+   disposition modifer appear.  The syntax is
+
+     failure-field = "Failure" ":" *text
+
+     error-field = "Error" ":" *text
+
+     warning-field = "Warning" ":" *text
+
+3.3 Extension fields
+
+   Additional MDN fields may be defined in the future by later revisions
+   or extensions to this specification.  Extension-field names beginning
+   with "X-" will never be defined as standard fields; such names are
+   reserved for experimental use.  MDN field names NOT beginning with
+   "X-" MUST be registered with the Internet Assigned Numbers Authority
+   (IANA) and described in a standards-track RFC or an experimental RFC
+   approved by the IESG.  See Section 10 for a registration form.
+
+   Extension MDN fields may be defined for the following reasons:
+
+   (a)  To allow additional information from foreign disposition
+        reports to be tunneled through Internet MDNs.  The names of such
+        MDN fields should begin with an indication of the foreign
+        environment name (e.g. X400-Physical-Forwarding-Address).
+
+   (b)  To allow transmission of diagnostic information which is
+        specific to a particular user agent (UA).  The names of such MDN
+        fields should begin with an indication of the UA implementation
+        which produced the MDN.  (e.g. Foomail-information).
+
+   If an application developer does not wish to register the meanings of
+   such extension fields, "X-" fields may be used for this purpose.  To
+   avoid name collisions, the name of the application implementation
+   should follow the "X-", (e.g. "X-Foomail-Log-ID" or "X-EDI-info").
+
+4.  Timeline of events
+
+   The following timeline shows when various events in the processing of
+   a message and generation of MDNs take place:
+
+
+
+
+Fajman                      Standards Track                    [Page 17]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   -- User composes message
+
+   -- User tells UA to send message
+
+   -- UA passes message to MTA (original recipient information
+      passed along)
+
+   -- MTA sends message to next MTA
+
+   -- Final MTA receives message
+
+   -- Final MTA delivers message to UA (possibily generating DSN)
+
+   -- UA performs automatic processing and generates corresponding
+      MDNs ("dispatched", "processed", "deleted", "denied" or "failed"
+      disposition type with "automatic-action" and "MDN-sent-
+      automatically" disposition modes)
+
+   -- UA displays list of messages to user
+
+   -- User selects a message and requests that some action be
+      performed on it.
+
+   -- UA performs requested action and, with user's permission,
+      sends appropriate MDN ("displayed", "dispatched", "processed",
+      "deleted", "denied" or "failed" disposition type with "manual-
+      action" and "MDN-sent-manually" or "MDN-sent-automatically"
+      disposition mode).
+
+   -- User possibly performs other actions on message, but no
+      further MDNs are generated.
+
+5.  Conformance and Usage Requirements
+
+   A UA or gateway conforms to this specification if it generates MDNs
+   according to the protocol defined in this memo.  It is not necessary
+   to be able to generate all of the possible values of the Disposition
+   field.
+
+   UAs and gateways MUST NOT generate the Original-Recipient field of an
+   MDN unless the mail protocols provide the address originally
+   specified by the sender at the time of submission.  Ordinary SMTP
+   does not make that guarantee, but the SMTP extension defined in RFC
+   1891 [8] permits such information to be carried in the envelope if it
+   is available.  The Original-Recipient header defined in this document
+   provides a way for the MTA to pass the original recipient address to
+   the UA.
+
+
+
+
+Fajman                      Standards Track                    [Page 18]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   Each sender-specified recipient address may result in more than one
+   MDN.  If an MDN is requested for a recipient that is forwarded to
+   multiple recipients of an "alias" (as defined in RFC 1891 [8],
+   section 6.2.7.3), each of the recipients may issue an MDN.
+
+   Successful distribution of a message to a mailing list exploder
+   SHOULD be considered final disposition of the message.  A mailing
+   list exploder may issue an MDN with a disposition type of "processed"
+   and disposition modes of "automatic-action" and "MDN- sent-
+   automatically" indicating that the message has been forwarded to the
+   list.  In this case, the request for MDNs is not propogated to the
+   members of the list.
+
+   Alternaively, the mailing list exploder may issue no MDN and
+   propogate the request for MDNs to all members of the list.  The
+   latter behavior is not recommended for any but small, closely knit
+   lists, as it might cause large numbers of MDNs to be generated and
+   may cause confidential subscribers to the list to be revealed.  It is
+   also permissible for the mailing list exploder to direct MDNs to
+   itself, correlate them, and produce a report to the original sender
+   of the message.
+
+   This specification places no restrictions on the processing of MDNs
+   received by user agents or mailing lists.
+
+6.  Security Considerations
+
+   The following security considerations apply when using MDNs:
+
+6.1 Forgery
+
+   MDNs may be forged as easily as ordinary Internet electronic mail.
+   User agents and automatic mail handling facilities (such as mail
+   distribution list exploders) that wish to make automatic use of MDNs
+   should take appropriate precautions to minimize the potential damage
+   from denial-of-service attacks.
+
+   Security threats related to forged MDNs include the sending of:
+
+   (a)  A falsified disposition notification when the indicated
+        disposition of the message has not actually ocurred,
+
+   (b)  Unsolicited MDNs
+
+6.2 Confidentiality
+
+   Another dimension of security is confidentiality.  There may be cases
+   in which a message recipient does not wish the disposition of
+
+
+
+Fajman                      Standards Track                    [Page 19]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   messages addressed to him to be known or is concerned that the
+   sending of MDNs may reveal other confidential information (e.g., when
+   the message was read).  In this situation, it is acceptable for the
+   UA to issue "denied" MDNs or to silently ignore requests for MDNs.
+
+   If the Disposition-Notification-To header is passed on unmodified
+   when a message is distributed to the subscribers of a mailing list,
+   the subscribers to the list may be revealed to the sender of the
+   original message by the generation of MDNs.
+
+   Headers of the original message returned in part 3 of the
+   multipart/report could reveal confidential information about host
+   names and/or network topology inside a firewall.
+
+   An unencrypted MDN could reveal confidential information about an
+   encrypted message, especially if all or part of the original message
+   is returned in part 3 of the multipart/report.  Encrypted MDNs are
+   not defined in this specification.
+
+   In general, any optional MDN field may be omitted if the Reporting UA
+   site or user determines that inclusion of the field would impose too
+   great a compromise of site confidentiality.  The need for such
+   confidentiality must be balanced against the utility of the omitted
+   information in MDNs.
+
+6.3 Non-Repudiation
+
+   Within the framework of today's Internet Mail, the MDNs defined in
+   this document provide valuable information to the mail user; however,
+   MDNs can not be relied upon as a guarantee that a message was or was
+   not not seen by the recipient.  Even if MDNs are not actively forged,
+   they may be lost in transit.  The MDN issuing mechanism may be
+   bypassed in some manner by the recipient.
+
+7.  Collected Grammar
+
+   NOTE:  The following lexical tokens are defined in RFC 822:  atom,
+   CRLF, mailbox, msg-id, text.  The definitions of attribute and value
+   are as in the definition of the Content-Type header in RFC 2045 [4].
+
+   Message headers:
+
+   mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox
+
+   Disposition-Notification-Options =
+        "Disposition-Notification-Options" ":"
+        disposition-notification-parameters
+
+
+
+
+Fajman                      Standards Track                    [Page 20]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   disposition-notification-parameters = parameter *(";" parameter)
+
+   parameter = attribute "=" importance "," 1#value
+
+   importance = "required" / "optional"
+
+   original-recipient-header =
+        "Original-Recipient" ":" address-type ";" generic-address
+
+
+   Report content:
+
+   disposition-notification-content = [ reporting-ua-field CRLF ]
+        [ mdn-gateway-field CRLF ]
+        [ original-recipient-field CRLF ]
+        final-recipient-field CRLF
+        [ original-message-id-field CRLF ]
+        disposition-field CRLF
+        *( failure-field CRLF )
+        *( error-field CRLF )
+        *( warning-field CRLF )
+        *( extension-field CRLF )
+
+   address-type = atom
+
+   mta-name-type = atom
+
+   reporting-ua-field = "Reporting-UA" ":" ua-name
+                        [ ";" ua-product ]
+
+   ua-name = *text
+
+   ua-product = *text
+
+   mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name
+
+   mta-name = *text
+
+   original-recipient-field =
+        "Original-Recipient" ":" address-type ";" generic-address
+
+   generic-address = *text
+
+   final-recipient-field =
+        "Final-Recipient" ":" address-type ";" generic-address
+
+   disposition-field = "Disposition" ":" disposition-mode ";"
+                       disposition-type
+
+
+
+Fajman                      Standards Track                    [Page 21]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+                       [ '/' disposition-modifier
+                         *( "," dispostion-modifier ) ]
+
+   disposition-mode = action-mode "/" sending-mode
+
+   action-mode = "manual-action" / "automatic-action"
+
+   sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
+
+   disposition-type = "displayed"
+                    / "dispatched"
+                    / "processed"
+                    / "deleted"
+                    / "denied"
+                    / "failed"
+
+   disposition-modifier = ( "error" / "warning" )
+                        / ( "superseded" / "expired" /
+                            "mailbox-terminated" )
+                        / disposition-modifier-extension
+
+   disposition-modifier-extension = atom
+
+   original-message-id-field = "Original-Message-ID" ":" msg-id
+
+   failure-field = "Failure" ":" *text
+
+   error-field = "Error" ":" *text
+
+   warning-field = "Warning" ":" *text
+
+   extension-field = extension-field-name ":" *text
+
+   extension-field-name = atom
+
+8.  Guidelines for Gatewaying MDNs
+
+   NOTE:  This section provides non-binding recommendations for the
+   construction of mail gateways that wish to provide semi-transparent
+   disposition notifications between the Internet and another electronic
+   mail system.  Specific MDN gateway requirements for a particular pair
+   of mail systems may be defined by other documents.
+
+8.1 Gatewaying from other mail systems to MDNs
+
+   A mail gateway may issue an MDN to convey the contents of a "foreign"
+   disposition notification over Internet Mail.  When there are
+   appropriate mappings from the foreign notification elements to MDN
+
+
+
+Fajman                      Standards Track                    [Page 22]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   fields, the information may be transmitted in those MDN fields.
+   Additional information (such as might be needed to tunnel the foreign
+   notification through the Internet) may be defined in extension MDN
+   fields.  (Such fields should be given names that identify the foreign
+   mail protocol, e.g. X400-* for X.400 protocol elements)
+
+   The gateway must attempt to supply reasonable values for the
+   Reporting-UA, Final-Recipient, and Disposition fields.  These will
+   normally be obtained by translating the values from the foreign
+   notification into their Internet-style equivalents.  However, some
+   loss of information is to be expected.
+
+   The sender-specified recipient address, and the original message-id,
+   if present in the foreign notification, should be preserved in the
+   Original-Recipient and Original-Message-ID fields.
+
+   The gateway should also attempt to preserve the "final" recipient
+   address from the foreign system.  Whenever possible, foreign protocol
+   elements should be encoded as meaningful printable ASCII strings.
+
+   For MDNs produced from foreign disposition notifications, the name of
+   the gateway MUST appear in the MDN-Gateway field of the MDN.
+
+8.2 Gatewaying from MDNs to other mail systems
+
+   It may be possible to gateway MDNs from the Internet into a foreign
+   mail system.  The primary purpose of such gatewaying is to convey
+   disposition information in a form that is usable by the destination
+   system.  A secondary purpose is to allow "tunneling" of MDNs through
+   foreign mail systems, in case the MDN may be gatewayed back into the
+   Internet.
+
+   In general, the recipient of the MDN (i.e., the sender of the
+   original message) will want to know, for each recipient:  the closest
+   available approximation to the original recipient address, and the
+   disposition (displayed, printed, etc.).
+
+   If possible, the gateway should attempt to preserve the Original-
+   Recipient address and Original-Message-ID (if present), in the
+   resulting foreign disposition report.
+
+   If it is possible to tunnel an MDN through the destination
+   environment, the gateway specification may define a means of
+   preserving the MDN information in the disposition reports used by
+   that environment.
+
+
+
+
+
+
+Fajman                      Standards Track                    [Page 23]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+9.  Example
+
+   NOTE:  This example is provided as illustration only, and is not
+   considered part of the MDN protocol specification.  If the example
+   conflicts with the protocol definition above, the example is wrong.
+
+   Likewise, the use of *-type subfield names or extension fields in
+   this example is not to be construed as a definition for those type
+   names or extension fields.
+
+9.1 This is an MDN issued after a message has been displayed to the user
+   of an Internet Mail user agent.
+
+   Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
+   From: Joe Recipient <Joe_Recipient@mega.edu>
+   Message-Id: <199509200019.12345@mega.edu>
+   Subject: Disposition notification
+   To: Jane Sender <Jane_Sender@huge.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=disposition-notification;
+         boundary="RAA14128.773615765/mega.edu"
+
+   --RAA14128.773615765/mega.edu
+
+   The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
+   Recipient <Joe_Recipient@mega.edu> with subject "First draft of
+   report" has been displayed.  This is no guarantee that the message
+   has been read or understood.
+
+   --RAA14128.773615765/mega.edu
+   content-type: message/disposition-notification
+
+   Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1
+   Original-Recipient: rfc822;Joe_Recipient@mega.edu
+   Final-Recipient: rfc822;Joe_Recipient@mega.edu
+   Original-Message-ID: <199509192301.23456@huge.com>
+   Disposition: manual-action/MDN-sent-manually; displayed
+
+   --RAA14128.773615765/mega.edu
+   content-type: message/rfc822
+
+   [original message goes here]
+
+   --RAA14128.773615765/mega.edu--
+
+
+
+
+
+
+
+Fajman                      Standards Track                    [Page 24]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+10.  IANA Registration Forms
+
+   The forms below are for use when registering a new parameter name for
+   the Disposition-Notification-Options header, a new disposition
+   modifier name, or a new MDN extension field.  Each piece of
+   information required by a registration form may be satisfied either
+   by providing the information on the form itself, or by including a
+   reference to a published, publicly available specification that
+   includes the necessary information.  IANA MAY reject registrations
+   because of incomplete registration forms, imprecise specifications,
+   or inappropriate names.
+
+   To register, complete the applicable form below and send it via
+   electronic mail to <IANA@IANA.ORG>.
+
+10.1 IANA registration form for Disposition-Notification-Options header
+   parameter names
+
+   A registration for a Disposition-Notification-Options header
+   parameter name MUST include the following information:
+
+   (a) The proposed parameter name.
+
+   (b) The syntax for parameter values, specified using BNF, ABNF,
+   regular expressions, or other non-ambiguous language.
+
+   (c) If parameter values are not composed entirely of graphic
+   characters from the US-ASCII repertoire, a specification for how they
+   are to be encoded as graphic US-ASCII characters in a Disposition-
+   Notification-Options header.
+
+   (d) A reference to a standards track RFC or experimental RFC approved
+   by the IESG that describes the semantics of the parameter values.
+
+10.2 IANA registration form for disposition modifer names
+
+   A registration for a disposition-modifier name MUST include the
+   following information:
+
+   (a) The proposed disposition-modifier name.
+
+   (b) A reference to a standards track RFC or experimental RFC approved
+   by the IESG that describes the semantics of the disposition modifier.
+
+10.3 IANA registration form for MDN extension field names
+
+   A registration for an MDN extension field name MUST include the
+   following information:
+
+
+
+Fajman                      Standards Track                    [Page 25]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   (a) The proposed extension field name.
+
+   (b) The syntax for extension values, specified using BNF, ABNF,
+   regular expressions, or other non-ambiguous language.
+
+   (c) If extension field values are not composed entirely of graphic
+   characters from the US-ASCII repertoire, a specification for how they
+   are to be encoded as graphic US-ASCII characters in a Disposition-
+   Notification-Options header.
+
+   (d) A reference to a standards track RFC or experimental RFC approved
+   by the IESG that describes the semantics of the extension field.
+
+11.  Acknowledgments
+
+   This document is based on the Delivery Status Notifications document,
+   RFC 1894 [9], by Keith Moore and Greg Vaudreuil.  Contributions were
+   made by members of the IETF Receipt Working Group, including Harald
+   Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned
+   Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell,
+   Pete Resnick, Chuck Shih.
+
+12.  References
+
+   [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+         August 1982.
+
+   [2]   Crocker, D., "Standard for the Format of ARPA Internet Text
+         Messages", STD 11, RFC 822, August 1982.
+
+   [3]   Braden, R. (ed.), "Requirements for Internet Hosts -
+         Application and Support", STD 3, RFC 1123, October 1989.
+
+   [4]   Freed, N., and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One:  Format of Internet Message
+         Bodies", RFC 2045, November 1996.
+
+   [5]   Freed, N., and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part Two:  Media Types", RFC 2046, November
+         1996.
+
+   [6]   Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part
+         Three:  Message Header Extensions for Non-Ascii Text", RFC
+         2047, November 1996.
+
+   [7]   Vaudreuil, G., "The Multipart/Report Content Type for the
+         Reporting of Mail System Administrative Messages", RFC 1892,
+         January 1996.
+
+
+
+Fajman                      Standards Track                    [Page 26]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+   [8]   Moore, K., "SMTP Service Extension for Delivery Status
+         Notifications", RFC 1891, January 1996.
+
+   [9]   Moore, K., and G. Vaudreuil, "An Extensible Format for
+         Delivery Status Notifications, RFC 1894, January 1996.
+
+   [10]  Bradner, S., "Key Words for Use in RFCs to Indicate
+         Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+13.  Author's Address
+
+   Roger Fajman
+   National Institutes of Health
+   Building 12A, Room 3063
+   12 South Drive MSC 5659
+   Bethesda, Maryland 20892-5659
+   USA
+
+   EMail:  raf@cu.nih.gov
+   Phone:  +1 301 402 4265
+   Fax:    +1 301 480 6241
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajman                      Standards Track                    [Page 27]
+
+RFC 2298           Message Disposition Notifications          March 1998
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fajman                      Standards Track                    [Page 28]
+
diff --git a/docs/rfc3028.txt b/docs/rfc3028.txt
new file mode 100644
index 00000000..d909a542
--- /dev/null
+++ b/docs/rfc3028.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                       T. Showalter
+Request for Comments: 3028                               Mirapoint, Inc.
+Category: Standards Track                                   January 2001
+
+
+                    Sieve: A Mail 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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes a language for filtering e-mail 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 it has no
+   variables, loops, or ability to shell out to external programs.
+
+Table of Contents
+
+   1.      Introduction ...........................................   3
+   1.1.     Conventions Used in This Document .....................   4
+   1.2.     Example mail messages .................................   4
+   2.      Design .................................................   5
+   2.1.     Form of the Language ..................................   5
+   2.2.     Whitespace ............................................   5
+   2.3.     Comments ..............................................   6
+   2.4.     Literal Data ..........................................   6
+   2.4.1.   Numbers ...............................................   6
+   2.4.2.   Strings ...............................................   7
+   2.4.2.1. String Lists ..........................................   7
+   2.4.2.2. Headers ...............................................   8
+   2.4.2.3. Addresses .............................................   8
+   2.4.2.4. MIME Parts ............................................   9
+   2.5.     Tests .................................................   9
+   2.5.1.   Test Lists ............................................   9
+
+
+
+Showalter                   Standards Track                     [Page 1]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   2.6.     Arguments .............................................   9
+   2.6.1.   Positional Arguments ..................................   9
+   2.6.2.   Tagged Arguments ......................................  10
+   2.6.3.   Optional Arguments ....................................  10
+   2.6.4.   Types of Arguments ....................................  10
+   2.7.     String Comparison .....................................  11
+   2.7.1.   Match Type ............................................  11
+   2.7.2.   Comparisons Across Character Sets .....................  12
+   2.7.3.   Comparators ...........................................  12
+   2.7.4.   Comparisons Against Addresses .........................  13
+   2.8.     Blocks ................................................  14
+   2.9.     Commands ..............................................  14
+   2.10.    Evaluation ............................................  15
+   2.10.1.  Action Interaction ....................................  15
+   2.10.2.  Implicit Keep .........................................  15
+   2.10.3.  Message Uniqueness in a Mailbox .......................  15
+   2.10.4.  Limits on Numbers of Actions ..........................  16
+   2.10.5.  Extensions and Optional Features ......................  16
+   2.10.6.  Errors ................................................  17
+   2.10.7.  Limits on Execution ...................................  17
+   3.      Control Commands .......................................  17
+   3.1.     Control Structure If ..................................  18
+   3.2.     Control Structure Require .............................  19
+   3.3.     Control Structure Stop ................................  19
+   4.      Action Commands ........................................  19
+   4.1.     Action reject .........................................  20
+   4.2.     Action fileinto .......................................  20
+   4.3.     Action redirect .......................................  21
+   4.4.     Action keep ...........................................  21
+   4.5.     Action discard ........................................  22
+   5.      Test Commands ..........................................  22
+   5.1.     Test address ..........................................  23
+   5.2.     Test allof ............................................  23
+   5.3.     Test anyof ............................................  24
+   5.4.     Test envelope .........................................  24
+   5.5.     Test exists ...........................................  25
+   5.6.     Test false ............................................  25
+   5.7.     Test header ...........................................  25
+   5.8.     Test not ..............................................  26
+   5.9.     Test size .............................................  26
+   5.10.    Test true .............................................  26
+   6.      Extensibility ..........................................  26
+   6.1.     Capability String .....................................  27
+   6.2.     IANA Considerations ...................................  28
+   6.2.1.   Template for Capability Registrations .................  28
+   6.2.2.   Initial Capability Registrations ......................  28
+   6.3.     Capability Transport ..................................  29
+   7.      Transmission ...........................................  29
+
+
+
+Showalter                   Standards Track                     [Page 2]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   8.      Parsing ................................................  30
+   8.1.     Lexical Tokens ........................................  30
+   8.2.     Grammar ...............................................  31
+   9.      Extended Example .......................................  32
+   10.     Security Considerations ................................  34
+   11.     Acknowledgments ........................................  34
+   12.     Author's Address .......................................  34
+   13.     References .............................................  34
+   14.     Full Copyright Statement ...............................  36
+
+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 GUIs for filter creation and manipulation.  The language is
+   not Turing-complete: it provides no way to write a loop or a function
+   and variables are not provided.
+
+   Scripts written in Sieve are executed during final delivery, when the
+   message is moved to the user-accessible mailbox.  In systems where
+   the MTA does final delivery, such as traditional Unix mail, it is
+   reasonable to sort 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
+   e-mail, 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.
+
+
+
+Showalter                   Standards Track                     [Page 3]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+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", "SHOULD", "SHOULD NOT", and
+   "MAY" in this document are to be interpreted as defined in
+   [KEYWORDS].
+
+   Each section on a command (test, action, or control structure) has a
+   line labeled "Syntax:".  This line describes the syntax 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
+   parenthesis are used for grouping, similar to [ABNF].
+
+   In the "Syntax" 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 in section 10 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, nor 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@desert.example.org
+   To: roadrunner@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
+
+
+
+
+Showalter                   Standards Track                     [Page 4]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   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@desert.example.org
+   -----------------------------------------------------------
+
+   Message B
+   -----------------------------------------------------------
+   From: youcouldberich!@reply-by-postal-mail.invalid
+   Sender: b1ff@de.res.example.com
+   To: rube@landru.example.edu
+   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.
+
+   The language is represented in UTF-8, as specified in [UTF-8].
+
+   Tokens in the ASCII range are considered case-insensitive.
+
+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.
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 5]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+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 and strings.
+
+2.4.1.   Numbers
+
+   Numbers are given as ordinary decimal numbers.  However, those
+   numbers that have a tendency to be fairly large, such as message
+   sizes, MAY have a "K", "M", or "G" 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 tebi-, or 1,073,741,824 (2^30) times the value of the
+   number [BINARY-SI].
+
+   Implementations MUST provide 31 bits of magnitude in numbers, but MAY
+   provide more.
+
+   Only positive integers are permitted by this specification.
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 6]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+2.4.2.   Strings
+
+   Scripts involve large numbers of strings 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, ASCII 34).  A backslash ("\", ASCII 92) inside of a quoted
+   string is followed by either another backslash or a double quote.
+   This two-character sequence represents a single backslash or double-
+   quote within the string, respectively.
+
+   No other characters should be escaped with a single 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").
+
+   Non-printing characters such as tabs, CR and LF, and control
+   characters are permitted in quoted strings.  Quoted strings MAY span
+   multiple lines.  NUL (ASCII 0) is not allowed in strings.
+
+   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.  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
+   which 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 dot-stuffed;
+   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.
+   Implementations are encouraged to use short-circuit evaluation in
+   these cases.
+
+
+
+Showalter                   Standards Track                     [Page 7]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   For instance, the test `header :contains ["To", "Cc"]
+   ["me@example.com", "me00@landru.example.edu"]' is true if either the
+   To header or Cc header of the input message contains either of the
+   e-mail addresses "me@example.com" or "me00@landru.example.edu".
+
+   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] [RFC1123], 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.
+
+   Folding of long header lines (as described in [IMAIL] 3.4.8) is
+   removed prior to interpretation of the data.  The folding syntax (the
+   CRLF that ends a line plus any leading whitespace at the beginning of
+   the next line that indicates folding) are interpreted as if they were
+   a single space.
+
+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.  Using the symbols defined in [IMAIL], section 6.1, 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 used
+   here.
+
+   Implementations MUST ensure that the addresses are syntactically
+   valid, but need not ensure that they actually identify an email
+   recipient.
+
+
+
+
+
+Showalter                   Standards Track                     [Page 8]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+2.4.2.4. MIME Parts
+
+   In a few places, [MIME] body parts are represented as strings.  These
+   parts include MIME headers and the body.  This provides a way of
+   embedding typed data within a Sieve script so that, among other
+   things, character sets other than UTF-8 can be used for output
+   messages.
+
+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/else to
+   decide which block of code is run.
+
+   Tests MUST NOT have side effects.  That is, a test cannot affect the
+   state of the filter or message.  No tests in this specification have
+   side effects, and side effects are forbidden in extension tests as
+   well.
+
+   The rationale for this is that tests with side effects impair
+   readability and maintainability and are difficult to represent in a
+   graphic interface for generating scripts.  Side effects are confined
+   to actions where they are clearer.
+
+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.
+
+   Example:  if anyof (not exists ["From", "Date"],
+                   header :contains "from" "fool@example.edu") {
+                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.
+
+2.6.1.   Positional Arguments
+
+   Positional arguments are given to a command which 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.
+
+
+
+
+Showalter                   Standards Track                     [Page 9]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+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 numbers or strings 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
+   with commands, but they still may be reordered arbitrarily provided
+   they appear before positional arguments.  Tagged arguments may be
+   mixed with optional arguments.
+
+   To simplify this specification, 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 [ACAP] comparator will be used to
+   compare two strings, since different languages may impose different
+   orderings on UTF-8 [UTF-8] characters.
+
+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 9.2 presents a parsable version of this:
+   Arguments are string-lists, numbers, and tags, which may be followed
+
+
+
+Showalter                   Standards Track                    [Page 10]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   by a test or a test-list, which may be followed by a block of
+   commands.  No more than one test or test list, nor more than one
+   block of commands, may be used, and commands that end with blocks 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 borrows ACAP's comparator registry.
+
+   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
+
+   There are three match types describing the matching used in this
+   specification:  ":is", ":contains", and ":matches".  Match type
+   arguments are supplied to those commands which allow them to specify
+   what kind of match is to be performed.
+
+   These are used as tagged arguments to tests that perform string
+   comparison.
+
+   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 null 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 null key ":is" and only ":is" the null value.
+
+   The ":matches" version specifies a wildcard match using the
+   characters "*" and "?".  "*" matches zero or more characters, and "?"
+   matches a single character.  "?" 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.
+
+
+
+Showalter                   Standards Track                    [Page 11]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   In order to specify what type of match is supposed to happen,
+   commands that support matching take optional tagged arguments
+   ":matches", ":is", and ":contains".  Commands default to using ":is"
+   matching if no match type argument is supplied.  Note that these
+   modifiers may interact with comparators; in particular, some
+   comparators are not 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.
+
+   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
+
+   All Sieve scripts are represented in UTF-8, but messages may involve
+   a number of character sets.  In order for comparisons to work across
+   character sets, implementations SHOULD implement the following
+   behavior:
+
+      Implementations decode header charsets to UTF-8.  Two strings are
+      considered equal if their UTF-8 representations are identical.
+      Implementations should decode charsets represented in the forms
+      specified by [MIME] for both message headers and bodies.
+      Implementations must be capable of decoding US-ASCII, ISO-8859-1,
+      the ASCII subset of ISO-8859-* character sets, and UTF-8.
+
+   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.  Comparators
+   are described for [ACAP]; a registry is defined for ACAP, and this
+   specification uses that registry.
+
+   ACAP defines multiple comparator types.  Only equality types are used
+   in this specification.
+
+
+
+
+
+Showalter                   Standards Track                    [Page 12]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   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 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 and use a
+   comparator with ":matches" or ":contains" that is not compatible with
+   it.
+
+   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 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
+
+
+
+
+Showalter                   Standards Track                    [Page 13]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   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.
+
+   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.  Blocks are
+   supplied to commands so that the commands can implement control
+   commands.
+
+   A control structure is a command that happens to take a test and a
+   block as one of its arguments; depending on the result of the test
+   supplied as another argument, it runs the code in the block some
+   number of times.
+
+   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.  So there are two arguments, the test and the
+   block.
+
+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.
+
+
+
+Showalter                   Standards Track                    [Page 14]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   A control command is similar, but it takes a test as an argument, and
+   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 4.4) 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 will.
+
+   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.
+
+2.10.3.  Message Uniqueness in a Mailbox
+
+   Implementations SHOULD NOT deliver a message to the same folder more
+   than once, even if a script explicitly asks for a message to be
+   written to a mailbox twice.
+
+
+
+Showalter                   Standards Track                    [Page 15]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   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 numbers 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 prohibit more than one reject.
+
+   Implementations MUST allow at least one keep or one fileinto.  If
+   fileinto is not implemented, implementations MUST allow at least one
+   keep.
+
+   Implementations SHOULD prohibit reject when used with other actions.
+
+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.
+
+   If a script does not understand an extension declared with require,
+   the script must not be used at all.  Implementations MUST NOT execute
+   scripts which require unknown capability names.
+
+   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.
+
+         Experience with PostScript suggests that mechanisms that allow
+         a script to work around missing extensions are not used in
+         practice.
+
+   Extensions which define actions MUST state how they interact with
+   actions discussed in the base specification.
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 16]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+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 might even go so far as to ensure that scripts can
+   never execute an invalid set of actions (e.g., reject + fileinto)
+   before execution, although this could involve solving the Halting
+   Problem.
+
+   This specification allows any of these approaches.  Solving the
+   Halting Problem is considered extra credit.
+
+   When an error happens, implementations MUST notify the user that an
+   error occurred, 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.
+
+3.      Control Commands
+
+   Control structures are needed to allow for multiple and conditional
+   actions.
+
+
+
+Showalter                   Standards Track                    [Page 17]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+3.1.     Control Structure 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 MUST only follow an if, and an else MUST follow only either an
+   if or an elsif.  An error occurs if these conditions are not met.
+
+   Syntax:   if <test1: test> <block1: block>
+
+   Syntax:   elsif <test2: test> <block2: block>
+
+   Syntax:   else <block>
+
+   The semantics are similar to those of any of the many other
+   programming languages these control commands 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 case.
+
+   This provides a way of performing exactly one of the blocks in the
+   chain.
+
+   In the following example, both Message A and B are dropped.
+
+   Example:  require "fileinto";
+             if header :contains "from" "coyote" {
+                discard;
+             } elsif header :contains ["subject"] ["$$$"] {
+                discard;
+             } else {
+                fileinto "INBOX";
+             }
+
+
+   When the script below is run over message A, it redirects the message
+   to  acm@example.edu;  message B, to postmaster@example.edu; any other
+   message is redirected to field@example.edu.
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 18]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Example:  if header :contains ["From"] ["coyote"] {
+                redirect "acm@example.edu";
+             } elsif header :contains "Subject" "$$$" {
+                redirect "postmaster@example.edu";
+             } else {
+                redirect "field@example.edu";
+             }
+
+   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 Structure Require
+
+   Syntax:   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 Structure Stop
+
+   Syntax:   stop
+
+   The "stop" action ends all processing.  If no actions have been
+   executed, then the keep action is taken.
+
+4.      Action Commands
+
+   This document supplies five actions that may be taken on a message:
+   keep, fileinto, redirect, reject, and discard.
+
+   Implementations MUST support the "keep", "discard", and "redirect"
+   actions.
+
+   Implementations SHOULD support "reject" and "fileinto".
+
+
+
+
+
+Showalter                   Standards Track                    [Page 19]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Implementations MAY limit the number of certain actions taken (see
+   section 2.10.4).
+
+4.1.     Action reject
+
+   Syntax:   reject <reason: string>
+
+   The optional "reject" action refuses delivery of a message by sending
+   back an [MDN] to the sender.  It resends the message to the sender,
+   wrapping it in a "reject" form, noting that it was rejected by the
+   recipient.  In the following script, message A is rejected and
+   returned to the sender.
+
+   Example:  if header :contains "from" "coyote@desert.example.org" {
+                reject "I am not taking mail from you, and I don't want
+                your birdseed, either!";
+             }
+
+   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
+   original sender that mail was refused by a filter.  This part of  the
+   MDN might appear as follows:
+
+   ------------------------------------------------------------
+   Message was refused by recipient's mail filtering program.  Reason
+   given was as follows:
+
+   I am not taking mail from you, and I don't want your birdseed,
+   either!
+   ------------------------------------------------------------
+
+   The MDN action-value field as defined in the MDN specification MUST
+   be "deleted" and MUST have the MDN-sent-automatically and automatic-
+   action modes set.
+
+   Because some implementations can not or will not implement the reject
+   command, it is optional.  The capability string to be used with the
+   require command is "reject".
+
+4.2.     Action fileinto
+
+   Syntax:   fileinto <folder: string>
+
+   The "fileinto" action delivers the message into the specified folder.
+   Implementations SHOULD support fileinto, but in some environments
+   this may be impossible.
+
+
+
+Showalter                   Standards Track                    [Page 20]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   The capability string for use with the require command is "fileinto".
+
+   In the following script, message A is filed into folder
+   "INBOX.harassment".
+
+   Example:  require "fileinto";
+             if header :contains ["from"] "coyote" {
+                fileinto "INBOX.harassment";
+             }
+
+4.3.     Action redirect
+
+   Syntax:   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
+   headers, but it may add new headers.  The "redirect" modifies the
+   envelope recipient.
+
+   The redirect command performs an MTA-style "forward"--that is, what
+   you get from a .forward file using sendmail under UNIX.  The address
+   on the SMTP envelope is replaced with the one on the redirect command
+   and the message is sent back out.  (This is not an MUA-style forward,
+   which creates a new message with a different sender and message ID,
+   wrapping the old message in a new one.)
+
+   A simple script can be used for redirecting all mail:
+
+   Example:  redirect "bart@example.edu";
+
+   Implementations SHOULD take measures to implement loop control,
+   possibly including adding headers to the message or counting received
+   headers.  If an implementation detects a loop, it causes an error.
+
+4.4.     Action keep
+
+   Syntax:   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
+   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.
+
+
+
+
+
+Showalter                   Standards Track                    [Page 21]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   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.5.     Action discard
+
+   Syntax:   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@example.edu" is thrown
+   out.
+
+   Example:  if header :contains ["from"] ["idiot@example.edu"] {
+                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.
+
+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.
+
+
+
+
+Showalter                   Standards Track                    [Page 22]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+5.1.     Test address
+
+   Syntax:   address [ADDRESS-PART] [COMPARATOR] [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.
+
+   Like envelope and header, this test returns true if any combination
+   of the header-list and key-list arguments match.
+
+   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, nor 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, Resent-To, and SHOULD include any other header
+   that utilizes an "address-list" structured header body.
+
+   Example:  if address :is :all "from" "tim@example.com" {
+                discard;
+
+5.2.     Test allof
+
+   Syntax:   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.
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 23]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+5.3.     Test anyof
+
+   Syntax:   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
+
+   Syntax:   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.
+
+   If one of the envelope-part strings is (case insensitive) "from",
+   then matching occurs against the FROM address used in the SMTP MAIL
+   command.
+
+   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.
+
+   Like address and header, this test returns true if any combination of
+   the envelope-part and key-list arguments is true.
+
+   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.
+
+
+
+
+
+Showalter                   Standards Track                    [Page 24]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Example:  require "envelope";
+             if envelope :all :is "from" "tim@example.com" {
+                discard;
+             }
+
+5.5.     Test exists
+
+   Syntax:   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
+
+   Syntax:   false
+
+   The "false" test always evaluates to false.
+
+5.7.     Test header
+
+   Syntax:   header [COMPARATOR] [MATCH-TYPE]
+             <header-names: string-list> <key-list: string-list>
+
+   The "header" test evaluates to true if any header name 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 string-list and key-list arguments match.
+
+   If a header listed in the header-names argument exists, it contains
+   the null key ("").  However, if the named header is not present, it
+   does not contain the null key.  So if a message contained the header
+
+           X-Caffeine: C8H10N4O2
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 25]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   these tests on that header evaluate as follows:
+
+           header :is ["X-Caffeine"] [""]         => false
+           header :contains ["X-Caffeine"] [""]   => true
+
+5.8.     Test not
+
+   Syntax:   not <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
+
+   Syntax:   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.
+
+   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 from the
+   initial header until the last character in the message body.
+
+   Note that for a message that is exactly 4,000 octets, the message is
+   neither ":over" 4000 octets or ":under" 4000 octets.
+
+5.10.    Test true
+
+   Syntax:   true
+
+   The "true" test always evaluates to true.
+
+6.      Extensibility
+
+   New control structures, 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.
+
+
+
+Showalter                   Standards Track                    [Page 26]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Any extensions to this language MUST define a capability string that
+   uniquely identifies that extension.  If a new version of an extension
+   changes the functionality of a previously defined extension, it MUST
+   use a different name.
+
+   In a situation where there is a 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.
+
+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:
+
+   envelope    The string "envelope" indicates that the implementation
+               supports the "envelope" command.
+
+   fileinto    The string "fileinto" indicates that the implementation
+               supports the "fileinto" command.
+
+   reject      The string "reject" indicates that the implementation
+               supports the "reject" 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.
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 27]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+6.2.     IANA Considerations
+
+   In order to provide a standard set of extensions, a registry is
+   provided by IANA.  Capability names may be registered on a first-
+   come, first-served basis.  Extensions designed for interoperable use
+   SHOULD be defined as standards track or IESG approved experimental
+   RFCs.
+
+6.2.1.     Template for Capability Registrations
+
+   The following template is to be used for registering new Sieve
+   extensions with IANA.
+
+   To: iana@iana.org
+   Subject: Registration of new Sieve extension
+
+   Capability name:
+   Capability keyword:
+   Capability arguments:
+   Standards Track/IESG-approved experimental RFC number:
+   Person and email address to contact for further information:
+
+6.2.2.     Initial Capability Registrations
+
+   The following are to be added to the IANA registry for Sieve
+   extensions as the initial contents of the capability registry.
+
+   Capability name:        fileinto
+   Capability keyword:     fileinto
+   Capability arguments:   fileinto <folder: string>
+   Standards Track/IESG-approved experimental RFC number:
+           RFC 3028 (Sieve base spec)
+   Person and email address to contact for further information:
+           Tim Showalter
+           tjs@mirapoint.com
+
+   Capability name:        reject
+   Capability keyword:     reject
+   Capability arguments:   reject <reason: string>
+   Standards Track/IESG-approved experimental RFC number:
+           RFC 3028 (Sieve base spec)
+   Person and email address to contact for further information:
+           Tim Showalter
+           tjs@mirapoint.com
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 28]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   Capability name:        envelope
+   Capability keyword:     envelope
+   Capability arguments:
+           envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
+           <envelope-part: string-list> <key-list: string-list>
+   Standards Track/IESG-approved experimental RFC number:
+           RFC 3028 (Sieve base spec)
+   Person and email address to contact for further information:
+           Tim Showalter
+           tjs@mirapoint.com
+
+   Capability name:        comparator-*
+   Capability keyword:
+           comparator-* (anything starting with "comparator-")
+   Capability arguments:   (none)
+   Standards Track/IESG-approved experimental RFC number:
+           RFC 3028, Sieve, by reference of
+           RFC 2244, Application Configuration Access Protocol
+   Person and email address to contact for further information:
+           Tim Showalter
+           tjs@mirapoint.com
+
+6.3.     Capability Transport
+
+   As the range of mail systems that this document is intended to apply
+   to is quite varied, 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
+   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 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.
+
+
+
+Showalter                   Standards Track                    [Page 29]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+    Security considerations: Discussed in section 10 of RFC 3028.
+    Interoperability considerations: Discussed in section 2.10.5
+       of RFC 3028.
+    Published specification: RFC 3028.
+    Applications which use this media type: sieve-enabled mail servers
+    Additional information:
+      Magic number(s):
+      File extension(s): .siv
+      Macintosh File Type Code(s):
+    Person & email address to contact for further information:
+       See the discussion list at ietf-mta-filters@imc.org.
+    Intended usage:
+       COMMON
+    Author/Change controller:
+       See Author information in RFC 3028.
+
+8.      Parsing
+
+   The Sieve grammar is separated into tokens and a separate grammar as
+   most programming languages are.
+
+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 ASCII.
+
+   The following are tokens in Sieve:
+
+           - identifiers
+           - tags
+           - numbers
+           - quoted strings
+           - multi-line strings
+           - other separators
+
+   Blanks, horizontal tabs, CRLFs, and comments ("white space") are
+   ignored except as they separate tokens.  Some white space is required
+   to separate otherwise adjacent tokens and in specific places in the
+   multi-line strings.
+
+   The other separators are single individual characters, and are
+   mentioned explicitly in the grammar.
+
+   The lexical structure of sieve is defined in the following BNF (as
+   described in [ABNF]):
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 30]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   bracket-comment = "/*" *(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) "*/"
+           ;; 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.)
+
+   CHAR-NOT-DOT = (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff)
+           ;; no dots, no CRLFs
+
+   CHAR-NOT-CRLF = (%x01-09 / %x0b-0c / %x0e-ff)
+
+   CHAR-NOT-SLASH = (%x00-57 / %x58-ff)
+
+   CHAR-NOT-STAR = (%x00-51 / %x53-ff)
+
+   comment = bracket-comment / hash-comment
+
+   hash-comment = ( "#" *CHAR-NOT-CRLF CRLF )
+
+   identifier = (ALPHA / "_") *(ALPHA DIGIT "_")
+
+   tag = ":" identifier
+
+   number = 1*DIGIT [QUANTIFIER]
+
+   QUANTIFIER = "K" / "M" / "G"
+
+   quoted-string = DQUOTE *CHAR DQUOTE
+           ;; in general, \ CHAR inside a string maps to CHAR
+           ;; so \" maps to " and \\ maps to \
+           ;; note that newlines and other characters are all allowed
+           ;; strings
+
+   multi-line          = "text:" *(SP / HTAB) (hash-comment / CRLF)
+                         *(multi-line-literal / multi-line-dotstuff)
+                         "." CRLF
+   multi-line-literal  = [CHAR-NOT-DOT *CHAR-NOT-CRLF] CRLF
+   multi-line-dotstuff = "." 1*CHAR-NOT-CRLF CRLF
+           ;; A line containing only "." ends the multi-line.
+           ;; Remove a leading '.' if followed by another '.'.
+
+   white-space = 1*(SP / CRLF / HTAB) / comment
+
+8.2.     Grammar
+
+   The following is the grammar of Sieve after it has been lexically
+   interpreted.  No white space or comments appear below.  The start
+   symbol is "start".
+
+
+
+Showalter                   Standards Track                    [Page 31]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   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) ")"
+
+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", "reject"];
+
+    #
+    # Reject any large messages (note that the four leading dots get
+    # "stuffed" to three)
+    #
+    if size :over 1M
+            {
+            reject text:
+    Please do not send me large attachments.
+    Put your file on a server and send me the URL.
+    Thank you.
+    .... Fred
+    .
+    ;
+            stop;
+            }
+    #
+
+
+
+Showalter                   Standards Track                    [Page 32]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+    # 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"
+            {
+            fileinto "filter";  # move to "filter" folder
+            }
+    #
+    # Keep all messages to or from people in my company
+    #
+    elsif address :domain :is ["From", "To"] "example.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@example.com",
+                 header :matches "subject"
+                   ["*make*money*fast*", "*university*dipl*mas*"])
+            {
+            # 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";
+            }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 33]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+10.     Security Considerations
+
+   Users must get their mail.  It is imperative that whatever method
+   implementations use to store the user-defined filtering scripts be
+   secure.
+
+   It is equally important that implementations sanity-check the user's
+   scripts, and not allow users to create on-demand mailbombs.  For
+   instance, an implementation that allows a user to reject or redirect
+   multiple times to a single message might also allow a user to create
+   a mailbomb triggered by mail from a specific user.  Site- or
+   implementation-defined limits on actions are useful for this.
+
+   Several commands, such as "discard", "redirect", and "fileinto" allow
+   for actions to be taken that are potentially very dangerous.
+
+   Implementations SHOULD take measures to prevent languages from
+   looping.
+
+11.     Acknowledgments
+
+   I am very thankful to Chris Newman for his support and his ABNF
+   syntax checker, to John Myers and Steve Hole for outlining the
+   requirements for the original drafts, to Larry Greenfield for nagging
+   me about the grammar and finally fixing it, to Greg Sereda for
+   repeatedly fixing and providing examples, to Ned Freed for fixing
+   everything else, to Rob Earhart for an early implementation and a
+   great deal of help, and to Randall Gellens for endless amounts of
+   proofreading.  I am grateful to Carnegie Mellon University where most
+   of the work on this document was done.  I am also indebted to all of
+   the readers of the ietf-mta-filters@imc.org mailing list.
+
+12.     Author's Address
+
+   Tim Showalter
+   Mirapoint, Inc.
+   909 Hermosa Court
+   Sunnyvale, CA 94085
+
+   EMail: tjs@mirapoint.com
+
+13.  References
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 34]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+   [ACAP]      Newman, C. and J. G. Myers, "ACAP -- Application
+               Configuration Access Protocol", RFC 2244, November 1997.
+
+   [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 1894, January
+               1996.
+
+   [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.
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IMAP]      Crispin, M., "Internet Message Access Protocol - version
+               4rev1", RFC 2060, December 1996.
+
+   [IMAIL]     Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, August 1982.
+
+   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [MDN]       Fajman, R., "An Extensible Message Format for Message
+               Disposition Notifications", RFC 2298, March 1998.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts --
+               Application and Support", STD 3, RFC 1123, November 1989.
+
+   [SMTP]      Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, August 1982.
+
+   [UTF-8]     Yergeau, F., "UTF-8, a transformation format of Unicode
+               and ISO 10646", RFC 2044, October 1996.
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 35]
+
+RFC 3028            Sieve: A Mail Filtering Language        January 2001
+
+
+14. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                    [Page 36]
+
diff --git a/docs/rfc3431.txt b/docs/rfc3431.txt
new file mode 100644
index 00000000..2bf17bdb
--- /dev/null
+++ b/docs/rfc3431.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
new file mode 100644
index 00000000..3bbc5976
--- /dev/null
+++ b/docs/rfc3598.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+