영어 번역좀 부탁드립니다
-
게시물 수정 , 삭제는 로그인 필요
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.
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 (""). Optional arguments
are listed inside square brackets ("[" and "]"). Each argument is
followed by its type, so "" 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.
영어고수님들 영어번역좀 부탁드립니다~
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.
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 (""). Optional arguments
are listed inside square brackets ("[" and "]"). Each argument is
followed by its type, so "
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.
영어고수님들 영어번역좀 부탁드립니다~
