draft-ietf-sieve-3028bis-10.txt   draft-ietf-sieve-3028bis-11.txt 
Network Working Group P. Guenther Network Working Group P. Guenther
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Intended status: Standards Track T. Showalter Intended status: Standards Track T. Showalter
Expires: August 2007 Editors Expires: August 2007 Editors
Obsoletes: 3028 (if approved) February 2007 Obsoletes: 3028 (if approved) February 2007
Sieve: An Email Filtering Language Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-10.txt draft-ietf-sieve-3028bis-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 9, line 40 skipping to change at page 9, line 40
A number of commands call for email addresses, which are also a A number of commands call for email addresses, which are also a
subset of strings. When these addresses are used in outbound subset of strings. When these addresses are used in outbound
contexts, addresses must be compliant with [IMAIL], but are further contexts, addresses must be compliant with [IMAIL], but are further
constrained within this document. Using the symbols defined in constrained within this document. Using the symbols defined in
[IMAIL], section 3, the syntax of an address is: [IMAIL], section 3, the syntax of an address is:
sieve-address = addr-spec ; simple address sieve-address = addr-spec ; simple address
/ phrase "<" addr-spec ">" ; name & addr-spec / phrase "<" addr-spec ">" ; name & addr-spec
That is, routes and group syntax are not permitted. If multiple That is, routes and group syntax are not permitted. If multiple
addresses are required, use a string list. Named groups are not used addresses are required, use a string list. Named groups are not
here. permitted.
Implementations MUST ensure that the addresses are syntactically It is an error for a script to execute an action with a value for use
valid, but need not ensure that they actually identify an email as an outbound address that doesn't match the "sieve-address" syntax.
recipient.
2.4.2.4. Encoding characters using "encoded-character" 2.4.2.4. Encoding characters using "encoded-character"
When the "encoded-character" extension is in effect, certain When the "encoded-character" extension is in effect, certain
character sequences in strings are replaced by their decoded value. character sequences in strings are replaced by their decoded value.
This happens after escape sequences are interpreted and dot- This happens after escape sequences are interpreted and dot-
unstuffing has been done. Implementations SHOULD support "encoded- unstuffing has been done. Implementations SHOULD support "encoded-
character". character".
Arbitrary octets can be embedded in strings by using the syntax Arbitrary octets can be embedded in strings by using the syntax
skipping to change at page 22, line 36 skipping to change at page 22, line 36
The "redirect" action is used to send the message to another user at The "redirect" action is used to send the message to another user at
a supplied address, as a mail forwarding feature does. The a supplied address, as a mail forwarding feature does. The
"redirect" action makes no changes to the message body or existing "redirect" action makes no changes to the message body or existing
headers, but it may add new headers. In particular, existing headers, but it may add new headers. In particular, existing
Received headers MUST be preserved and the count of Received headers Received headers MUST be preserved and the count of Received headers
in the outgoing message MUST be larger than the same count on the in the outgoing message MUST be larger than the same count on the
message as received by the implementation. (An implementation that message as received by the implementation. (An implementation that
adds a Received header before processing the message does not need to adds a Received header before processing the message does not need to
add another when redirecting.) add another when redirecting.)
The redirect command performs an MTA-style "forward"--that is, what The message is send back out with the address from the redirect
you get from a .forward file using sendmail under UNIX. The address command as an envelope recipient. Implementations MAY combine
on the [SMTP] envelope is replaced with the one on the redirect separate redirects for a given message into a single submission with
command and the message is sent back out. (This is not an MUA-style multiple envelope recipients. (This is not an MUA-style forward,
forward, which creates a new message with a different sender and which creates a new message with a different sender and message ID,
message ID, wrapping the old message in a new one.) wrapping the old message in a new one.)
The envelope sender address on the outgoing message is chosen by the The envelope sender address on the outgoing message is chosen by the
sieve implementation. It MAY be copied from the original message. sieve implementation. It MAY be copied from the message being
processed.
A simple script can be used for redirecting all mail: A simple script can be used for redirecting all mail:
Example: redirect "bart@example.com"; Example: redirect "bart@example.com";
Implementations SHOULD take measures to implement loop control, Implementations SHOULD take measures to implement loop control,
possibly including adding headers to the message or counting Received possibly including adding headers to the message or counting Received
headers. If an implementation detects a loop, it causes an error. headers. If an implementation detects a loop, it causes an error.
4.3. Action keep 4.3. Action keep
skipping to change at page 25, line 34 skipping to change at page 25, line 36
Example: anyof (false, false) => false Example: anyof (false, false) => false
anyof (false, true) => true anyof (false, true) => true
anyof (true, true) => true anyof (true, true) => true
5.4. Test envelope 5.4. Test envelope
Usage: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] Usage: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list> <envelope-part: string-list> <key-list: string-list>
The "envelope" test is true if the specified part of the SMTP (or The "envelope" test is true if the specified part of the [SMTP] (or
equivalent) envelope matches the specified key. This specification equivalent) envelope matches the specified key. This specification
defines the interpretation of the (case insensitive) "from" and "to" defines the interpretation of the (case insensitive) "from" and "to"
envelope-parts. Additional envelope-parts may be defined by other envelope-parts. Additional envelope-parts may be defined by other
extensions; implementations SHOULD consider unknown envelope parts an extensions; implementations SHOULD consider unknown envelope parts an
error. error.
If one of the envelope-part strings is (case insensitive) "from", If one of the envelope-part strings is (case insensitive) "from",
then matching occurs against the FROM address used in the SMTP MAIL then matching occurs against the FROM address used in the SMTP MAIL
command. The null reverse-path is matched against as the empty command. The null reverse-path is matched against as the empty
string, regardless of the ADDRESS-PART argument specified. string, regardless of the ADDRESS-PART argument specified.
skipping to change at page 29, line 24 skipping to change at page 29, line 24
Capability strings beginning with "vnd." represent vendor-defined Capability strings beginning with "vnd." represent vendor-defined
extensions. Such extensions are not defined by Internet standards or extensions. Such extensions are not defined by Internet standards or
RFCs, but are still registered with IANA in order to prevent RFCs, but are still registered with IANA in order to prevent
conflicts. Extensions starting with "vnd." SHOULD be followed by the conflicts. Extensions starting with "vnd." SHOULD be followed by the
name of the vendor and product, such as "vnd.acme.rocket-sled". name of the vendor and product, such as "vnd.acme.rocket-sled".
The following capability strings are defined by this document: The following capability strings are defined by this document:
encoded-character encoded-character
The string "encoded-character" indicates that the The string "encoded-character" indicates that the
implementation supports the interpretation of "${hex:...}" implementation supports the interpretation of
and "${unicode:...}" in strings. "${hex:...}" and "${unicode:...}" in strings.
envelope The string "envelope" indicates that the implementation envelope The string "envelope" indicates that the implementation
supports the "envelope" command. supports the "envelope" command.
fileinto The string "fileinto" indicates that the implementation fileinto The string "fileinto" indicates that the implementation
supports the "fileinto" command. supports the "fileinto" command.
comparator- The string "comparator-elbonia" is provided if the comparator- The string "comparator-elbonia" is provided if the
implementation supports the "elbonia" comparator. implementation supports the "elbonia" comparator.
Therefore, all implementations have at least the Therefore, all implementations have at least the
skipping to change at page 41, line 10 skipping to change at page 41, line 10
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the IETF Funding for the RFC Editor function is currently provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Appendix A. Change History Appendix A. Change History
This section will be removed when this document leaves the Internet- This section will be removed when this document leaves the Internet-
Draft stage. Draft stage.
Changes from draft-ietf-sieve-3028bis-10.txt
1. Clarify how the "redirect" action uses the address argument
2. Eliminate the phrase "original message"
3. If an outbound address doesn't match the syntax, it's an error
Changes from draft-ietf-sieve-3028bis-09.txt Changes from draft-ietf-sieve-3028bis-09.txt
1. [MDN] reference is merely informative 1. [MDN] reference is merely informative
2. Whitespace tweaks in the ABNF 2. Whitespace tweaks in the ABNF
3. Extensions can't change "require" 3. Extensions can't change "require"
4. fileinto a nonexistent mailbox is implementation defined behavior 4. fileinto a nonexistent mailbox is implementation defined behavior
5. Clarify the definition of the size of a message 5. Clarify the definition of the size of a message
6. Make the KEYWORDS boilerplate match expectations 6. Make the KEYWORDS boilerplate match expectations
7. Add the encoded-character extension 7. Add the encoded-character extension
8. Remove duplication in text regarding unknown extensions 8. Remove duplication in text regarding unknown extensions
9. Address security concerns about looping with redirect or other 9. Address security concerns about looping with redirect or other
 End of changes. 8 change blocks. 
16 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/