wdiff draft-martin-sieve-notify-00.txt draft-martin-sieve-notify-01.txt

Network Working Group Tim Martin
Document: draft-martin-sieve-notify-00.txt Mirapoint Inc. draft-martin-sieve-notify-01.txt Wolfgang Segmuller
Expires December 6, 2001 1 June 9, 2001 4 December 2000

Sieve -- An extension for providing instant notifications

<draft-martin-sieve-notify-00.txt>

<draft-ietf-sieve-notify-01.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited.

Abstract

Users go to great lengths to be notified as quickly as possible that
they have received new mail. Most of these methods involve polling
to check for new messages periodically. A push method handled by the
final delivery agent would give gives users quicker notifications and save saves
server resources. This document does not specify the notification
method but is expected that using existing instant messaging
infrastructure such as Zephyr, ICQ, or SMS messages will be popular.
This draft describes an extension to the Sieve mail filtering
language that allows users to give specific preferences for
notification of Sieve actions.

TTaabbllee ooff CCoonntteennttss

Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Capability Identifier . . . . . .
1.1. Conventions Used in This Document . . . . . . . . . . . . . . 3

3. Actions . . . .

2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3

3. Actions . . . 3
3.1. Notify action . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Denotify
3.1. Notify action . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Default action . 3
3.2. Denotify Action . . . . . . . . . . . . . . . . . . . . . . . 5

4. Interaction with Other Sieve Actions . . . . . . . . . . . . 5 6

5. Interaction with Other Sieve Actions . . . . . . . . . . . . 5

6. Security Considerations . . . . . . . . . . . . . . . . . . . 6

7. 7

6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6

8. 7

7. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 6

9. 7

8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6

10. 8

9. Author's Address Addresses . . . . . . . . . . . . . . . . . . . . . . 7 8
1. Introduction

This is an extension to the Sieve language defined by [SIEVE] for
providing instant notifications of sieve actions that have been
preformed. It defines the new action "notify".

This document does not dictate the notification method used.
Examples of possible notification methods are Zephyr and ICQ. The
method shall be site-defined.

Sieve interpreters for which notifications are impractical or is not
possible SHOULD ignore this extension.

Conventions for notations are as in [SIEVE] section 1.1, including
use of [KEYWORDS].

1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].

2. Capability Identifier

The capability string associated with the extension defined in this
document is "notify".

3. Actions

3.1. Notify action

Syntax: notify <priority> <message> [<list of headers to include>] [":method" string]
[":id" string]
[":options" 1*(string-list / number)]
[<":low" / ":normal" / ":high">]
["message:" string]

The Notify action specifies that a notification should be sent to
the user upon successful handling of this message.

The format of the notification is site-defined. implementation-defined. However,
all
content, content specified in the notify action, including Sieve actions
taken on the message, specified in
the notify action MUST SHOULD be included. If errors occurred in
another action they SHOULD be reported in the notification. In
addition, if the notification method does not provide a timestamp,
one SHOULD be appended to the notification. Implementations SHOULD
NOT include extraneous information.

The "priority" :method tag identifies the notification method that will be
used. If the :method tag is not specified, the default
implementation defined notification method MUST be used. The
possible values of this will be site-specific. If a method is
specified that the implementation does not support, the notification
MUST be ignored. An implementation treats this as a warning
condition and execution of the sieve script MUST continue.

The :id tag can be used to give the notify action an unique
identifier. This identifier can be used later in the script to
cancel the specific notify. The string may have any value and SHOULD
NOT be included in the notification.

The :options tag is used to send parameters to the notification
method. This might be the phone number for an SMS message or a
user's ICQ identifier.

The priority parameter specifies the importance of the notification.
The priority parameter shall range from :high has the following values: ":high" (very
important) to :medium (moderately important) to :low
important), ":normal", and ":low" (not very important). If no
priority is giving it shall given, a default to "medium". priority of ":normal" SHOULD be
assumed. Some instant notification methods allow users to specify their
state of activity (for example "busy" or "away from keyboard"). If
the notification method provides this information it SHOULD be used
to selectively send notifications. If If, for example example, the user marks
herself as "busy" "busy", an implentation implementation SHOULD NOT send a notification
for a new mailing list message with a priority of :low, however a the
user should be notified of a high priority action. If the
notification method allows users to filter messages based upon
certain parameters in the message, users should be able to filter
based upon priority.

The "message" If the notification method does not support
priority, then this parameter MUST be ignored.

The :message tag specifies the message data to be included in the
notification. The entirety of the string SHOULD be sent but
implementations MAY shorten the message for technical or aesthetic
reasons.

The list of headers specifies which headers Message may include the user wishes to be
notified of. The header and its contents MUST both be displayed. message variables defined below. If
this
the message parameter is omitted, the "From", "To", and "Subject" headers
shall absent, a default message of "$from$:
$subject$" will be displayed by default. used.

$from$ - the display name or address of the RFC 822 from
$env-from$ - the address of the RFC 821 from

