HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 11:28:03 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 18 Apr 1997 10:02:00 GMT ETag: "3dd9b9-8bb0-33574698" Accept-Ranges: bytes Content-Length: 35760 Connection: close Content-Type: text/plain Network Working Group T. Showalter Internet Draft Carnegie Mellon Document: draft-showalter-sieve-00.txt April 1997 Expire in six months (10/97) SIEVE: A Mail Filtering Language Status of this Memo This document is an Internet-Draft. 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 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. Abstract This document describes a mail filtering language for filtering messages at time of final delivery. It is designed to be independent of protocol, and implementable on either a mail client or mail server which uses multiple folders. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating systems used to implement it. Mail filtering systems are widely used for a variety of reasons, including organization of messages (filtering out mailing list messages for separate reading). They are becoming increasingly useful in avoiding unsolicited mail. Existing languages are not consistant across client, server, or operating system, and are frequently difficult for users to use. This language is not tied to any particular system or mail architecture and is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box IMAP servers. Showalter [Page 1] draft-showalter-sieve-00.txt SIEVE April 1997 Table of Contents This document is content-free. Showalter [Page 2] draft-showalter-sieve-00.txt SIEVE April 1997 0. Unfinished 0.1. Known Weaknesses The following suggestions have been made, and will probably be addressed by extensions. An extension for regular expressions will be written. While regular expressions are of questionable usefulness for users, the programmers writing implementations desperately want regular expressions. Envelope-matching commands are not readily supported by all mail systems, and putting them in the draft will result in a system that cannot be implemented by a mail architecture that does not adequately store envelopes. "Detailed" addressing or "subaddressing" (i.e., the "fmh" in an address "tjs+fmh@andrew.cmu.edu") is not handled, and will be moved to an extension for those systems that offer it. The newline problem is relatively, but not completely, solved. We'll be arguing this until the end of time. A previous version included a "valid" test. I have tentatively removed it because Randy had noted it was too fuzzy to implement, and that's probably true. The formal grammar is not complete, and needs to be revised to make the best use of ABNF, whatever its final state is. My knowledge of email is not comprehensive, and as a result, there might be a better way to express some of the concepts in here. An "include" command is not included, but has been suggested for an extension. I need to run a spelling checker on this document. I hate nroff. 0.2. Open Issues Do "fileinto" commands need to be moved to a separate document? 1. Introduction There are a number of reasons to use a filtering system. Mail traffic for most users has been increasing due both to increased Showalter [Page 3] draft-showalter-sieve-00.txt SIEVE April 1997 usage of e-mail, the emergence of unsolicited email as a form of advertising, and increased usage of mailing lists. This language is offered in order to try and provide a standard language that can be used to create filters for e-mail. It is not tied to any particular operating system or mail architecture. It requires the use of [IMAIL]-compliant messages and support of multiple folders, but should work with a wide variety of systems that support these criteria. The language is powerful enough to be useful, but limited in power in order to allow for a reasonably bulletproof server-side filtering system. The language is not Turing-complete, and provides no way to write a loop or a function, nor are variables are provided. The intention is to make it impossible for users to do anything more complex than write simple mail filters. Implementations of the language are expected to take place at time of final delivery. In systems where the MTA does final delivery -- IMAP4 and traditional UNIX mail, for instance, it is reasonable to sort when the MTA deposits mail into the user's mailbox. If the MTA does not do final delivery, or lacks the power to sort into separate mailboxes (as is the case under POP3), the MUA must do filtering into local filters. 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 users did not make use of the Andrew system's FLAMES filtering language due to difficulty in programming it. Due to this expectation, this language has been made simple enough to allow many users to make use of it. 1.1. Conventions used in this document Line breaks have been inserted for readability. In the sections of this document that discuss the requirements of various keywords and operators, the following conventions have been adopted. Each section on an test, action, or conditional has a line labeled "Syntax:". This line describes the arguments each command requires. Required arguments are listed inside angle brackets ("<" and ">"). Optional arguments are listed inside square brackets ("[" and "]"). The formal grammar for these commands is described in section 10 and is the authoritative reference on how to construct these commands. Showalter [Page 4] draft-showalter-sieve-00.txt SIEVE April 1997 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and "MAY" in this document are to be interpreted as defined in [KEYWORDS]. 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@anvil.dementia.org To: roadrunner@birdseed.thekeep.org Subject: I have a present for you Look, I'm sorry about the whole anvil thing, but I can make it up to you. I've got some great birdseed over here at my place -- top of the line stuff -- and if you come by, I'll have it all wrapped up for you. I'm really sorry for all the problems I've caused for you over the years, and I know we can work this out. ----------------------------------------------------------- Message B ----------------------------------------------------------- From: youcouldberich!@reply-by-postal-mail Sender: b1ff@znic.net To: rube@znic.net Date: Mon, 31 Mar 1997 18:26:10 -0800 (PST) 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 This language is made up as a set of commands. Each command is either an action or a conditional. Each conditional contains a test; depending on the results of the test, one set of commands in a Showalter [Page 5] draft-showalter-sieve-00.txt SIEVE April 1997 control structure is taken. 2.2. Whitespace Whitespace is used to separate commands. Whitespace is made up of tabs, newlines (which can be CR, LF, or both), and the space character. The amount of whitespace used is not significant. 2.3. Comments Comments begin with a "#" character that is not contained within a string and continue until the next newline. Example: if size over 100K then # this is a comment toss endif 2.4. Numbers Numbers are normally given as ordinary decimal numbers. However, those numbers that have a tendency to be fairly large, such as message sizes, such as message sizes, may have a "K", "M", or "G" appended to indicate a multiple of a base-two number. To be comparable with the power- of-two-based versions of SI units that computers fre- quently use, K specifies kilo, or 1,024 (2^10) times the value of the number; M specifies mega, or 1,048,576 (2^20) times the value of the number; and G specifies giga, or 1,073,741,824 (2^30) times the value of the number. Numbers are limited to 32 bits by this specification. [OPEN: If numbers are limited to 32 bits, gigabit-sized numbers probably aren't very useful. Should I remove them?] 2.5. Strings Scripts involve large numbers of strings. Typically, short quoted strings suffice for most uses, but a more convenient form is provided for longer strings. A quoted string starts and ends with a single double quote (the " character). A backslash ("\") inside of a quoted string is followed by either another backslash or a double quote. This two-character sequence represents a Showalter [Page 6] draft-showalter-sieve-00.txt SIEVE April 1997 single backslash or double-quote within the string. [If there are missing words in the paragraph, I had problems with nroff; please point it out to me.] For entering larger amounts of text, such as an email message, a longer form is allowed, known as a "user- message". It starts with the keyword "message" and ends with the sequence of a newline, a single period, and another newline. Any line that begins with ".." is con- sidered to begin with ".". XXX this example needs formatting work Example: if any-of (header ("from") contains ("bart" "homer" "smithers" "burns" "lisa"), header ("subject") contains ("URGENT")) then fileinto "INBOX" else reply message # multi-line message here: You are not one of the people I regularly correspond with. I have deleted your message due to the large volume of email I regularly receive. If you feel that you need to speak with me directly, and cannot find your answer in my web pages, please send mail with the word "URGENT" in the subject line. Thank you for your time. , <-- XXX should be a "." \. endif 2.5.1. Headers [OPEN ISSUE: Is this section necessary or useful?] Headers are a subset of strings. In the Internet Message Specifica- tion [IMAIL], each header line is allowed to have whitespace nearly anywhere in the line, including after the field name and before the subsequent colon. Thus, the lines "From: acm@andrew.cmu.edu" is equivalent to "From : acm@andrew.cmu.edu". Within a SIEVE script, header names are never considered to have spaces. Only the "From" in the above headers is considered to be there. While a header can be listed as "From " within a header list (say, for the "header" command) such usage is absurd. The following colon is never specified; a header "From:", as well as a header ":From", is guaranteed never to happen within a valid header. 2.5.2. Addresses Showalter [Page 7] draft-showalter-sieve-00.txt SIEVE April 1997 [OPEN ISSUE: Is this section necessary or useful?] A number of commands call for email addresses, which are also a sub- set of strings. These addresses must be compliant with [IMAIL]. Implementations MUST insure the addresses are syntactically valid, and need not insure that they are actually deliverable. 2.7. Evaluation If evaluation of the script fails to file the message into any mail- box, as in the following script, the message is filed into INBOX. With any of the short messages offered above, the following script produces no actions. Example: if size over 500K then toss endif then the "normal" action is taken. The "normal" action is defined to be the action that is taken normally, such as in a situation where the user does no filtering. Under most situations, the normal action is to file into the user's main mailbox (such as "INBOX" under IMAP). Implementations define the specific meanings of actions. Implementa- tions may impose restrictions on the actions taken, such as only honoring one "reply", "bounce", or "forward" per message. Precedence is not important in any of the commands in this base specification. However, as an extension might make it more impor- tant, all rules MUST be evaluated in left-to-right order. Those operations that may implement short-circuit evaluation (such as the "all-of" and "any-of" operators, which preform logical "and" and "or" operations, respectively) SHOULD do so. 3. Conditionals and Control Structures In order for a script to do more than one set of actions, control structures are needed. 3.1. If Syntax: if then [elsif then [elsif ...]] [else ] endif The "if" control structure is borrowed from any number of programming languages. It is evaluated in the usual way, as follows: if is true, then are evaluated. If an elsif keyword exists, and is true, then are evaluated. Any Showalter [Page 8] draft-showalter-sieve-00.txt SIEVE April 1997 number of elsif cases may be included, and are evaluated serially. If is false and the s are false as well, then the are evaluated. The "if" block is terminated with an "endif" keyword, which is required. In the following example, both Message A and B are dropped. Example: if header ("from") contains ("coyote") then toss elsif header ("subject") contains ("$$$") then toss else fileinto "INBOX" endif Only one set of commands in an if ... elsif ... elsif ... else ... endif block is executed. In the script below, when run over message A, forwards the message to acm@andrew.cmu.edu; message B, to service@andrew.cmu.edu; any other message is forwarded to postman@andrew.cmu.edu. Example: if header ("") contains ("") then forward "acm@andrew.cmu.edu"; elsif header ("Subject") contains ("$$$") then forward "service@andrew.cmu.edu"; else forward "postman@andrew.cmu.edu"; endif 3.2. Require Syntax: require Require SHOULD be declared in a user script before an extension is used. It instructs the evaluator that the extension named extension-name, supplied as a string, MUST be present in order to allow further processing. If the string specifies an extension that the evaluating mechanism supports, then processing continues. Other- wise, an error has been encountered, and the script should not be evaluated. Require is intended to demand the use of an extension not present in this document. The following example will fail on any server that does not implement the extension known as DWIM. Showalter [Page 9] draft-showalter-sieve-00.txt SIEVE April 1997 Example: require "dwim"; if header ("subject") contains-nocase ("the secret message") then dwim blurdybloop body; endif stop 4. Actions This document supplies six actions that may be taken on a message: normal, fileinto, forward, bounce, toss, and stop. 4.1. Action bounce Syntax: bounce The "bounce" action resends the message to the sender, wrapping it in a "bounce" form, noting that it was rejected by the recipient. In the following script, message A is bounced to the sender. Example: if header ("from") contains ("coyote@anvil.dementia.org") then bounce "I am not taking mail from you, you killer!" endif 4.2. Action fileinto Syntax: fileinto [OPEN ISSUE: I could be talked into making fileinto optional for POP3 server agents that wanted to simply throw mail out and then do user filtering on the client.] The "fileinto" action drops the message into a named folder. In the following script, message A is filed into folder "INBOX.harassment". Example: if header ("to") contains 4.3. Action forward Syntax: forward
The "forward" action is used to forward the message to another user at the supplied address, as a mail forwarding feature does. The "forward" action makes no changes to the message body or headers, and only modifies the envelope. A simple script can be used for forwarding: Example: forward "tjs@andrew.cmu.edu" Showalter [Page 10] draft-showalter-sieve-00.txt SIEVE April 1997 4.4. Action normal Syntax: normal The "normal" action is whatever action is taken in lieu of all other actions; generally, this simply means to drop the message into the user's normal mailbox. This command provides a way to execute this action without naming it explicitly, providing a way to use it independent of system. Syntax: if size under 1M then normal else toss 4.5. Action reply Syntax: reply The "reply" action is used to generate a form letter reply to the original sender. Message is a string to be sent as a reply message. The multi-line production described in the Formal Grammar section is intended for this purpose. In the following exam- ple, any message over 500K (or 512,000 octets) would be thrown out; otherwise, the message would be filed into INBOX. Example: if size over 500K reply message Your message was unnecessarily large. I reject all large messages; you will need to contact me directly. toss endif OPEN: Specify headers transmitted? OPEN: Specify way to do vacation? A previous version of this had a -days switch to specify number of days to do a new reply. 4.6. Action stop The "stop" action ends all processing. If no actions have been executed, then the normal action is taken. In the following script, if the mail is from the address "wall@andrew.cmu.edu" it is forwarded to "tjs@xanadu.wv.us"; other- wise the mail receives a reply, and is thrown out. Example: if (header ("from") matches ("wall@andrew.cmu.edu")) then forward "tjs@xanadu.wv.us"; stop endif reply "I'm on vacation and not taking any messages; try after Sunday. I have thrown your message out. Please resend it later." ; toss Showalter [Page 11] draft-showalter-sieve-00.txt SIEVE April 1997 4.7. Action toss Toss drops the message. In the following script, any mail from "wall@andrew.cmu.edu" is thrown out. Example: if header ("from") contains ("wall@andrew.cmu.edu") then toss endif 5. Tests Tests are used in conditionals to decide which part(s) of the condi- tional to execute. 5.1. all-of Syntax: all-of ( [,] [,] ... ) The all-of test preforms a logical AND on the tests supplied to it. The comma in between tests is optional. Example: all-of (false false) => false all-of (false true) => false all-of (true, true) => true 5.2. any-of Syntax: all-of ( [,] [,] ... ) The any-of test preforms a logical OR on the tests supplied to it. The comma in between tests is optional. Example: all-of (false false) => false all-of (false true) => true all-of (true, true) => true 5.3. exists Syntax: exists The "exists" test is true if the headers listed in the argument exist within the message. All of the headers must exist or the test is false. Showalter [Page 12] draft-showalter-sieve-00.txt SIEVE April 1997 Example: if not exists ("From" "Date" "Subject" "To" "Message-ID") then toss endif 5.4. false Syntax: false The "false" test always evaluates to false. 5.5. header Syntax: header <"contains"/"is"/"matches"/"contains-nocase" / "is- nocase"/"matches-nocase"> The "header" test evaluates to true if the header name matches key. How the match is done is described by the second argument. The basic matching forms are case sensitive. Each matching form has a corresponding form ending in "-nocase"; these are not case sensitive. All matchings on header field names MUST be done in a case insensi- tive manner. The "is" argument demands that one of the fields of the headers listed in header-name-list can be found in the key-list. It requires an absolute match. It is true if there are repeated arguments in the header-name-list or the key-list. The "contains" argument demands that one of the values of the headers named in header-name-list partially matches one of the values in key-list. It is true if there are repeated arguments in the header- name-list or the key-list. The string "" is contained in any header that exists. The "matches" argument demands that one of the fields of the headers listed in header-name-list matches a "glob" pattern described by one of the members of key-list. A glob pattern is a UNIX-style filename glob, which has the following special characters: * Match zero or more characters ? Match any single character Escape next character The string "" matches all strings that exist. That is, if a message Showalter [Page 13] draft-showalter-sieve-00.txt SIEVE April 1997 contains the line [XXX formatted improperly] X-Blurdybloop: death to the heathens the tests on that header evaluate as follows: header ("X-Blurdyblop") is ("") => false header ("X-Blurdyblop") matches ("") => true header ("X-Blurdyblop") contains ("") => true 5.6. not Syntax: not The "not" test takes some other test, and returns the opposite result. 5.7. size Syntax: size <"over" / "under"> The "size" test deals with the size of a message. The test is true only if the second argument is "over" and the size of the message is strictly greater than the number of octets specified as limit. If the second argument is "under", then the test is true only if the message size is strictly less than the number of octets specified as limit. In either case, if the message size is exactly the limit, the test is false. 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. 5.8. support Syntax: support The "support" test evaluates to true if the extension named by is supported. In the following script, all mail is filed into INBOX unless the "black-magic" extension is supported. Otherwise, behavior is defined by the black-magic extension. Syntax: if support "black-magic" then Showalter [Page 14] draft-showalter-sieve-00.txt SIEVE April 1997 black-magic ("kgb@andrew.cmu.edu") endif 5.9. true Syntax: true The "true" test is always true. 6. Errors in Processing a Script In any sort of programming language, even a very simple one, errors are inevitable. In this case, users are expected to make errors -- even if the actual script is machine-generated, mailbox rights might change to disallow users from writing to a mailbox, a mailbox may no longer exist, or a variety of other problems. It is imperative that mail be allowed to get through in any case. If an error is found in a script, an implementation MUST make an attempt to resolve the condition. Implementations SHOULD check a script before it is run in order to insure that it is valid. Imple- mentations SHOULD NOT try and recover from a script with errors, and should file mail into the user's primary mailbox. Users MUST be notified of errors in processing a script. The method by which users are notified is implementation defined, but a mail message describing the error is suggested if a preferable alternative cannot be found Implementations that allow for the script to be checked for syntax errors in advance of mail receipt (i.e., client-based filtering, or server-based filtering with a submission protocol aware of this language) SHOULD notify the user of the error and refuse to accept a syntactically invalid script, or one that makes use of extensions that the server does not report. Implementations that allow server-based filtering (i.e., as part of an IMAP server) MUST allow mail to be filed normally (i.e., for IMAP, into the user's INBOX) in case of a syntax error in the script, and MUST notify the user of an error in some form (such as sending the user a mail message notifying them of the error). Implementations SHOULD avoid over-sending error messages to the user's mailbox. Implementations are REQUIRED to notify users of errors in filtering scripts. If there are errors in the script being used, mail SHOULD be filed into INBOX. Implementations MUST NOT discard mail. Showalter [Page 15] draft-showalter-sieve-00.txt SIEVE April 1997 7. Extensibility New control structures, actions, and tests can be added to the language. Sites must make these features known to their users; an extension negotiation mechanism is not defined by this document. For the formal grammar, an extension SHOULD define one of the symbols beginning with "extension-". Any extensions to this language MUST define a unique string that describes that extension. Such strings SHOULD include a version number. The purpose of such a string is for the "require" and "sup- port" conditionals, which mandates that script requires the use of that extension. Additionally, in a situation where there is a sub- mission protocol and an extension advertisement mechanism, so that scripts submitted can be checked against the mail server for valid extensions. 7.1. Capability Mechanism [A brief description of the capability string will be included here.] 7.2. Registry [A registration mechanism will be included here.] 7.3. Capability Transport [A brief description of what is required for a capability transport will be defined here. Transports will be defined in separate docu- ments.] 8. Transmission This document does not define a method for accessing stored scripts at run-time or as they are written, nor does it define a character set encoding for scripts. If the method of handing a script off to the server allows for MIME- typing of data as described in [MIME] and the data is encoded in UTF-8 as described in [UTF-8], the MIME type for a SIEVE script is XXX/XXX. Implementations SHOULD check a script before it is run in order to insure that it is valid. Implementations SHOULD NOT try and recover from a script with errors, and should file mail into the user's pri- mary mailbox. Showalter [Page 16] draft-showalter-sieve-00.txt SIEVE April 1997 9. Acknowledgments 10. Formal Grammar The grammar used in this section is the same as the ABNF described in [ABNF] with one exception: the delimiter used with "#" is any amount of whitespace (that is, CR, LF, spaces, and tabs), as described by the "WSP" terminal, followed by a single comma, and additional whi- tespace. Two commas without something in between them is a protocol error, and is prohibited. In the case of alternative or optional rules in which a later rule overlaps an earlier rule, the rule which is listed earlier MUST take priority. action = toss / fileinto / forward / bounce / reply / stop / extension-action address = string ;; any legal IMAIL address any-of = "any-of" WSP "(" [WSP] #(condition) [WSP] ")" all-of = "all-of" WSP "(" [WSP] #(condition) [WSP] ")" big-number = number [ UNIT ] bounce = "bounce" WSP string ;; string is a text message to be sent with the bounce as the ;; reason control-structure = if / extension-control-structure command = action [WSP] ";" [WSP] / control-structure commands = #(command) comment = "#" *CHAR newline fileinto = "fileinto" WSP string forward = "forward" WSP address if = "if" WSP test WSP "then" WSP commands WSP #("elsif" WSP test WSP "then" WSP commands) [ "else" WSP commands WSP ] "endif" ;; if then ;; [elsif then [elsif ...]] Showalter [Page 17] draft-showalter-sieve-00.txt SIEVE April 1997 ;; [else ] endif header = "header" WSP string-list WSP match-keyword WSP string-list match-keyword = "contains" / "matches" / "is" / "contains-nocase" / "contains-nocase" / "is-nocase" newline = CRLF / CR / LF ;; A CRLF is ALWAYS one newline. number = 1*DIGIT or = condition WSP "or" WSP condition quoted-string = " ;; ;; \ inside a string maps to ;; Note that newlines and other weird characters ;; are all strings. size = "size" WSP ( "over" / "under" ) WSP big-number stop = "stop" string = quoted-string / user-message string-list = "(" [WSP] #(string) [WSP] ")" test = [WSP] any-of / all-of / exists / false / header / not / size / extension-test [WSP] UNIT = "K" / "M" / "G" ;; kilobytes, megabytes, or gigabytes user-message = "message" [WSP] newline "." newline ;; note when used, ;; a CR that is not followed by an LF becomes a CRLF; ;; an LF that is not followed by a CR becomes a CRLF. ;; a leading .. on a line is mapped to . WSP = " " / CR / LF / tab ;; just whitespace 10. Security Considerations Users must get their mail. It is impera- tive that whatever method implementations use to store the user- defined filtering scripts be reasonably secure. It is equally important that implementations sanity-check the user's Showalter [Page 18] draft-showalter-sieve-00.txt SIEVE April 1997 scripts, and not allow users to create on-demand mailbombs. For instance, an implementation that allows a user to bounce, forward, or reply multiple times to a single message might also allow a user to create a mailbomb triggered by mail from a specific user. 11. Author's Address Tim Showalter Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 E-Mail: tjs@andrew.cmu.edu Appendix A. References [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", Internet Mail Consortium, Work in Progress. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [IMAP] Crispin, M., "Internet Mail Access Protocol - version 4rev1", RFC 2060, University of Washington, December 1996. [IMAIL] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982. [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [UTF-8] Yergeau, F. "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, Alis Technologies, October 1996. Showalter [Page 19]