7
Network Working Group A. Melnikov, Ed.
8
Request for Comments: 5435 Isode Limited
9
Category: Standards Track B. Leiba, Ed.
11
IBM T.J. Watson Research Center
17
Sieve Email Filtering: Extension for Notifications
21
This document specifies an Internet standards track protocol for the
22
Internet community, and requests discussion and suggestions for
23
improvements. Please refer to the current edition of the "Internet
24
Official Protocol Standards" (STD 1) for the standardization state
25
and status of this protocol. Distribution of this memo is unlimited.
29
Copyright (c) 2009 IETF Trust and the persons identified as the
30
document authors. All rights reserved.
32
This document is subject to BCP 78 and the IETF Trust's Legal
33
Provisions Relating to IETF Documents (http://trustee.ietf.org/
34
license-info) in effect on the date of publication of this document.
35
Please review these documents carefully, as they describe your rights
36
and restrictions with respect to this document.
40
Users go to great lengths to be notified as quickly as possible that
41
they have received new mail. Most of these methods involve polling
42
to check for new messages periodically. A push method handled by the
43
final delivery agent gives users quicker notifications and saves
44
server resources. This document does not specify the notification
45
method, but it is expected that using existing instant messaging
46
infrastructure such as Extensible Messaging and Presence Protocol
47
(XMPP), or Global System for Mobile Communications (GSM) Short
48
Message Service (SMS) messages will be popular. This document
49
describes an extension to the Sieve mail filtering language that
50
allows users to give specific rules for how and when notifications
58
Melnikov, et al. Standards Track [Page 1]
60
RFC 5435 Sieve Extension: Notifications January 2009
65
1. Introduction ....................................................3
66
1.1. Conventions Used in This Document ..........................3
67
2. Capability Identifier ...........................................3
68
3. Notify Action ...................................................3
69
3.1. Notify Action Syntax and Semantics .........................3
70
3.2. Notify Parameter "method" ..................................3
71
3.3. Notify Tag ":from" .........................................4
72
3.4. Notify Tag ":importance" ...................................4
73
3.5. Notify Tag ":options" ......................................5
74
3.6. Notify Tag ":message" ......................................5
75
3.7. Examples ...................................................6
76
3.8. Requirements on Notification Methods Specifications ........7
77
4. Test valid_notify_method ........................................8
78
5. Test notify_method_capability ...................................9
79
6. Modifier encodeurl to the 'set' Action .........................10
80
7. Interactions with Other Sieve Actions ..........................11
81
8. Security Considerations ........................................11
82
9. IANA Considerations ............................................13
83
9.1. Registration of Sieve Extension ...........................13
84
9.2. New Registry for Sieve Notification Mechanisms ............14
85
9.3. New Registry for Notification-Capability Parameters .......14
86
10. Acknowledgements ..............................................15
87
11. References ....................................................16
88
11.1. Normative References .....................................16
89
11.2. Informative References ...................................16
114
Melnikov, et al. Standards Track [Page 2]
116
RFC 5435 Sieve Extension: Notifications January 2009
121
This is an extension to the Sieve language defined by [Sieve] for
122
providing instant notifications. It defines the new action "notify".
124
This document does not specify the notification methods. Examples of
125
possible notification methods are email and XMPP. To allow for the
126
portability of scripts that use notifications, implementation of the
127
[MailTo] method is mandatory. Other available methods shall depend
128
upon the implementation and configuration of the system.
130
1.1. Conventions Used in This Document
132
Conventions for notations are as in [Sieve], Section 1.1, including
135
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
137
document are to be interpreted as described in [Kwds].
139
2. Capability Identifier
141
The capability string associated with the extension defined in this
142
document is "enotify".
146
3.1. Notify Action Syntax and Semantics
148
Usage: notify [":from" string]
149
[":importance" <"1" / "2" / "3">]
150
[":options" string-list]
154
The "notify" action specifies that a notification should be sent to a
155
user. The format of the notification is implementation-defined and
156
is also affected by the notification method used (see Section 3.2).
157
However, all content specified in the ":message" parameter SHOULD be
160
3.2. Notify Parameter "method"
162
The "method" positional parameter identifies the notification method
163
that will be used; it is a URI [URI]. For example, the notification
164
method can be a tel URI [TEL-URI] with a phone number to send SMS
165
messages to, or an XMPP [XMPP] URI containing an XMPP identifier
170
Melnikov, et al. Standards Track [Page 3]
172
RFC 5435 Sieve Extension: Notifications January 2009
175
The supported URI values will be site-specific, but support for the
176
[MailTo] method is REQUIRED in order to ensure interoperability. If
177
a URI schema is specified that the implementation does not support,
178
the notification MUST cause an error condition at run time. Sieve
179
scripts can check the supported methods using the valid_notify_method
180
test to be sure that they only use supported ones, to avoid such
183
If the "method" parameter contains a supported URI schema, then the
184
URI MUST be checked for syntactic validity. Invalid URI syntax or an
185
unsupported URI extension MUST cause an error. An implementation MAY
186
enforce other semantic restrictions on URIs -- for example, to
187
restrict phone numbers in a tel: URI to a particular geographical
188
region -- and will treat violations of such semantic restrictions as
191
3.3. Notify Tag ":from"
193
A ":from" tag may be used to specify an author of the notification.
194
The syntax of this parameter's value is method-specific.
195
Implementations SHOULD check the syntax according to the notification
196
method specification and generate an error when a syntactically
197
invalid ":from" tag is specified.
199
In order to minimize/prevent forgery of the author value,
200
implementations SHOULD impose restrictions on what values can be
201
specified in a ":from" tag. For example, an implementation may
202
restrict this value to be a member of a list of known author
203
addresses or to belong to a particular domain. It is suggested that
204
values that don't satisfy such restrictions simply be ignored rather
205
than causing the "notify" action to fail.
207
3.4. Notify Tag ":importance"
209
The ":importance" tag specifies the importance of quick delivery of
210
the notification, as perceived by the Sieve script owner. The
211
":importance" tag is followed by a numeric value represented as a
212
string: "1" (high importance), "2" (normal importance), and "3" (low
213
importance). If no importance is given, the default value "2" SHOULD
214
be assumed. A notification method MAY treat the importance value as
215
a transport indicator. For example, it might deliver notifications
216
of high importance quicker than notifications of normal or low
217
importance. Some notification methods allow users to specify their
218
state of activity (for example, "busy" or "away from keyboard"). If
219
the notification method provides this information, it SHOULD be used
220
to selectively send notifications. If, for example, the user marks
226
Melnikov, et al. Standards Track [Page 4]
228
RFC 5435 Sieve Extension: Notifications January 2009
231
herself as "busy", a notification method can require that a
232
notification with importance of "3" is not to be sent; however, the
233
user might be notified of a notification with higher importance.
235
If the notification method allows users to filter messages based upon
236
certain parameters in the message, users SHOULD be able to filter
237
based upon importance. If the notification method does not support
238
importance, then this parameter MUST be ignored. An implementation
239
MAY include the importance value in the default message, Section 3.6,
240
if one is not provided.
242
3.5. Notify Tag ":options"
244
The ":options" tag is used to send additional parameters to the
245
notification method. Interpretation of the parameters is method-
246
specific. This document doesn't specify any such additional
249
Each string in the options string list has the following syntax:
250
"<optionname>=<value>"
251
where optionname has the following ABNF [ABNF]:
255
l-d-p = l-d / "." / "-" / "_"
256
optionname = l-d *l-d-p
257
value = *(%x01-09 / %x0B-0C / %x0E-FF)
259
3.6. Notify Tag ":message"
261
The ":message" tag specifies the message data to be included in the
262
notification. The entirety of the string SHOULD be sent, but
263
implementations MAY shorten the message for technical or aesthetic
264
reasons. If the ":message" parameter is absent, a default
265
implementation-specific message is used. Unless otherwise specified
266
by a particular notification mechanism, an implementation default
267
containing at least the value of the "From" header field and the
268
value of the "Subject" header field is RECOMMENDED.
270
In order to construct more complex messages, the notify extension can
271
be used together with the Sieve variables extension [Variables], as
272
shown in the examples below.
282
Melnikov, et al. Standards Track [Page 5]
284
RFC 5435 Sieve Extension: Notifications January 2009
290
require ["enotify", "fileinto", "variables"];
292
if header :contains "from" "boss@example.org" {
293
notify :importance "1"
294
:message "This is probably very important"
295
"mailto:alm@example.com";
296
# Don't send any further notifications
300
if header :contains "to" "sievemailinglist@example.org" {
301
# :matches is used to get the value of the Subject header
302
if header :matches "Subject" "*" {
303
set "subject" "${1}";
306
# :matches is used to get the value of the From header
307
if header :matches "From" "*" {
311
notify :importance "3"
312
:message "[SIEVE] ${from}: ${subject}"
313
"mailto:alm@example.com";
314
fileinto "INBOX.sieve";
318
require ["enotify", "fileinto", "variables", "envelope"];
320
if header :matches "from" "*@*.example.org" {
321
# :matches is used to get the MAIL FROM address
322
if envelope :all :matches "from" "*" {
323
set "env_from" " [really: ${1}]";
326
# :matches is used to get the value of the Subject header
327
if header :matches "Subject" "*" {
328
set "subject" "${1}";
331
# :matches is used to get the address from the From header
332
if address :matches :all "from" "*" {
333
set "from_addr" "${1}";
338
Melnikov, et al. Standards Track [Page 6]
340
RFC 5435 Sieve Extension: Notifications January 2009
343
notify :message "${from_addr}${env_from}: ${subject}"
344
"mailto:alm@example.com";
348
require ["enotify", "variables"];
351
"xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
353
if header :contains "subject" "Your dog" {
354
set "notif_method" "tel:+14085551212";
357
if header :contains "to" "sievemailinglist@example.org" {
358
set "notif_method" "";
361
if not string :is "${notif_method}" "" {
362
notify "${notif_method}";
365
if header :contains "from" "boss@example.org" {
366
# :matches is used to get the value of the Subject header
367
if header :matches "Subject" "*" {
368
set "subject" "${1}";
371
# don't need high importance notification for
372
# a 'for your information'
373
if not header :contains "subject" "FYI:" {
374
notify :importance "1" :message "BOSS: ${subject}"
379
3.8. Requirements on Notification Methods Specifications
381
This section describes requirements for documents that define
382
specific Sieve notification methods.
384
Notification mechanisms MUST NOT add new Sieve tags to the "notify"
387
A notification method MAY allow modification of the final
388
notification text -- for example, truncating it if it exceeds a
389
length limit or modifying characters that can not be represented in
390
the target character set. Characters in the notification text that
394
Melnikov, et al. Standards Track [Page 7]
396
RFC 5435 Sieve Extension: Notifications January 2009
399
can't be represented by the notification method SHOULD be replaced
400
with a symbol indicating an unknown character. Allowed modifications
401
MUST be documented in the document describing the notification
404
A notification method MAY ignore parameters specified in the "notify"
407
A notification method MAY recommend the default message value to be
408
used if the ":message" argument is not specified.
410
Notifications SHOULD include timestamps, if the notification method
411
allows for their transmission outside of the textual message.
412
Implementation methods that can only transmit timestamps in the
413
textual message MAY include them in the textual message.
415
A notification MUST include means to identify/track its origin in
416
order to allow a recipient to stop notifications or find out how to
417
contact the sender. This requirement is to help with tracking a
418
misconfigured or abusive origin of notifications.
420
Methods SHOULD NOT include any other extraneous information not
421
specified in parameters to the "notify" action.
423
Methods MUST specify which URI parameters (if any) must be ignored,
424
which ones must be used in the resulting notification, and which ones
427
Methods MUST specify what values are returned by the
428
notify_method_capability test, Section 5, in particular for the
429
"online" notification-capability.
431
If there are errors sending the notification, the Sieve interpreter
432
SHOULD ignore the notification and not retry indefinitely. The Sieve
433
interpreter MAY throttle notifications; if it does, a request to send
434
a notification MAY be silently ignored. Documents describing
435
notification methods SHOULD describe how retries, throttling,
436
duplicate suppression (if any), etc. are to be handled by
439
4. Test valid_notify_method
441
Usage: valid_notify_method <notification-uris: string-list>
443
The valid_notify_method test is true if the notification methods
444
listed in the notification-uris argument are supported and they are
445
valid both syntactically (including URI parameters) and semantically
450
Melnikov, et al. Standards Track [Page 8]
452
RFC 5435 Sieve Extension: Notifications January 2009
455
(including implementation-specific semantic restrictions). This test
456
MUST perform exactly the same validation as would be performed on the
457
"method" parameter to the "notify" action.
459
The test is true only if ALL of the listed notification methods are
463
if not valid_notify_method ["mailto:",
464
"http://gw.example.net/notify?test"] {
468
5. Test notify_method_capability
470
Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE]
471
<notification-uri: string>
472
<notification-capability: string>
473
<key-list: string-list>
475
The notify_method_capability test retrieves the notification
476
capability specified by the notification-capability string that is
477
specific to the notification-uri and matches it to the values
478
specified in the key-list. The test succeeds if a match occurs. The
479
type of match defaults to ":is", and the default comparator is
482
The notification-capability parameter is case insensitive.
484
The notify_method_capability test MUST fail unconditionally if the
485
specified notification-uri is syntactically invalid (as determined by
486
the valid_notify_method test, Section 4) or specifies an unsupported
487
notification method. However this MUST NOT cause an error.
489
The notify_method_capability test MUST fail unconditionally if the
490
specified notification-capability item is not known to the Sieve
491
interpreter. A script MUST NOT fail with an error if the item does
492
not exist. This allows scripts to be written that handle nonexistent
495
This document defines a single notification-capability value
496
"online", which is described below. Additional notification-
497
capability values may be defined by using the procedure defined in
500
The "relational" extension [Relational] adds a match type called
501
":count". The count of an notify_method_capability test is 0, if the
502
returned information is the empty string, or 1.
506
Melnikov, et al. Standards Track [Page 9]
508
RFC 5435 Sieve Extension: Notifications January 2009
511
For the "online" notification-capability, the
512
notify_method_capability test can match one of the following key-list
515
o "yes" - the entity identified by the notification-uri can receive
516
a notify notification immediately. Note that even after this
517
value is returned, there is no guarantee that the entity would
518
actually be able to receive any notification immediately or even
519
receive it at all. Transport errors, recipient policy, etc. can
522
o "no" - the entity identified by the notification-uri is not
523
currently available to receive an immediate notification.
525
o "maybe" - the Sieve interpreter can't determine if the entity
526
identified by the notification-uri is online or not.
531
if notify_method_capability
532
"xmpp:tim@example.com?message;subject=SIEVE"
535
notify :importance "1" :message "You got mail"
536
"xmpp:tim@example.com?message;subject=SIEVE";
538
notify :message "You got mail" "tel:+14085551212";
541
6. Modifier encodeurl to the 'set' Action
545
When the Sieve script specifies both "variables" [Variables] and
546
"enotify" capabilities in the "require", a new "set" action modifier
547
(see [Variables]) ":encodeurl" becomes available to Sieve scripts.
548
This modifier performs percent-encoding of any octet in the string
549
that doesn't belong to the "unreserved" set (see [URI]). The
550
percent-encoding procedure is described in [URI].
552
The ":encodeurl" modifier has precedence 15.
562
Melnikov, et al. Standards Track [Page 10]
564
RFC 5435 Sieve Extension: Notifications January 2009
568
require ["enotify", "variables"];
570
set :encodeurl "body_param" "Safe body&evil=evilbody";
572
notify "mailto:tim@example.com?body=${body_param}";
574
7. Interactions with Other Sieve Actions
576
The "notify" action is compatible with all other actions, and does
577
not affect the operation of other actions. In particular, the
578
"notify" action MUST NOT cancel the implicit keep.
580
Multiple executed "notify" actions are allowed. Specific
581
notification methods MAY allow multiple notifications from the same
582
script to be collapsed into one.
584
8. Security Considerations
586
Security considerations are discussed in [Sieve]. Additionally,
587
implementations must be careful to follow the security considerations
588
of the specific notification methods.
590
The "notify" action is potentially very dangerous. The path the
591
notification takes through the network may not be secure. An error
592
in the options string may cause the message to be transmitted to
593
someone it was not intended for, or may expose information to
596
Just because a notification is received doesn't mean that it was sent
597
by the Sieve implementation. It might be possible to forge
598
notifications or modify parts of valid notifications with some
599
notification methods.
601
Forgery of the ":importance" value (for example, by unauthorized
602
script modification) can potentially result in slowdown in
603
notification delivery.
605
Note that some components of notifications should not be trusted.
606
For example, the timestamp field can be easily forged or modified
607
when some notification transports are used. Even if the timestamp is
608
believed to be correct by the sender and is not modified in transit,
609
it might be misleading on the receiving system due to clock
618
Melnikov, et al. Standards Track [Page 11]
620
RFC 5435 Sieve Extension: Notifications January 2009
623
An organization may have a policy about the forwarding of classified
624
information to unclassified networks. Unless the policy is also
625
enforced in the module responsible for the generating (or sending) of
626
notifications, users can use the extension defined in this document
627
to extract classified information and bypass the policy.
629
Notifications can result in loops and bounces. Also, allowing a
630
single script to notify multiple destinations can be used as a means
631
of amplifying the number of messages in an attack. Moreover, if loop
632
detection is not properly implemented, it may be possible to set up
633
exponentially growing notification loops. Accordingly, Sieve
634
notification methods:
636
1. MUST provide mechanisms for avoiding notification loops.
638
2. MUST provide the means for administrators to limit the ability of
639
users to abuse notify. In particular, it MUST be possible to
640
limit the number of "notify" actions a script can perform.
641
Additionally, if no use cases exist for using "notify" with
642
multiple destinations, this limit SHOULD be set to 1. Additional
643
limits, such as the ability to restrict "notify" to local users,
644
MAY also be implemented.
646
3. MUST provide facilities to log the use of "notify" in order to
647
facilitate tracking down abuse.
649
4. MAY use script analysis to determine whether or not a given
650
script can be executed safely. While the Sieve language is
651
sufficiently complex so that full analysis of all possible
652
scripts is computationally infeasible, the majority of real-world
653
scripts are amenable to analysis. For example, an implementation
654
might allow scripts that it has determined to be safe to run
655
unhindered, block scripts that are potentially problematic, and
656
subject unclassifiable scripts to additional auditing and
659
Allowing "notify" action at all may not be appropriate in situations
660
where Sieve scripts are associated with email accounts that are
661
freely-available and/or not trackable to a human who can be held
662
accountable for creating message bombs or other abuse.
664
Implementations that construct URIs internally from various notify
665
parameters MUST make sure that all components of such URIs are
666
properly percent-encoded (see [URI]). In particular, this applies to
667
values of the ":from" and ":message" tagged arguments and may apply
668
to the ":options" values.
674
Melnikov, et al. Standards Track [Page 12]
676
RFC 5435 Sieve Extension: Notifications January 2009
679
Header/envelope tests [Sieve], together with Sieve variables, can be
680
used to extract the list of users to receive notifications from the
681
incoming email message or its envelope. This is potentially quite
682
dangerous, as this can be used for denial-of-service attacks on
683
recipients controlled by the message sender. For this reason,
684
implementations SHOULD NOT allow the use of variables containing
685
values extracted from the email message in the "method" parameter to
686
the "notify" action. Note that violation of this SHOULD NOT may
687
result in the creation of an open relay, i.e., any sender would be
688
able to create specially crafted email messages that would result in
689
notifications delivered to recipients under the control of the
690
sender. In the worst case, this might result in financial loss by
691
the user controlling the Sieve script and/or by recipients of
692
notifications (e.g., if a notification is an SMS message).
694
Note that the last SHOULD NOT is not a generic prohibition of use of
695
variables in the "notify" action, as controlling the target of a
696
notification by extracting it from user-owned data stores (such as
697
user's Lightweight Directory Access Protocol (LDAP) entry) is
698
considered to be useful.
700
It is imperative that whatever implementations use to store the user-
701
defined filtering scripts protect them from unauthorized
702
modification, to preserve the integrity of the mail system. An
703
attacker who can modify a script can cause mail to be discarded,
704
rejected, or forwarded to an unauthorized recipient. In addition,
705
it's possible that Sieve scripts might expose private information,
706
such as mailbox names or email addresses of favored (or disfavored)
707
correspondents. Because of that, scripts SHOULD also be protected
708
from unauthorized retrieval.
710
9. IANA Considerations
712
9.1. Registration of Sieve Extension
715
Subject: Registration of new Sieve extension
716
Capability name: enotify
717
Description: adds the "notify" action for notifying user about the
718
received message. It also provides two new tests:
719
valid_notify_method checks notification URIs for validity;
720
notify_method_capability can check recipients capabilities.
722
Contact address: The Sieve discussion list
723
<ietf-mta-filters@imc.org>
725
This information has been added to the list of Sieve extensions
726
available from http://www.iana.org/.
730
Melnikov, et al. Standards Track [Page 13]
732
RFC 5435 Sieve Extension: Notifications January 2009
735
9.2. New Registry for Sieve Notification Mechanisms
737
IANA has created a new registry for Sieve notification mechanisms.
738
This registry contains both vendor-controlled notification mechanism
739
names (beginning with "vnd.") and IETF-controlled notification
740
mechanism names. Vendor-controlled notification mechanism names have
741
the format as defined in the following paragraph and may be
742
registered on a "First Come First Served" basis [IANA-GUIDELINES], by
743
applying to IANA with the form specified later in this section.
744
Registration of notification mechanisms that do not begin with "vnd."
745
are registered using a "Specification Required" policy
748
Vendor-controlled notification mechanism names MUST have the form
749
"vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as
750
specified in the Application Configuration Access Protocol (ACAP)
751
Vendor Subtree registry [ACAP].
753
This defines the template for a new registry for Sieve notification
754
mechanisms, which has been created and is available from
755
http://www.iana.org/. There are no initial entries for this
759
Subject: Registration of new Sieve notification mechanism
760
Mechanism name: [the name of the mechanism]
761
Mechanism URI: [the RFC number of the document that defines the URI
762
used by this mechanism. Different mechanisms MUST use different
764
Mechanism-specific options: [the names of any Sieve notify options
765
(as used in the ":options" parameter) that are specific to this
766
mechanism, or "none"]
767
Permanent and readily available reference: [the RFC number or an URL
768
of the document that defines this notification mechanism]
769
Person and email address to contact for further information: [the
770
name and email address of the technical contact for information
771
about this mechanism]
773
9.3. New Registry for Notification-Capability Parameters
775
IANA has created a new registry for the notification-capability
776
parameters of the notify_method_capability test. This registry
777
contains both vendor-controlled notification-capability values
778
(beginning with "vnd.") and IETF-controlled notification-capability
779
values. Vendor-controlled notification-capability values have the
780
format as defined in the following paragraph and may be registered on
781
a "First Come First Served" basis [IANA-GUIDELINES], by applying to
782
IANA with the form specified later in this section. Registration of
786
Melnikov, et al. Standards Track [Page 14]
788
RFC 5435 Sieve Extension: Notifications January 2009
791
notification-capability values that do not begin with "vnd." are
792
registered using the "Specification Required" policy
795
Vendor-controlled notification-capability values MUST have the form
796
"vnd.<vendor-name>.<capability-name>", where <vendor-name> is as
797
specified in the ACAP Vendor Subtree registry [ACAP].
799
The following template must be used for registering notification-
800
capability parameters:
803
Subject: Registration of a new notification-capability parameter
804
Capability name: [the name of the notification-capability]
805
Description: [an explanation of the purpose of the notification-
807
Syntax: [formal definition of allowed values and their syntax]
808
Permanent and readily available reference(s): [the RFC number(s) or
809
an URL of the document that defines this notification mechanism]
810
Contact information: [the name and email address of the technical
811
contact for information about this mechanism]
813
Below is the registration form for the "online" notification-
817
Subject: Registration of a new notification-capability parameter
818
Capability name: online
819
Description: Returns whether the entity identified by the
820
notification-uri parameter to the notify_method_capability test
821
can receive a notify notification immediately.
822
Syntax: Can contain one of three values: "yes", "no", and, "maybe".
823
Values MUST be in lowercase.
824
Permanent and readily available reference(s): This RFC
825
Contact information: The Sieve discussion list
826
<ietf-mta-filters@imc.org>
830
Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus
831
Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E.
832
Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt
833
Gulbrandsen, Peter Saint-Andre, Sean Turner, Cullen Jennings, and
834
Pasi Eronen for help with this document.
842
Melnikov, et al. Standards Track [Page 15]
844
RFC 5435 Sieve Extension: Notifications January 2009
849
11.1. Normative References
851
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
852
for Syntax Specifications: ABNF", STD 68,
853
RFC 5234, January 2008.
855
[Kwds] Bradner, S., "Key words for use in RFCs to
856
Indicate Requirement Levels", BCP 14, RFC 2119,
859
[MailTo] Leiba, B. and M. Haardt, "Sieve Notification
860
Mechanism: mailto", RFC 5436, January 2009.
862
[Relational] Segmuller, W. and B. Leiba, "Sieve Extension:
863
Relational Tests", RFC 5231, January 2008.
865
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve:
866
An Email Filtering Language", RFC 5228,
869
[URI] Berners-Lee, T., Fielding, R., and L. Masinter,
870
"Uniform Resource Identifier (URI): Generic
871
Syntax", STD 66, RFC 3986, January 2005.
873
[Variables] Homme, K., "Sieve Extension: Variables", RFC 5229,
876
11.2. Informative References
878
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
879
Configuration Access Protocol", RFC 2244,
882
[IANA-GUIDELINES] Narten, T. and H. Alvestrand, "Guidelines for
883
Writing an IANA Considerations Section in RFCs",
884
BCP 26, RFC 5226, May 2008.
886
[TEL-URI] Schulzrinne, H., "The tel URI for Telephone
887
Numbers", RFC 3966, December 2004.
889
[XMPP] Saint-Andre, Ed., P., "Extensible Messaging and
890
Presence Protocol (XMPP): Core", RFC 3920,
898
Melnikov, et al. Standards Track [Page 16]
900
RFC 5435 Sieve Extension: Notifications January 2009
903
[XMPP-URI] Saint-Andre, P., "Internationalized Resource
904
Identifiers (IRIs) and Uniform Resource
905
Identifiers (URIs) for the Extensible Messaging
906
and Presence Protocol (XMPP)", RFC 5122,
911
Alexey Melnikov (editor)
913
5 Castle Business Village
915
Hampton, Middlesex TW12 2BX
918
EMail: Alexey.Melnikov@isode.com
922
IBM T.J. Watson Research Center
927
Phone: +1 914 784 7941
928
EMail: leiba@watson.ibm.com
932
IBM T.J. Watson Research Center
937
Phone: +1 914 784 7408
938
EMail: werewolf@us.ibm.com
944
San Francisco, CA 94117
947
Phone: +1 510 260-4175
948
EMail: timmartin@alumni.cmu.edu
954
Melnikov, et al. Standards Track [Page 17]
added
removed
pigeonhole/doc/rfc/notify.rfc5435.txt
