draft-freed-sieve-notary-03.txt   draft-freed-sieve-notary-04.txt 
Network Working Group N. Freed Network Working Group N. Freed
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Expires: July 19, 2009 January 15, 2009 Expires: July 19, 2009 January 15, 2009
Sieve Email Filtering: Delivery Status Notifications Extension Sieve Email Filtering: Delivery Status Notifications Extension
draft-freed-sieve-notary-03 draft-freed-sieve-notary-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
All of these tests fail unconditionally if the specified envelope All of these tests fail unconditionally if the specified envelope
parameter does not exist for the current message or recipient. parameter does not exist for the current message or recipient.
The envelope test's ADDRESS-PART argument assumes the string being The envelope test's ADDRESS-PART argument assumes the string being
tested has the syntax of an email address. None of the new envelope tested has the syntax of an email address. None of the new envelope
parts defined here have address syntax, accordingly, it is an error parts defined here have address syntax, accordingly, it is an error
to specify an ADDRESS-PART argument in conjunction with these new to specify an ADDRESS-PART argument in conjunction with these new
envelope parts. envelope parts.
The "relational" extension [RFC5231] adds a match type called The "relational" extension [RFC5231] adds a match type called
":count". The count of an envelope test of with an envelope-part of ":count". The count of an envelope test with an envelope-part of
"orcpt", "ret", and "envid" is 1 if the corresponding SMTP parameter "orcpt", "ret", and "envid" is 1 if the corresponding SMTP parameter
is present and 0 otherwise. The count of an envelope test with an is present and 0 otherwise. The count of an envelope test with an
envelope-part of "notify" is equal to the number of notification envelope-part of "notify" is equal to the number of notification
conditions specified and 0 if the NOTIFY parameter is not present. conditions specified and 0 if the NOTIFY parameter is not present.
4.1. Examples 4.1. Examples
The fact that the notify envelope-part operates on a list of values The fact that the NOTIFY envelope parameter is multivalued and the
makes it easy to check to see if a given value is present without notify envelope-part turns this into list of values makes it easy to
having to worry about other values: check to see if a given value is present without having to worry
about other values:
require ["envelope", "envelope-dsn"]; require ["envelope", "envelope-dsn"];
# Check whether SUCCESS notifications were requested, # Check whether SUCCESS notifications were requested,
# irrespective of any other requests that were made # irrespective of any other requests that were made
if envelope "notify" "SUCCESS" if envelope "notify" "SUCCESS"
{ {
# do whatever # do whatever
} }
Checking to see if a given request is the only one present is a Checking to see if a given request is the only one present is a
little trickier, however: little trickier, however:
require ["envelope", "envelope-dsn", "relational", require ["envelope", "envelope-dsn", "relational",
"comparator-i;ascii-numeric"]; "comparator-i;ascii-numeric"];
# Check whether only FAILURE notifications were requested # Check whether only FAILURE notifications were requested
if allof ( envelope "notify" "FAILURE", if allof ( envelope "notify" "FAILURE",
envelope :comparator "i;ascii-numeric" envelope :comparator "i;ascii-numeric"
:count "eq" "notify" "1" :count "eq" "notify" "1"
skipping to change at page 5, line 18 skipping to change at page 5, line 19
# Check whether only FAILURE notifications were requested # Check whether only FAILURE notifications were requested
if allof ( envelope "notify" "FAILURE", if allof ( envelope "notify" "FAILURE",
envelope :comparator "i;ascii-numeric" envelope :comparator "i;ascii-numeric"
:count "eq" "notify" "1" :count "eq" "notify" "1"
) )
{ {
# do whatever # do whatever
} }
The orcpt envelope-part contains an address type indicator in The orcpt envelope-part always contains an address type indicator
addition to an address, which must be taken into account: prefix in addition to an address, which must be taken into account in
any tests:
require ["envelope", "envelope-dsn"]; require ["envelope", "envelope-dsn"];
# See if the orcpt is an RFC822 address in the example.com # See if the orcpt is an RFC822 address in the example.com
# domain # domain
if envelope :matches "orcpt" "rfc822;*@example.com" if envelope :matches "orcpt" "rfc822;*@example.com"
{ {
# do whatever # do whatever
} }
5. redirect-dsn extension 5. redirect-dsn extension
The "redirect-dsn" extension does not define any new tests or The "redirect-dsn" extension does not define any new tests or
actions, rather, it adds two new arguments, NOTIFY and RET, to the actions, rather, it adds two new arguments, NOTIFY and RET, to the
redirect action defined in Section 4.2 of [RFC5228]. This updates redirect action defined in Section 4.2 of [RFC5228]. This updates
the usage description for redirect to: the usage description for redirect to:
[
Usage: redirect [NOTIFY] [RET] <address: string> Usage: redirect [:notify "value"] [:ret "FULL"|"HDRS"]
<address: string>
The syntax for the NOTIFY and RET arguments are: The syntax for the NOTIFY and RET arguments are:
NOTIFY = ":notify" notify-value NOTIFY = ":notify" notify-value
notify-value = DQUOTE notify-esmtp-value DQUOTE notify-value = DQUOTE notify-esmtp-value DQUOTE
RET = ":ret" ret-value RET = ":ret" ret-value
ret-value = DQUOTE ("FULL" / "HDRS") DQUOTE ret-value = DQUOTE ("FULL" / "HDRS") DQUOTE
The notify-esmtp-value production is defined in Section 4.1 of The notify-esmtp-value production is defined in Section 4.1 of
[RFC3461]. [RFC3461].
When these arguments are specified, they set the corresponding NOTIFY When these arguments are specified, they set the corresponding NOTIFY
ESMTP RCPT TO and RET ESMTP MAIL FROM parameters, respectively. ESMTP RCPT TO and RET ESMTP MAIL FROM parameters, respectively.
These parameters are only available when the delivery status These parameters are only available when the delivery status
notification (DSN) ESMTP extension is available; they are simply notification (DSN) ESMTP extension is available. When the DSN
ignored and MUST NOT cause an error if the DSN extension is extension is not available, the parameters MUST be ignored and MUST
unavailable. NOT cause an error.
5.1. Example 5.1. Example
One possible use of :notify on redirect is to ccmbine the copy One possible use of :notify on redirect is to combine the copy
extension [RFC3894] with the ability to suppress nondelivery extension [RFC3894] with the ability to suppress nondelivery
notifications to generate a private copy of selected messages with no notifications to generate a private copy of selected messages with no
side effects or error notifications: side effects or error notifications:
require ["copy", "redirect-dsn"]; require ["copy", "redirect-dsn"];
# Make a private copy of messages from user@example.com # Make a private copy of messages from user@example.com
if address "from" "user@example.com" if address "from" "user@example.com"
{ {
redirect :copy :notify "NEVER" "elsewhere@example.com"; redirect :copy :notify "NEVER" "elsewhere@example.com";
skipping to change at page 8, line 16 skipping to change at page 8, line 16
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC3894] Degener, J., "Sieve Extension: Copying Without Side [RFC3894] Degener, J., "Sieve Extension: Copying Without Side
Effects", RFC 3894, October 2004. Effects", RFC 3894, October 2004.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Cyrus Daboo, Derek Diget, Philip Guenther, Arnt Gulbrandsen, Alexey Cyrus Daboo, Derek Diget, Philip Guenther, Arnt Gulbrandsen, Alexey
Melnikov, and Alexandros Vellis provided helpful suggestions and Melnikov, Aaron Stone, and Alexandros Vellis provided helpful
corrections. suggestions and corrections.
Author's Address Author's Address
Ned Freed Ned Freed
Sun Microsystems Sun Microsystems
800 Royal Oaks 800 Royal Oaks
Monrovia, CA 91016-6347 Monrovia, CA 91016-6347
USA USA
Phone: +1 909 457 4293 Phone: +1 909 457 4293
 End of changes. 9 change blocks. 
16 lines changed or deleted 18 lines changed or added

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