$subject$ - the subject of the message

$text$ - the first text/* part

$text[n]$ - the first n bytes of the first text/* part

If there are errors sending the notification, the Sieve interpreter
SHOULD ignore the notification and not retry indefinitely.

At maximum, one notification is sent per message. If a message
yields multiple notify actions in the processing of a script, the
notify

This action with the highest priority MUST be used. If there are
multiple notify actions with the same priority NOT cancel the last one with
that priority shall be used. implicit keep.

Example:
require ["notify","fileinto"];

if header :contains "from" "brian_bitono@foo.org" "boss@example.org" {
notify :high "This is probably very important";
}

if header :contains "to" "mailinglist@cmu.edu" "sievemailinglist@example.org" {
notify :low "" "" ["From", "Subject"]; "[SIEVE] $from$: $subject$";
fileinto "INBOX.mailing-list"; "INBOX.sieve";
}

3.2. Denotify action Action

Syntax: denotify [MATCH-TYPE string] [<":low" / ":normal" /
":high">]

The denotify action specifies can be used to cancel a previous notification.
If the priority, ":low" / ":normal" / ":high", is specified, then
only cancel those notifications with the specified priority. If a
MATCH-TYPE with a string is specified, then only those notifications
whose :id tag matches the specified string using the match-type
operator are canceled. The ascii-casemap comparator MUST be used.

If no notifications exist that match the current notification, if any,
shall search criteria, then the
denotify has no effect. A denotify only cancels notifications that
have already been requested. It is not be sent. possible to preemptively
cancel a notification.

The sequence:

denotify;
notify;

will still generate a notification. The denotify does not cancel
the notify.

The following table shows which notifies would get cancelled:

# what is cancelled
denotify # all notifications
denotify :matches "*" # all notifications with :id tag
denotify :high # all high priority notifications
denotify :is "foobar" # all notifications with id "foobar"
denotify :matches "foo*" :normal # all normal priority notifications
# with id that starts with "foo"

Example:
require "notify";

notify "" "New mail"; :method "sms" :options "408-555-1212" :id "foobar";
if header :contains "from" "mymom@baz.org" "boss@example.org" {
denotify;
fileinto "INBOX.junk";
}

3.3. Default action

If neither the
notify or :method "sms" :options "408-555-1212" :id "foobar" :high
:message "BOSS: $subject$";
}

if header :contains "to" "sievemailinglist@example.org" {
denotify action is encountered by default a
notifications SHOULD be sent. This :is "foobar";
}

if header :contains "subject" "FYI:" {
# don't need high priority notification shall be equivalent
to a notify action with for
# a priority of medium and the default headers
specified. The message shall be site defined. 'for your information'
denotify :is "foobar" :high;
}

4. Interaction with Other Sieve Actions

Notifications MUST be sent no matter what the message actions might
be. in all cases, unless a reject action is
also executed. Users may wish to know when messages are be notified of a message being discarded or
rejected.

5. Interaction with Other Sieve Actions
discarded, for example. The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [ABNF]. This uses reject action is given an exception
because implementations may wish to restrict users from seeing the ABNF core
rules as specified in Appendix A
contents of a rejected message. However, notifications MAY be
modified to not include any data from the ABNF specification [ABNF].

capability =/ original rejected message.

The notify action =/ notify / MUST NOT cancel the implicit keep.

The denotify

priority = :low / :medium / :high / action MUST NOT affect any actions other than the
notify = "notify" WSP priority WSP string WSP string-list
;; <priority> <message> <headers-list>

denotify = "denotify"

6. action.

Failures of other actions MAY be reported in the notification.

5. Security Considerations

Security considerations are discussed in [SIEVE]. Additionally
implementations must be careful to follow the security
considerations of the specific notification methods. It is believed
that this extension does not introduce any additional security
concerns.

The notify action is potentially very dangerous. The path the
notification takes through the network may not be secure. An error
in the options string may cause the message to be transmitted to
someone it was not intended for.

Just because a notification is received doesn't mean it was sent by
the sieve implementation. It might be possible to forge
notifications with some notification methods.

6. Acknowledgments

Thanks to Larry Greenfield and Greenfield, Sarah Robeson Robeson, Tim Showalter, and Barry
Leiba for help with this document.

7. Copyright

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

8. References
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].

[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
November 1997.

[SIEVE]

[SIEVE]; Showalter, T, "Sieve -- a T.; "Sieve: A Mail Filtering Language", draft-
showalter-sieve-09.txt, Language"; RFC
3028; Mirapoint, September 1999.

10. Inc.; January 2001

9. Author's Address Addresses

Tim Martin
Mirapoint Inc.
909 Hermosa Court
Sunnyvale, CA 94085

Phone: (408) 720-3835
EMail: tmartin@mirapoint.com

Wolfgang Segmuller
IBM T.J. Watson Research Center
30 Saw Mill River Rd
Hawthorne, NY 10532

Phone: (914) 784-7408
Email: whs@watson.ibm.com