idnits 2.17.1 draft-ietf-sieve-notify-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 988. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 24, 2007) is 5967 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'COMPARATOR' is mentioned on line 563, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 563, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-GUIDELINES') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Limited 4 Intended status: Standards Track B. Leiba, Ed. 5 Expires: June 26, 2008 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 BeThereBeSquare Inc. 9 December 24, 2007 11 SIEVE Email Filtering: Extension for Notifications 12 draft-ietf-sieve-notify-12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 26, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 Users go to great lengths to be notified as quickly as possible that 46 they have received new mail. Most of these methods involve polling 47 to check for new messages periodically. A push method handled by the 48 final delivery agent gives users quicker notifications and saves 49 server resources. This document does not specify the notification 50 method but it is expected that using existing instant messaging 51 infrastructure such as XMPP, or GSM Short Message Service (SMS) 52 messages will be popular. This draft describes an extension to the 53 Sieve mail filtering language that allows users to give specific 54 rules for how and when notifications should be sent. 56 Changes since draft-ietf-sieve-notify-11 58 o [As per DISCUSS from Cullen] Changed a SHOULD to a MUST in the 59 following requirement: A notification SHOULD include means to 60 identify/track its origin. 62 o [As per DISCUSS from Cullen] Changed sms: URIs to tel: URIs. 64 o [As per COMMENT from Chris] Updated the notify mechanism IANA 65 registration template to allow for specifications which are not 66 RFCs. 68 o Additional security considerations as per SecDir review from Sean 69 Turner. 71 o Added a new registry for the notification-capability parameter of 72 the notify_method_capability test (as per Pasi Eronen gen-art 73 review). 75 Changes since draft-ietf-sieve-notify-10 77 o Updated IANA registration template as per discussion in Vancouver. 79 o Added ABNF for :options names. 81 o Prohibit notification methods from defining new Sieve tags. 83 Changes since draft-ietf-sieve-notify-09 85 o Extended requirements for avoiding loops and amplification 86 attacks. 88 o Other minor editorial changes as per AD's (Lisa) review. 90 Changes since draft-ietf-sieve-notify-08 92 o Added missing IANA registry for notification methods. 94 Changes since draft-ietf-sieve-notify-07 96 o Added a new "set" modifier for URL percent-encoding. 98 o Clarified that notification methods must address notification 99 loops. 101 o Added an implementation consideration for implementations that use 102 URIs internally. 104 Changes since draft-ietf-sieve-notify-06 106 o Remove extract_text. The WG consensus was to move it to another 107 document, such as Sieve MIME loops. 109 o Deleted markers for open issues from the document. 111 o Clarified that a notification mechanism can treat some URI 112 parameters as an error. 114 o Added notify_method_capability test and example. 116 o Minor corrections to the IANA registration as a result of other 117 changes. 119 Changes since draft-ietf-sieve-notify-05 121 o Fixed XMPP URI in one example. 123 o Addressed Michael's issue with how timestamp are described. 125 o Renamed "valid_notif_method" to "valid_notify_method". 127 o Added text about truncation of a textual part when it is stored in 128 a variable using extract_text. 130 o Changed tagged :method argument to positional argument. 132 o Added text about notification throttling, identifying notification 133 source and restricting values of the :from parameter. 135 o Added a requirement on documents describing notification methods 136 to list which URI parameters must be ignored. 138 Changes since draft-ietf-sieve-notify-04 139 o Made notification method required. 141 o Defined "mailto" as a mandatory-to-implement method. 143 o Added normative reference to mailto. 145 o Clarified that :importance may be treated as a transport 146 indicator. 148 o Clarified that :importance value can be included in the default 149 :message, if one is not specified. 151 o Made the default :message implementation specific. 153 o Renamed the capability name from "notify" to "enotify" 155 o Updated IANA registration. 157 o Moved text about ManageSieve capability to the ManageSieve 158 document itself. 160 o Removed reference to IANA registry for options. 162 o Some miscellaneous text cleanup and clarification. 164 Changes since draft-ietf-sieve-notify-03 166 o Added a warning that "notify" must not be used as a crappy form of 167 "redirect". 169 o Added a warning about using "notify" to forward confidential 170 information in order to bypass organization's policy. 172 o Fixed syntax of the :options argument - it is a string list, each 173 string containing "=" 175 o Renamed :priority to :importance 177 o Cleaned up section about requirements on methods. 179 Changes since draft-ietf-sieve-notify-02 181 o Added :from tagged argument. 183 o Added Extract_text action, which allows to extract content of the 184 first text/* part. 186 o Added back the ":options" parameter to the notify action. 188 o Added new section talking about requirements on notification 189 method specs. 191 o Added more examples. 193 Changes since draft-ietf-sieve-notify-00 195 o Updated references, etc. 197 o Added IANA considerations section. 199 o Removed denotify action. 201 o Updated examples to use the variables extension. 203 o Replaced notification method with URI. 205 o Removed text suggesting that this extension can be used to track 206 all Sieve actions taken. 208 o Changed priority to be a string. 210 o Added text about URI verification. 212 o Clarified that a notification method is allowed to perform 213 adaptation of notification context (e.g. truncation, charset 214 conversion, etc.). These adaptations must be documented in a 215 document describing the notification method. 217 o Clarified that notify is compatible with all existing actions. 219 o Removed the :id parameter to the notify action. 221 o Added valid_notif_method test that allows to test if an 222 notification method (URI) is supported. 224 o Added a new capability response to ManageSieve that allows to 225 report supported notification types. 227 Table of Contents 229 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 230 1.1. Conventions used in this document . . . . . . . . . . . . . 7 232 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 7 234 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 7 235 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 7 236 3.2. Notify parameter "method" . . . . . . . . . . . . . . . . . 7 237 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 8 238 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 8 239 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 9 240 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 9 241 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 242 3.8. Requirements on notification methods specifications . . . . 12 244 4. Test valid_notify_method . . . . . . . . . . . . . . . . . . 13 246 5. Test notify_method_capability . . . . . . . . . . . . . . . 14 248 6. Modifier encodeurl to the 'set' action . . . . . . . . . . . 15 250 7. Interactions with Other Sieve Actions . . . . . . . . . . . 16 252 8. Security Considerations . . . . . . . . . . . . . . . . . . 16 254 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 255 9.1. Registration of Sieve extension . . . . . . . . . . . . . . 18 256 9.2. New registry for Sieve notification mechanisms . . . . . . . 18 257 9.3. New registry for notification-capability parameters . . . . 19 259 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 261 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 262 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 20 263 11.2. Informative References . . . . . . . . . . . . . . . . . . . 21 265 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 266 Intellectual Property and Copyright Statements . . . . . . . 23 268 1. Introduction 270 This is an extension to the Sieve language defined by [Sieve] for 271 providing instant notifications. It defines the new action "notify". 273 This document does not specify the notification methods. Examples of 274 possible notification methods are email and XMPP. To allow a 275 mechanism for portability of scripts that use notifications, 276 implementation of the [MailTo] method is mandatory. Other available 277 methods shall depend upon the implementation and configuration of the 278 system. 280 1.1. Conventions used in this document 282 Conventions for notations are as in [Sieve] section 1.1, including 283 the use of [ABNF]. 285 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 286 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 287 document are to be interpreted as described in [Kwds]. 289 2. Capability Identifier 291 The capability string associated with the extension defined in this 292 document is "enotify". 294 3. Notify Action 296 3.1. Notify Action Syntax and Semantics 298 Usage: notify [":from" string] 299 [":importance" <"1" / "2" / "3">] 300 [":options" string-list] 301 [":message" string] 302 304 The Notify action specifies that a notification should be sent to a 305 user. The format of the notification is implementation-defined and 306 is also affected by the notification method used (see Section 3.2). 307 However, all content specified in the :message parameter SHOULD be 308 included. 310 3.2. Notify parameter "method" 312 The method positional parameter identifies the notification method 313 that will be used; it is a URI [URI]. For example, the notification 314 method can be a tel URI [TEL-URI] with a phone number to send SMS 315 messages to, or an XMPP [XMPP] URI containing an XMPP identifier 316 [XMPP-URI]. 318 The supported URI values will be site-specific, but support for the 319 [MailTo] method is REQUIRED in order to insure interoperability. If 320 a URI schema is specified that the implementation does not support, 321 the notification MUST cause an error condition. Sieve scripts can 322 check the supported methods using the "valid_notify_method" test to 323 be sure that they only use supported ones, to avoid such error 324 conditions. 326 If the method parameter contains a supported URI schema, then the URI 327 MUST be checked for syntactic validity. An invalid URI syntax or an 328 unsupported URI extension MUST cause an error. An implementation MAY 329 enforce other semantic restrictions on URIs -- for example to 330 restrict phone numbers in a tel: URI to a particular geographical 331 region -- and will treat violations of such semantic restrictions as 332 errors. 334 3.3. Notify tag ":from" 336 A ":from" parameter may be used to specify an author of the 337 notification. The syntax of this parameter's value is method- 338 specific. Implementations SHOULD check the syntax according to the 339 notification method specification and generate an error when a 340 syntactically invalid ":from" parameter is specified. 342 In order to minimize/prevent forgery of the author value, 343 implementations SHOULD impose restrictions on what values can 344 specified in a ":from" parameter. For example, an implementation may 345 restrict this value to be a member of a list of known author 346 addresses or to belong to a particular domain. It is suggested that 347 values which don't satisfy such restrictions simply be ignored rather 348 than causing the notify action to fail. 350 3.4. Notify tag ":importance" 352 The :importance tag specifies the importance of quick delivery of the 353 notification as perceived by the Sieve script owner. The :importance 354 tag is followed by a numeric value represented as a string: "1" (high 355 importance), "2" (normal importance), and "3" (low importance). If 356 no importance is given, the default value "2" SHOULD be assumed. A 357 notification method MAY treat the importance value as a transport 358 indicator. For example, it might deliver notifications of high 359 importance quicker than notifications of normal or low importance. 360 Some notification methods allow users to specify their state of 361 activity (for example "busy" or "away from keyboard"). If the 362 notification method provides this information it SHOULD be used to 363 selectively send notifications. If, for example, the user marks 364 herself as "busy", a notification method can require that a 365 notification with importance of "3" is not to be sent, however the 366 user should be notified of a notification with higher importance. 368 If the notification method allows users to filter messages based upon 369 certain parameters in the message, users SHOULD be able to filter 370 based upon importance. If the notification method does not support 371 importance, then this parameter MUST be ignored. An implementation 372 MAY include the importance value in the default message Section 3.6, 373 if one is not provided. 375 3.5. Notify tag ":options" 377 The :options tag is used to send additional parameters to the 378 notification method. Interpretation of the parameters is method- 379 specific. This document doesn't specify any such additional 380 parameter. 382 Each string in the options string list has the following syntax: 383 "=". 384 where optionname has the following ABNF [ABNF]: 385 l-d = ALPHA / DIGIT 386 l-d-p = l-d / "." / "-" / "_" 387 optionname = l-d *l-d-p 388 value = *(%x01-09 / %x0B-0C / %x0E-FF) 390 3.6. Notify tag ":message" 392 The :message tag specifies the message data to be included in the 393 notification. The entirety of the string SHOULD be sent but 394 implementations MAY shorten the message for technical or aesthetic 395 reasons. If the message parameter is absent, a default 396 implementation-specific message is used. Unless specified otherwise 397 by a particular notification mechanism, an implementation default 398 containing at least the value of the "From" header field and the 399 value of the "Subject" header field is RECOMMENDED. 401 In order to construct more complex messages the notify extension can 402 be used together with the Sieve variables extension [Variables], as 403 shown in the examples below. 405 3.7. Examples 406 Example 1: 407 require ["enotify", "fileinto", "variables"]; 409 if header :contains "from" "boss@example.org" { 410 notify :importance "1" 411 :message "This is probably very important" 412 "mailto:alm@example.com"; 413 # Don't send any further notifications 414 stop; 415 } 417 if header :contains "to" "sievemailinglist@example.org" { 418 # :matches is used to get the value of the Subject header 419 if header :matches "Subject" "*" { 420 set "subject" "${1}"; 421 } 423 # :matches is used to get the value of the From header 424 if header :matches "From" "*" { 425 set "from" "${1}"; 426 } 428 notify :importance "3" 429 :message "[SIEVE] ${from}: ${subject}" 430 "mailto:alm@example.com"; 431 fileinto "INBOX.sieve"; 432 } 434 Example 2: 435 require ["enotify", "fileinto", "variables", "envelope"]; 437 if header :matches "from" "*@*.example.org" { 438 # :matches is used to get the MAIL FROM address 439 if envelope :all :matches "from" "*" { 440 set "env_from" " [really: ${1}]"; 441 } 443 # :matches is used to get the value of the Subject header 444 if header :matches "Subject" "*" { 445 set "subject" "${1}"; 446 } 448 # :matches is used to get the address from the From header 449 if address :matches :all "from" "*" { 450 set "from_addr" "${1}"; 451 } 453 notify :message "${from_addr}${env_from}: ${subject}" 454 "mailto:alm@example.com"; 455 } 457 Example 3: 458 require ["enotify", "variables"]; 460 set "notif_method" 461 "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail"; 463 if header :contains "subject" "Your dog" { 464 set "notif_method" "tel:+14085551212"; 465 } 467 if header :contains "to" "sievemailinglist@example.org" { 468 set "notif_method" ""; 469 } 471 if not string :is "${notif_method}" "" { 472 notify "${notif_method}"; 473 } 475 if header :contains "from" "boss@example.org" { 476 # :matches is used to get the value of the Subject header 477 if header :matches "Subject" "*" { 478 set "subject" "${1}"; 479 } 481 # don't need high importance notification for 482 # a 'for your information' 483 if not header :contains "subject" "FYI:" { 484 notify :importance "1" :message "BOSS: ${subject}" 485 "tel:+14085551212"; 486 } 487 } 489 3.8. Requirements on notification methods specifications 491 This section describes requirements for documents that define 492 specific Sieve notification methods. 494 Notification mechanisms MUST NOT add new Sieve tags to the notify 495 action. 497 A notification method MAY allow modification of the final 498 notification text -- for example, truncating it if it exceeds a 499 length limit, or modifying characters that can not be represented in 500 the target character set. Characters in the notification text which 501 can't be represented by the notification method SHOULD be replaced 502 with a symbol indicating an unknown character. Allowed modifications 503 MUST be documented in the document describing the notification 504 method. 506 A notification method MAY ignore parameters specified in the Notify 507 action. 509 A notification method MAY recommend the default message value to be 510 used if the :message argument is not specified. 512 Notifications SHOULD include timestamps, if the notification method 513 allows for their transmission outside of the textual message. 514 Implementation methods which can only transmit timestamps in the 515 textual message MAY include them in the textual message. 517 A notification MUST include means to identify/track its origin, in 518 order to allow a recipient to stop notifications or find out how to 519 contact the sender. This requirement is to help tracking a 520 misconfigured or abusive origin of notifications. 522 Methods SHOULD NOT include any other extraneous information not 523 specified in parameters to the notify action. 525 Methods MUST specify which URI parameters (if any) must be ignored, 526 which ones must be used in the resulting notification and which ones 527 must cause an error. 529 Methods MUST specify what values are returned by the 530 notify_method_capability test Section 5, in particular for the 531 "online" notification-capability. 533 If there are errors sending the notification, the Sieve interpreter 534 SHOULD ignore the notification and not retry indefinitely. The Sieve 535 interpreter MAY throttle notifications; if it does, a request to send 536 a notification MAY be silently ignored. Documents describing 537 notification methods SHOULD describe how retries, throttling, 538 duplicate suppression (if any), etc. are to be handled by 539 implementations. 541 4. Test valid_notify_method 543 Usage: valid_notify_method 545 The "valid_notify_method" test is true if the notification methods 546 listed in the notification-uris argument are supported and they are 547 valid both syntactically (including URI parameters) and semantically 548 (including implementation-specific semantic restrictions). This test 549 MUST perform exactly the same validation as would be performed on the 550 "method" parameter to the "notify" action. 552 The test is true only if ALL of the listed notification methods are 553 supported and valid. 555 Example 4 (partial): 556 if not valid_notify_method ["mailto:", 557 "http://gw.example.net/notify?test"] { 558 stop; 559 } 561 5. Test notify_method_capability 563 Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE] 564 565 566 568 The "notify_method_capability" test retrieves the notification 569 capability specified by the notification-capability string that is 570 specific to the notification-uri and matches it to the values 571 specified in the key-list. The test succeeds if a match occurs. The 572 type of match defaults to ":is" and the default comparator is 573 "i;ascii-casemap". 575 The notification-capability parameter is case insensitive. 577 The notify_method_capability test MUST fail unconditionally if the 578 specified notification-uri is syntactically invalid (as determined by 579 the valid_notify_method test Section 4) or specifies an unsupported 580 notification method. However this MUST NOT cause an error. 582 The notify_method_capability test MUST fail unconditionally if the 583 specified notification-capability item is not known to the Sieve 584 interpreter. A script MUST NOT fail with an error if the item does 585 not exist. This allows scripts to be written that handle nonexistent 586 items gracefully. 588 This document defines a single notification-capability value 589 "online", which is described below. Additional notification- 590 capability values may be defined by using the procedure defined in 591 Section 9.3. 593 The "relational" extension [Relational] adds a match type called 594 ":count". The count of an notify_method_capability test is 0 if the 595 returned information is the empty string, or 1 otherwise. 597 For the "online" notification-capability the notify_method_capability 598 test can match one of the following key-list values: 600 o "yes" - the entity identified by the notification-uri can receive 601 a notify notification immediately. Note that even after this 602 value is returned, there is no guarantee that the entity would 603 actually be able to receive any notification immediately or even 604 receive it at all. Transport errors, recipient policy, etc. can 605 prevent that. 607 o "no" - the entity identified by the notification-uri is not 608 currently available to receive an immediate notification. 610 o "maybe" - Sieve interpreter can't determine if the the entity 611 identified by the notification-uri is online or not. 613 Example 5: 614 require ["enotify"]; 616 if notify_method_capability 617 "xmpp:tim@example.com?message;subject=SIEVE" 618 "Online" 619 "yes" { 620 notify :importance "1" :message "You got mail" 621 "xmpp:tim@example.com?message;subject=SIEVE"; 622 } else { 623 notify :message "You got mail" "tel:+14085551212"; 624 } 626 6. Modifier encodeurl to the 'set' action 628 Usage: ":encodeurl" 630 When the Sieve script specifies both "variables" [Variables] and 631 "enotify" capabilities in the "require", a new "set" action modifier 632 (see [Variables]) ":encodeurl" becomes available to Sieve scripts. 633 This modifier performs percent-encoding of any octet in the string 634 which doesn't belong to the "unreserved" set (see [URI]). The 635 percent-encoding procedure is described in [URI]. 637 The ":encodeurl" modifier has precedence 15. 639 Example 6: 640 require ["enotify", "variables"]; 642 set :encodeurl "body_param" "Safe body&evil=evilbody"; 644 notify "mailto:tim@example.com?body=${body_param}"; 646 7. Interactions with Other Sieve Actions 648 The notify action is compatible with all other actions, and does not 649 affect the operation of other actions. In particular, the notify 650 action MUST NOT cancel the implicit keep. 652 Multiple executed notify actions are allowed. Specific notification 653 methods MAY allow multiple notifications from the same script to be 654 collapsed into one. 656 8. Security Considerations 658 Security considerations are discussed in [Sieve]. Additionally, 659 implementations must be careful to follow the security considerations 660 of the specific notification methods. 662 The notify action is potentially very dangerous. The path the 663 notification takes through the network may not be secure. An error 664 in the options string may cause the message to be transmitted to 665 someone it was not intended for, or may expose information to 666 eavesdroppers. 668 Just because a notification is received doesn't mean that it was sent 669 by the Sieve implementation. It might be possible to forge 670 notifications or modify parts of valid notifications with some 671 notification methods. 673 Forgery of the :importance value (for example by unauthorized script 674 modification) can potentially result in slow down in notification 675 delivery. 677 Note that some components of notifications should not be trusted. 678 For example the timestamp field can be easily forged or modified when 679 some notification transports are used. Even if the timestamp is 680 believed to be correct by the sender and is not modified in transit, 681 it might be misleading on the receiving system due to clock 682 differences. 684 An organization may have a policy about the forwarding of classified 685 information to unclassified networks. Unless the policy is also 686 enforced in the module responsible for generating (or sending) of 687 notifications, users can use the extension defined in this document 688 to extract classified information and bypass the policy. 690 Notifications can result in loops and bounces. Also, allowing a 691 single script to notify multiple destinations can be used as a means 692 of amplifying the number of messages in an attack. Moreover, if loop 693 detection is not properly implemented it may be possible to set up 694 exponentially growing notification loops. Accordingly, Sieve 695 notification methods: 697 1. MUST provide mechanisms for avoiding notification loops. 699 2. MUST provide the means for administrators to limit the ability of 700 users to abuse notify. In particular, it MUST be possible to 701 limit the number of notify actions a script can perform. 702 Additionally, if no use cases exist for using notify with 703 multiple destinations, this limit SHOULD be set to 1. Additional 704 limits, such as the ability to restrict notify to local users MAY 705 also be implemented. 707 3. MUST provide facilities to log use of notify in order to 708 facilitate tracking down abuse. 710 4. MAY use script analysis to determine whether or not a given 711 script can be executed safely. While the Sieve language is 712 sufficiently complex that full analysis of all possible scripts 713 is computationally infeasible, the majority of real-world scripts 714 are amenable to analysis. For example, an implementation might 715 allow scripts that it has determined are safe to run unhindered, 716 block scripts that are potentially problematic, and subject 717 unclassifiable scripts to additional auditing and logging. 719 Allowing notify action at all may not be appropriate in situations 720 where Sieve scripts are associated with email accounts which are 721 freely-available and/or not trackable to a human who can be held 722 accountable for creating message bombs or other abuse. 724 Implementations that construct URIs internally from various notify 725 parameters MUST make sure that all components of such URIs are 726 properly percent-encoded (see [URI]). In particular this applies to 727 values of the :from and the :message tagged arguments and may apply 728 to the :options values. 730 Header/envelope tests [Sieve] together with Sieve variables can be 731 used to extract the list of users to receive notifications from the 732 incoming email message or its envelope. This is potentially quite 733 dangerous, as this can be used for Deny Of Service attacks on 734 recipients controlled by the message sender. For this reason 735 implementations SHOULD NOT allow use of variables containing values 736 extracted from the email message in the method parameter to the 737 notify action. Note that violation of this SHOULD NOT may result in 738 the creation of an open relay, i.e. any sender would be able to 739 create specially crafted email messages that would result in 740 notifications delivered to recipients under the control of the 741 sender. In worst case this might result in financial loss by user 742 controlling the Sieve script and/or by recipients of notifications 743 (e.g. if a notification is an SMS message). 745 Note that the last SHOULD NOT is not a generic prohibition of use of 746 variables in the notify action, as controlling the target of a 747 notification by extracting it from user owned data stores (such as 748 user's LDAP entry) is considered to be useful. 750 9. IANA Considerations 752 9.1. Registration of Sieve extension 754 To: iana@iana.org 755 Subject: Registration of new Sieve extension 756 Capability name: enotify 757 Description: adds the 'notify' action for notifying user about the 758 received message. It also provides two new test: valid_notify_method 759 checks notification URIs for validity; notify_method_capability can 760 check recipients capabilities. 761 RFC number: this RFC 762 Contact address: 763 The Sieve discussion list 765 This information should be added to the list of sieve extensions 766 given on http://www.iana.org/assignments/sieve-extensions. 768 9.2. New registry for Sieve notification mechanisms 770 IANA is requested to create a new registry for Sieve notification 771 mechanisms. This registry contains both vendor-controlled 772 notification mechanism names (beginning with "vnd.") and IETF- 773 controlled notification mechanism names. Vendor-controlled 774 notification mechanism names have the format as defined in the 775 following paragraph and may be registered on a "First Come First 776 Served" basis [IANA-GUIDELINES], by applying to IANA with the form 777 specified later in this section. Registration of notification 778 mechanisms that do not begin with "vnd." are registered using the 779 "Specification Required" policy [IANA-GUIDELINES]. 781 Vendor-controlled notification mechanism names MUST have the form 782 "vnd..", where is as 783 specified in the ACAP Vendor Subtree registry [ACAP]. 785 This defines the template for a new registry for Sieve notification 786 mechanisms, to be created as 787 http://www.iana.org/assignments/sieve-notification. There are no 788 initial entries for this registry. 790 To: iana@iana.org 791 Subject: Registration of new Sieve notification mechanism 792 Mechanism name: [the name of the mechanism] 793 Mechanism URI: [the RFC number of the document that defines the URI 794 used by this mechanism. Different mechanisms MUST use different URI 795 schema.] 796 Mechanism-specific options: [the names of any Sieve notify option 797 names (as used in the :options parameter) that are specific to this 798 mechanism, or "none"] 799 Permanent and readily available reference: [the RFC number or an URL 800 of the document that defines this notification mechanism] 801 Person and email address to contact for further information: [the 802 name and email address of the technical contact for information about 803 this mechanism] 805 9.3. New registry for notification-capability parameters 807 IANA is requested to create a new registry for notification- 808 capability parameter of the notify_method_capability test. This 809 registry contains both vendor-controlled notification-capability 810 values (beginning with "vnd.") and IETF-controlled notification- 811 capability values. Vendor-controlled notification-capability values 812 have the format as defined in the following paragraph and may be 813 registered on a "First Come First Served" basis [IANA-GUIDELINES], by 814 applying to IANA with the form specified later in this section. 815 Registration of notification-capability values that do not begin with 816 "vnd." are registered using the "Specification Required" policy 817 [IANA-GUIDELINES]. 819 Vendor-controlled notification-capability values MUST have the form 820 "vnd..", where is as 821 specified in the ACAP Vendor Subtree registry [ACAP]. 823 The following template must be used for registering notification- 824 capability parameters: 826 To: iana@iana.org 827 Subject: Registration of a new notification-capability parameter 828 Capability name: [the name of the notification-capability] 829 Description: [a description of what the notification-capability is 830 for] 831 Syntax: [formal definition of allowed values and their syntax] 832 Permanent and readily available reference(s): [the RFC number(s) or 833 an URL of the document that defines this notification mechanism] 834 Contact information: [the name and email address of the technical 835 contact for information about this mechanism] 837 Below is the registration form for the "online" notification- 838 capability: 839 To: iana@iana.org 840 Subject: Registration of a new notification-capability parameter 841 Capability name: online 842 Description: Returns whether the entity identified by the 843 notification-uri parameter to the notify_method_capability test can 844 receive a notify notification immediately. 845 Syntax: Can contain one of three values: "yes", "no" and "maybe". 846 Values MUST be in lowercase. 847 Permanent and readily available reference(s): This RFC 848 Contact information: The Sieve discussion list 849 851 10. Acknowledgements 853 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 854 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 855 Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt 856 Gulbrandsen, Peter Saint-Andre, Sean Turner, Cullen Jennings and Pasi 857 Eronen for help with this document. 859 11. References 861 11.1. Normative References 863 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 864 Specifications: ABNF", RFC 4234, October 2005. 866 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", RFC 2119, March 1997. 869 [MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 870 mailto", work in progress, draft-ietf-sieve-notify-mailto, 871 October 2006. 873 [Relational] 874 Segmuller, W. and B. Leiba, "Sieve Extension: Relational 875 Tests", work in progress, draft-ietf-sieve-3431bis, 876 December 2005. 878 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 879 Language", work in progress, draft-ietf-sieve-3028bis, 880 August 2006. 882 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 883 Resource Identifier (URI): Generic Syntax", STD 66, 884 RFC 3986, January 2005. 886 [Variables] 887 Homme, K., "Sieve Extension: Variables", work in 888 progress, draft-ietf-sieve-variables, December 2005. 890 11.2. Informative References 892 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 893 Configuration Access Protocol", RFC 2244, November 1997. 895 [IANA-GUIDELINES] 896 Narten, T. and H. Alvestrand, "Guidelines for Writing an 897 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 898 October 1998. 900 [TEL-URI] Schulzrinne, H., "The tel URI for Telephone Numbers", 901 RFC 3966, December 2004. 903 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 904 Protocol (XMPP): Core", RFC 3920, October 2004. 906 [XMPP-URI] 907 Saint-Andre, P., "Internationalized Resource Identifiers 908 (IRIs) and Uniform Resource Identifiers (URIs) for the 909 Extensible Messaging and Presence Protocol (XMPP)", work 910 in progress, draft-saintandre-rfc4622bis, June 2007. 912 Authors' Addresses 914 Alexey Melnikov (editor) 915 Isode Limited 916 5 Castle Business Village 917 36 Station Road 918 Hampton, Middlesex TW12 2BX 919 UK 921 Email: Alexey.Melnikov@isode.com 923 Barry Leiba (editor) 924 IBM T.J. Watson Research Center 925 19 Skyline Drive 926 Hawthorne, NY 10532 927 US 929 Phone: +1 914 784 7941 930 Email: leiba@watson.ibm.com 932 Wolfgang Segmuller 933 IBM T.J. Watson Research Center 934 19 Skyline Drive 935 Hawthorne, NY 10532 936 US 938 Phone: +1 914 784 7408 939 Email: werewolf@us.ibm.com 941 Tim Martin 942 BeThereBeSquare Inc. 943 672 Haight st. 944 San Francisco, CA 94117 945 US 947 Phone: +1 510 260-4175 948 Email: timmartin@alumni.cmu.edu 950 Full Copyright Statement 952 Copyright (C) The IETF Trust (2007). 954 This document is subject to the rights, licenses and restrictions 955 contained in BCP 78, and except as set forth therein, the authors 956 retain all their rights. 958 This document and the information contained herein are provided on an 959 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 960 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 961 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 962 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 963 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 964 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 966 Intellectual Property 968 The IETF takes no position regarding the validity or scope of any 969 Intellectual Property Rights or other rights that might be claimed to 970 pertain to the implementation or use of the technology described in 971 this document or the extent to which any license under such rights 972 might or might not be available; nor does it represent that it has 973 made any independent effort to identify any such rights. Information 974 on the procedures with respect to rights in RFC documents can be 975 found in BCP 78 and BCP 79. 977 Copies of IPR disclosures made to the IETF Secretariat and any 978 assurances of licenses to be made available, or the result of an 979 attempt made to obtain a general license or permission for the use of 980 such proprietary rights by implementers or users of this 981 specification can be obtained from the IETF on-line IPR repository at 982 http://www.ietf.org/ipr. 984 The IETF invites any interested party to bring to its attention any 985 copyrights, patents or patent applications, or other proprietary 986 rights that may cover technology that may be required to implement 987 this standard. Please address the information to the IETF at 988 ietf-ipr@ietf.org. 990 Acknowledgment 992 Funding for the RFC Editor function is provided by the IETF 993 Administrative Support Activity (IASA).