This is a draft for the filtering language. I managed to fill in a few
examples, but there are still a lot of consistancy errors that arose from
making a lot of changes in the grammar. I'm posting it anyway because I
believe it'll be better to actually let people see it.
If you find obvious errors, let me know. I'm SURE there are places that are
not internally consistant. I'll work on it more tomorrow.
Thanks ...
--
Tim Showalter
tjs(_at_)andrew(_dot_)cmu(_dot_)edu
Network Working Group T. Showalter
Internet Draft Carnegie Mellon
Document: draft-showalter-sieve-XX.txt March 1997
Expire sometime after it's released
SIEVE: A Mail Filtering Language
Status of this Memo
This draft has no standing and is for limited distribution. Please
do not implement anything within without contacting the author, and
even then, use extreme caution; everything in this draft is carved in
warm butter.
The following is here for when we actually publish this:
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 deliver. 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 architechture, 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 lists), and
Showalter [Page 1]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
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.
Showalter [Page 2]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
Table of Contents
This document is content-free.
Showalter [Page 3]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
0. Known Weaknesses
The following weaknesses will be addressed, probably by extensions to
be issued with this draft.
Several people want regular expressions. It is my feeling that
mostly only advanced users (mostly UNIX types) want regular
expression support instead of globs. I really want this in my
filtering language, and will code it. However, regexp support is
gross and frequently creatively incompatible, so I have removed it
from this draft. I will write up an extension if I can find a
reasonable way of documenting regular expressions (will probably
borrow something from POSIX).
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 architechture that dumps envelopes,
or stores them in weird ways.
"Detailed" addressing is not handled, and will likely be moved to an
extension as it is not supported by all systems. Detailed addressing
is where, in address like tjs+fmh(_at_)andrew(_dot_)cmu(_dot_)edu, the
delivery system
ignores the "+fmh" in the address, but leaves it to the filtering
system to interpret. A "detail" command will be added to match this;
it can be handled in the draft as-is with suitable pattern matching
on the to/cc field, but it requires env-to matching to get it really
right. This is a common practice on CMU's mail system, and the Cyrus
IMAPD offers some support of it as it is, and it's a must for us.
I had a section on a "support" test, but removed it. The idea of
support is that if a given extension is supported, the test is true,
and you can call on the extension. It is a neat idea, but introduces
mystery grammatical constructs that cannot be reasonably resolved. A
"require" keyword is still useful, and has been added.
Whitespace is for readability, and as such, should be reasonably easy
to edit. (Whitespace in computer-generated scripts will probably be
single spaces and occasional newlines.) But thanks to creative
obscufation from modern operating systems in their definitions of
ASCII, there is no platform-independant newline in a text editor,
which will be useful for users editing source. Proposed solution:
since we generally don't care what the newline character is anyway,
allow any newline character (or, in the case of real ASCII, the CRLF
sequence) to be whitespace. This has been the decision used in this
document regarding whitespace.
Commands can optionally end with a ";", and tests can optionally end
with a ",". This is a feature intended to allow for humans to mark
Showalter [Page 4]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
ends of commands, as I expect missing arguments for some commands
will be a frequent source of error. They are unnecessary and would
be easily removed, but I'm partial to them. Comments would be
appreciated.
I'm not sure if I have most of the technichal terms right. I suspect
they're IMAP-biased, and need to reflect mail more generally. Any
comments would be appreciated.
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 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 architechture. It
requires the use of [RFC822]-complant messages and support of
multiple folders, but should work with a wide variety of systems.
The language is powerful enough to be useful, but delibrately very
limited in order to allow for a reasonably secure server-side
filtering system. The language is not Turing-complete, and provides
no way to write a loop or a function. 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 seperate
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 availible 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.
Showalter [Page 5]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
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.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and
"MAY" in this document are to be interpreted as defined in [XXX].
1.2. Example mail messages
The following mail messages will be used throughout this document in
examples.
Message A
-----------------------------------------------------------
Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
From: coyote(_at_)anvil(_dot_)dementia(_dot_)org
To: roadrunner(_at_)birdseed(_dot_)thekeep(_dot_)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!(_at_)reply-by-postal-mail
Sender: b1ff(_at_)znic(_dot_)net
To: rube(_at_)znic(_dot_)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!!! JUST
SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
-----------------------------------------------------------
Showalter [Page 6]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
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
control structure is taken.
2.2. Whitespace
Whitespace seperates commands. The amount of whitespace used in
seperating commands is not important. Whitespace includes tabs,
newlines, and the space character.
2.3. Comments
Comments begin with a "#" character that is not containted within a
string and continue until the next newline.
2.4. Numbers
Numbers are normally given in the form of decimal numbers. However,
those numbers that have a tendancy 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 base-two-based versions of SI units that
computers frequently use, K specifies kilo, or 1,024 times the value
of the number; M specifies mega, or 1,048,576 times the value of the
number; and G specifies giga, or1,073,741,824 times the value of the
number.
2.5. Strings
Scripts involve large numbers of strings. Typically, short quoted
strings suffice for most uses, but a more conveinent form is provided
for longer strings.
A quoted string starts and ends with a single double quote (the ").
A backslash (" backslash or a double quote. This two-character
sequence represents a single backslash or double-quote within the
string.
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 considered to begin with ".".
Showalter [Page 7]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
Example: if any-of (header ("from") contains
("bart" "homer" "smithers" "burns" "lisa")
header ("subject") contains ("URGENT")) then fileinto
"INBOX" else reply message 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.
[ ONE SINGLE DOT, which I can't get nroff to produce ...
]
endif
2.6. Addresses
A number of commands call for email addresses. These addresses must
be compliant with [RFC822]. 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 produce any actions, as in the
following script with message A above:
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" on many
implementations).
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) MAY do so.
3. Conditionals and Control Structures
Showalter [Page 8]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
In order for a script to do more than one set of actions, control
structures are needed.
3.1. If
Syntax: if <test> then <commands>
[elsif <elsif-test> then <elsif-commands> [elsif ...]]
[else <else-commands>]
endif
The "if" control structure is borrowed from any number of programming
languages. It is evaluated in the usual way, as follows: if <test>
is true, then <commands> are evaluated. If an elsif keyword exists,
and <next-test> is true, then <elsif-commands> are evaluated. Any
number of elsif cases may be included, and are evaluated serially.
If <test> is false and the <elsif-test>s are false as well, then the
<else-commands> 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, sends mail to
acm(_at_)andrew(_dot_)cmu(_dot_)edu; message B, to
service(_at_)andrew(_dot_)cmu(_dot_)edu; and message
C, to postman(_at_)andrew(_dot_)cmu(_dot_)edu(_dot_)
Example: XXX
XXX
3.2. Require
Syntax: require <extension-name>
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
Showalter [Page 9]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
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.
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, resend, 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(_at_)anvil(_dot_)dementia(_dot_)org")
then bounce endif
4.2. Action fileinto
Syntax: fileinto <folder>
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 <address>
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:
Showalter [Page 10]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
Example: forward "tjs(_at_)andrew(_dot_)cmu(_dot_)edu"
4.4. Action normal
Syntax: normal
The "normal" action is whatever action is taken in leiu 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 explicitally, providing a way to use it
independant of system.
Syntax: if size under 1MB then normal else toss
4.5. Action reply
Syntax: reply <message>
The "reply" action is used to generate a form letter reply to the
original sender. Message is XXXXXXXXX
Example: if size over 500K reply message
Your message was unnecessarily large.
I reject all large messages; you will need to contact me
directly.
else normal endif
OPEN: Specify headers transmitted? Specify number of days before
considered valid/invalid?
4.6. Action resend
Syntax: resend <address>
The "resend" action resends a message to the supplied address, adding
the appropriate Resent-From: and Resent-To: headers. Other than a
few added headers, the "resend" function is expected to make no
changes to the message body or headers, leaving the message mostly
untouched.
Example
if subject "cyrus" then resend
"cyrus-bugs(_at_)andrew(_dot_)cmu(_dot_)edu" endif
4.7. Action stop The "stop" action ends all processing. If no actions
have been executed, then the normal action is taken.
Example: if (header "from" matches
"wall*(_at_)andrew(_dot_)cmu(_dot_)edu")
then forward "tjs(_at_)xanadu(_dot_)wv(_dot_)us"; endif stop
endif reply "I'm on vacation and not taking any messages;
Showalter [Page 11]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
try again in a week."
4.8. Action toss Toss drops the message.
Example: if header "from" contains "wall(_at_)andrew(_dot_)cmu(_dot_)edu"
then toss
endif
5. Tests
Tests are used in conditionals to decide which part(s) of the condi-
tional to execute.
5.X. all-of
Syntax: all-of ( <test> [,] <test> [,] ... <test> )
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.X. any-of
Syntax: all-of ( <test> [,] <test> [,] ... <test> )
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. . false
Syntax: false
5.X. header
Syntax: header <header-name-list>
<"contains"/"is"/"matches"/"contains-nocase" / "is-
Showalter [Page 12]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
nocase"/"matches-nocase"> <key-list>
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 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 heard-
ers 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
"" matches all strings that exist.
5.B. not
Syntax:
not <test>
The "not" test takes some other test, and returns the opposite
result.
5.Q. size
Syntax:
size <"over" / "under"> <limit [quantifier]>
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
Showalter [Page 13]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
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.X. true
Syntax:
true
The "true" test is always true.
5.X. valid
Syntax:
valid
The "valid" test is true if the message satisfies the basic criteria
for an [RFC822] compliant message. At a minimum, the message must
have valid a valid "To" header, a valid "From" or "Sender" header,
where the field in the address contains an email address of the form
"user(_at_)host", and host is a valid domain record.
The intention of the "valid" test is to drop messages that do not fit
the basic requirements of an [RFC822] compliant message, but made it
to final delivery none the less.
[I'm not sure exactly what requirements should be imposed, but this
one might be very useful for weeding out joke messages from
president(_at_)whitehouse(_dot_)gov that happen whenever the freshman class
fig-
ures out how to forge mail, or spams that don't bother having valid
return addresses.]
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 try to make
forward process.
Showalter [Page 14]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
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 preferrable alterna-
tive cannot be found
Implentations 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 oversending error messages to the user's mailbox.
Implementations that allow client-based filtering (i.e., use this
language to implement filtering from a POP server into local mail
folders) must notify the user of syntax errors, and should allow the
user to file mail into their main mailbox on request. If mail is
processed without user intervention (as part of a background test,
with long periods of time in between user intervention) the implenta-
tion MUST file mail into the main mailbox.
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" condi-
tional, which mandates that script requires the use of that exten-
sion. Additionally, in a situation where there is a submission pro-
tocol and an extsension advertisement mechanism, so that scripts sub-
mitted can be checked against the mail server for valid extensions.
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
Showalter [Page 15]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
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, 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.
9. Acknowledgements
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, and not a single comma.
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 / resend /
stop / extension-action
address ::= string
;; any legal RFC822 address
any-of ::= "any-of" WSP "(" [WSP] condition *([","] condition) [WSP] ")"
all-of ::= "all-of" WSP "(" [WSP] condition *([","] condition) [WSP] ")"
big-number ::= number [ UNIT ]
bounce ::= "bounce"
control-structure ::= if / extension-control-structure
command ::= action [WSP] [";"] / control-structure
commands ::= #(command)
comment ::= "#" *CHAR CRLF
CHAR ::= <any ASCII/UTF-8 character>
Showalter [Page 16]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
CR ::= <ASCII CR, carriage return, 0x0D>
CRLF ::= CR LF
DIGIT ::= "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
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 <cond> then <commands>
;; [elsif <cond> then <commands> [elsif ...]]
;; [else <commands>] endif
include ::= "include" WSP url
header ::=
LF ::= <ASCII LF, line feed, 0x0A>
newline ::= CR[LF] / LF
;; A CRLF is ALWAYS one newline.
;; XXX there's a better way to specify this!
number ::= 1*DIGIT
or ::= condition WSP "or" WSP condition
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 .
resend ::= "resend" WSP string
size ::= "size" WSP ( "over" / "under" ) WSP big-number
stop ::= "stop"
string ::= ( "
;;
;; \ inside a string maps to
string-list ::= "(" [WSP] *string [WSP] ")"
Showalter [Page 17]
draft-showalter-sieve-XX.txt SIEVE 20 Mar 1997
test ::= [WSP] any-of / all-of / false / header / not /
size / extension-test [WSP]
UNIT ::= "K" / "M" / "G"
;; kilobytes, megabytes, or gigabytes; the B is optional
url ::= string
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
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(_at_)andrew(_dot_)cmu(_dot_)edu
Appendix A. References
[ABNF]
[ACAP]
[IMAP]
[RFC822]
[XXX]
Showalter [Page 18]