7
Network Working Group B. Leiba
8
Request for Comments: 5436 IBM T.J. Watson Research Center
9
Updates: 3834 M. Haardt
10
Category: Standards Track freenet.de GmbH
14
Sieve Notification Mechanism: mailto
18
This document specifies an Internet standards track protocol for the
19
Internet community, and requests discussion and suggestions for
20
improvements. Please refer to the current edition of the "Internet
21
Official Protocol Standards" (STD 1) for the standardization state
22
and status of this protocol. Distribution of this memo is unlimited.
26
Copyright (c) 2009 IETF Trust and the persons identified as the
27
document authors. All rights reserved.
29
This document is subject to BCP 78 and the IETF Trust's Legal
30
Provisions Relating to IETF Documents (http://trustee.ietf.org/
31
license-info) in effect on the date of publication of this document.
32
Please review these documents carefully, as they describe your rights
33
and restrictions with respect to this document.
37
This document describes a profile of the Sieve extension for
38
notifications, to allow notifications to be sent by electronic mail.
58
Leiba & Haardt Standards Track [Page 1]
60
RFC 5436 Sieve Notification Mechanism: mailto January 2009
65
1. Introduction ....................................................3
66
1.1. Overview ...................................................3
67
1.2. Conventions Used in This Document ..........................3
68
2. Definition ......................................................3
69
2.1. Notify Parameter "method" ..................................3
70
2.2. Test notify_method_capability ..............................3
71
2.3. Notify Tag ":from" .........................................3
72
2.4. Notify Tag ":importance" ...................................4
73
2.5. Notify Tag ":options" ......................................4
74
2.6. Notify Tag ":message" ......................................4
75
2.7. Other Definitions ..........................................4
76
2.7.1. The Auto-Submitted Header Field .....................6
77
3. Examples ........................................................7
78
4. Internationalization Considerations .............................8
79
5. Security Considerations .........................................9
80
6. IANA Considerations ............................................10
81
6.1. Registration of Notification Mechanism ....................10
82
6.2. New Registry for Auto-Submitted Header Field Keywords .....10
83
6.3. Initial Registration of Auto-Submitted Header
84
Field Keywords ............................................11
85
7. References .....................................................11
86
7.1. Normative References ......................................11
87
7.2. Informative References ....................................12
114
Leiba & Haardt Standards Track [Page 2]
116
RFC 5436 Sieve Notification Mechanism: mailto January 2009
123
The [Notify] extension to the [Sieve] mail filtering language is a
124
framework for providing notifications by employing URIs to specify
125
the notification mechanism. This document defines how [mailto] URIs
126
are used to generate notifications by email.
128
1.2. Conventions Used in This Document
130
Conventions for notations are as in Section 1.1 of [Sieve], including
133
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
134
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
135
document are to be interpreted as described in [Kwds].
139
The mailto mechanism results in the sending of a new email message (a
140
"notification message") to notify a recipient about a "triggering
143
2.1. Notify Parameter "method"
145
The mailto notification mechanism uses standard mailto URIs as
146
specified in [mailto]. mailto URIs may contain header fields
147
consisting of a header name and value. These header fields are
148
called "URI headers" to distinguish them from "message headers".
150
2.2. Test notify_method_capability
152
The notify_method_capability test for "online" may return "yes" or
153
"no" only if the Sieve processor can determine with certainty whether
154
or not the recipients of the notification message are online and
155
logged in. Otherwise, the test returns "maybe" for this notification
158
2.3. Notify Tag ":from"
160
The ":from" tag overrides the default sender of the notification
161
message. "Sender", here, refers to the value used in the [RFC5322]
162
"From" header. Implementations MAY also use this value in the
163
[RFC5321] "MAIL FROM" command (the "envelope sender"), or they may
164
prefer to establish a mailbox that receives bounces from notification
170
Leiba & Haardt Standards Track [Page 3]
172
RFC 5436 Sieve Notification Mechanism: mailto January 2009
175
2.4. Notify Tag ":importance"
177
The ":importance" tag has no special meaning for this notification
178
mechanism, and this specification puts no restriction on its use.
179
Implementations MAY use the value of ":importance" to set a priority
180
or importance indication on the notification message (perhaps a
181
visual indication, or perhaps making use of one of the non-standard
182
but commonly used message headers).
184
2.5. Notify Tag ":options"
186
This tag is not used by the mailto method.
188
2.6. Notify Tag ":message"
190
The value of this tag, if it is present, is used as the subject of
191
the notification message, and overrides all other mechanisms for
192
determining the subject (as described below). Its value SHOULD NOT
193
normally be truncated, though it may be sensible to truncate an
194
excessively long value.
196
2.7. Other Definitions
198
Because the receipt of an email message is generating another email
199
message, implementations MUST take steps to avoid mail loops. The
200
REQUIRED inclusion of an "Auto-Submitted:" field, as described in the
201
message composition guidelines, will also help in loop detection and
204
Implementations SHOULD NOT trigger notifications for messages
205
containing "Auto-Submitted:" header fields with any value other than
208
Implementations MUST allow messages with empty envelope senders to
209
trigger notifications.
211
Because this notification method uses a store-and-forward system for
212
delivery of the notification message, the Sieve processor should not
213
have a need to retry notifications. Therefore, implementations of
214
this method SHOULD use normal mechanisms for submitting SMTP messages
215
and for retrying the initial submission. Once the notification
216
message is submitted, implementations MUST NOT resubmit it, as this
217
is likely to result in multiple notifications, and increases the
218
danger of message loops.
220
Implementations SHOULD consider limiting notification messages. In
221
particular, they SHOULD NOT sent duplicate notifications to the same
222
address from the same script invocation. Batching of notifications
226
Leiba & Haardt Standards Track [Page 4]
228
RFC 5436 Sieve Notification Mechanism: mailto January 2009
231
within a short time to the same address might also be useful.
232
Different implementations, different administrative domains, and
233
different users may have different needs; configuration options are a
236
The overall notification message is composed using the following
237
guidelines (see [RFC5322] for references to message header fields):
239
o If the envelope sender of the triggering message is empty, the
240
envelope sender of the notification message MUST be empty as well,
241
to avoid message loops. Otherwise, the envelope sender of the
242
notification message SHOULD be set to the value of the ":from" tag
243
to the notify action, if one is specified, has email address
244
syntax, and is valid according to the implementation-specific
245
security checks (see Section 3.3 of [Notify]). If ":from" is not
246
specified or is not valid, the envelope sender of the notification
247
message SHOULD be set either to the envelope "to" field from the
248
triggering message, as used by Sieve, or to an email address
249
associated with the notification system, at the discretion of the
250
implementation. This MUST NOT be overridden by a "from" URI
251
header, and any such URI header MUST be ignored.
253
o The envelope recipient(s) of the notification message SHOULD be
254
set to the address(es) specified in the URI (including any URI
255
headers where the hname is "to" or "cc").
257
o The header field "Auto-Submitted: auto-notified" MUST be included
258
in the notification message (see Section 2.7.1). This is to
259
reduce the likelihood of message loops, by tagging this as an
260
automatically generated message. Among other results, it will
261
inform other notification systems not to generate further
262
notifications. mailto URI headers with hname "auto-submitted" are
263
considered unsafe and MUST be ignored.
265
o The "From:" header field of the notification message SHOULD be set
266
to the value of the ":from" tag to the notify action, if one is
267
specified, has email address syntax, and is valid according to the
268
implementation-specific security checks (see Section 3.3 of
269
[Notify]). If ":from" is not specified or is not valid, the
270
"From:" header field of the notification message SHOULD be set
271
either to the envelope "to" field from the triggering message, as
272
used by Sieve, or to an email address associated with the
273
notification system, at the discretion of the implementation.
274
This MUST NOT be overridden by a "from" URI header, and any such
275
URI header MUST be ignored.
282
Leiba & Haardt Standards Track [Page 5]
284
RFC 5436 Sieve Notification Mechanism: mailto January 2009
287
o The "To:" header field of the notification message SHOULD be set
288
to the address(es) specified in the URI (including any URI headers
289
where the hname is "to").
291
o The "Subject:" field of the notification message SHOULD contain
292
the value defined by the ":message" tag, as described in [Notify].
293
If there is no ":message" tag and there is a "subject" header on
294
the URI, then that value SHOULD be used. If the "subject" header
295
is also absent, the subject SHOULD be retained from the triggering
296
message. Note that Sieve [Variables] can be used to advantage
297
here, as shown in the example in Section 3.
299
o The "References:" field of the notification message MAY be set to
300
refer to the triggering message, and MAY include references from
301
the triggering message.
303
o If the mailto URI contains a "body" header, the value of that
304
header SHOULD be used as the body of the notification message. If
305
there is no "body" header, it is up to the implementation whether
306
to leave the body empty or to use an excerpt of the original
309
o The "Received:" fields from the triggering message MAY be retained
310
in the notification message, as these could provide useful trace/
311
history/diagnostic information. The "Auto-Submitted" header field
312
MUST be placed above these (see Section 2.7.1). URI headers with
313
hname "received" are considered unsafe, and MUST be ignored.
315
o Other header fields of the notification message that are normally
316
related to an individual new message (such as "Message-ID" and
317
"Date") are generated for the notification message in the normal
318
manner, and MUST NOT be copied from the triggering message. Any
319
URI headers with those names MUST be ignored. Further, the "Date"
320
header serves as the notification timestamp defined in [Notify].
322
o All other header fields of the notification message either are as
323
specified by URI headers, or have implementation-specific values;
324
their values are not defined here. It is suggested that the
325
implementation capitalize the first letter of URI headers and add
326
a space character after the colon between the mail header name and
327
value when adding URI headers to the message, to be consistent
328
with common practice in email headers.
330
2.7.1. The Auto-Submitted Header Field
332
The header field "Auto-Submitted: auto-notified" MUST be included in
333
the notification message (see [RFC3834]). The "Auto-Submitted"
334
header field is considered a "trace field", similar to "Received"
338
Leiba & Haardt Standards Track [Page 6]
340
RFC 5436 Sieve Notification Mechanism: mailto January 2009
343
header fields (see [RFC5321]). If the implementation retains the
344
"Received" fields from the triggering message (see above), the "Auto-
345
Submitted" field MUST be placed above those "Received" fields,
346
serving as a boundary between the ones from the triggering message
347
and those that will be part of the notification message.
349
The header field "Auto-Submitted: auto-notified" MUST include one or
350
both of the following parameters:
352
o owner-email - specifies an email address, determined by the
353
implementation, of the owner of the Sieve script that generated
354
this notification. If specified, it might be used to identify or
355
contact the script's owner. The parameter attribute is "owner-
356
email", and the parameter value is a quoted string containing an
357
email address, as defined by "addr-spec" in [RFC5322]. Example:
358
Auto-Submitted: auto-notified; owner-email="me@example.com"
360
o owner-token - specifies an opaque token, determined by the
361
implementation, that the administrative domain of the owner of the
362
Sieve script that generated this notification can use to identify
363
the owner. This might be used to allow identification of the
364
owner while protecting the owner's privacy. The parameter
365
attribute is "owner-token", and the parameter value is as defined
366
by "token" in [RFC3834]. Example:
367
Auto-Submitted: auto-notified; owner-token=af3NN2pK5dDXI0W
369
See Section 5 for discussion of possible uses of these parameters.
373
Triggering message (received by recipient@example.org):
375
Return-Path: <knitting-bounces@example.com>
376
Received: from mail.example.com by mail.example.org
377
for <recipient@example.org>; Wed, 7 Dec 2005 05:08:02 -0500
378
Received: from hobbies.example.com by mail.example.com
379
for <knitting@example.com>; Wed, 7 Dec 2005 02:00:26 -0800
380
Message-ID: <1234567.89ABCDEF@example.com>
381
Date: Wed, 07 Dec 2005 10:59:19 +0100
383
List-Id: Knitting Mailing List <knitting.example.com>
384
Sender: knitting-bounces@example.com
385
Errors-To: knitting-bounces@example.com
386
From: "Jeff Smith" <jeff@hobbies.example.com>
387
To: "Knitting Mailing List" <knitting@example.com>
388
Subject: [Knitting] A new sweater
390
I just finished a great new sweater!
394
Leiba & Haardt Standards Track [Page 7]
396
RFC 5436 Sieve Notification Mechanism: mailto January 2009
399
Sieve script (run on behalf of recipient@example.org):
401
require ["enotify", "variables"];
403
if header :contains "list-id" "knitting.example.com" {
404
if header :matches "Subject" "[*] *" {
405
notify :message "From ${1} list: ${2}"
407
"mailto:0123456789@sms.example.net?to=backup@example.com";
412
Notification message:
414
Auto-Submitted: auto-notified; owner-email="recipient@example.org"
415
Received: from mail.example.com by mail.example.org
416
for <recipient@example.org>; Wed, 7 Dec 2005 05:08:02 -0500
417
Received: from hobbies.example.com by mail.example.com
418
for <knitting@example.com>; Wed, 7 Dec 2005 02:00:26 -0800
419
Date: Wed, 7 Dec 2005 05:08:55 -0500
420
Message-ID: <A2299BB.FF7788@example.org>
421
From: recipient@example.org
422
To: 0123456789@sms.example.net, backup@example.com
423
Subject: From Knitting list: A new sweater
427
o Fields such as "Message-ID:" and "Date:" were generated afresh for
428
the notification message, and do not relate to the triggering
431
o Additional "Received:" fields will be added to the notification
432
message in transit; the ones shown were copied from the triggering
433
message. New ones will be added above the Auto-Submitted: header
436
o If this message should appear at the mail.example.org server
437
again, the server can use the presence of a "mail.example.org"
438
received line to recognize that. The Auto-Submitted header field
439
is also present to tell the server to avoid sending another
440
notification, and it includes an optional owner-email parameter
443
4. Internationalization Considerations
445
This specification introduces no specific internationalization issues
446
that are not already addressed in [Sieve] and in [Notify].
450
Leiba & Haardt Standards Track [Page 8]
452
RFC 5436 Sieve Notification Mechanism: mailto January 2009
455
5. Security Considerations
457
Sending a notification is comparable with forwarding mail to the
458
notification recipient. Care must be taken when forwarding mail
459
automatically, to ensure that confidential information is not sent
460
into an insecure environment.
462
The automated sending of email messages exposes the system to mail
463
loops, which can cause operational problems. Implementations of this
464
specification MUST protect themselves against mail loops; see
465
Section 2.7 for discussion of this and some suggestions. Other
466
possible mitigations for mail loops involve types of service
467
limitations. For example, the number of notifications generated for
468
a single user might be limited to no more than, say, 30 in a
469
60-minute period. Of course, this technique presents its own
470
problems, in that the actual rate-limit must be selected carefully,
471
to allow most legitimate situations in the given environment. Even
472
with careful selection, it's inevitable that there will be false
473
positives -- and false negatives.
475
Ultimately, human intervention may be necessary to re-enable
476
notifications that have been disabled because a loop was detected, or
477
to terminate a very slow loop that's under the automatic-detection
478
radar. Administrative mechanisms MUST be available to handle these
481
Email addresses specified as recipients of notifications might not be
482
owned by the entity that owns the Sieve script. As a result, a
483
notification recipient could wind up as the target of unwanted
484
notifications, either through intent (using scripts to mount a mail-
485
bomb attack) or by accident (an address was mistyped or has been
486
reassigned). The situation is arguably no worse than any other in
487
which a recipient gets unwanted email, and some of the same
488
mechanisms can be used in this case. But those deploying this
489
extension have to be aware of the potential extra problems here,
490
where scripts might be created through means that do not adequately
491
validate email addresses, and such scripts might then be forgotten
492
and left to run indefinitely.
494
In particular, note that the Auto-Submitted header field is required
495
to include a value that a recipient can use when contacting the
496
source domain of the notification message (see Section 2.7.1). That
497
value will allow the domain to track down the script's owner and have
498
the script corrected or disabled. Domains that enable this extension
499
MUST be prepared to respond to such complaints, in order to limit the
500
damage caused by a faulty script.
506
Leiba & Haardt Standards Track [Page 9]
508
RFC 5436 Sieve Notification Mechanism: mailto January 2009
511
Problems can also show up if notification messages are sent to a
512
gateway into another service, such as SMS. Information from the
513
email message is often lost in the gateway translation; and in this
514
case, critical information needed to avoid loops, to contact the
515
script owner, and to resolve other problems might be lost.
516
Developers of email gateways should consider these issues, and try to
517
preserve as much information as possible, including what appears in
518
email trace headers and the Auto-Submitted header field.
520
Additional security considerations are discussed in [Sieve] and in
523
6. IANA Considerations
525
6.1. Registration of Notification Mechanism
527
The following template specifies the IANA registration of the Sieve
528
notification mechanism specified in this document:
531
Subject: Registration of new Sieve notification mechanism
532
Mechanism name: mailto
533
Mechanism URI: RFC2368
534
Mechanism-specific options: none
535
Permanent and readily available reference: RFC 5436
536
Person and email address to contact for further information:
537
Michael Haardt <michael.haardt@freenet.ag>
539
This information should be added to the list of Sieve notification
540
mechanisms available from http://www.iana.org.
542
6.2. New Registry for Auto-Submitted Header Field Keywords
544
Because [RFC3834] does not define a registry for new keywords used in
545
the Auto-Submitted header field, we define one here, which has been
546
created and is available from http://www.iana.org. Keywords are
547
registered using the "Specification Required" policy [IANA].
549
This defines the template to be used to register new keywords.
550
Initial entries to this registry follow in Section 6.3.
553
Subject: Registration of new auto-submitted header field keyword
554
Keyword value: [the text value of the field]
555
Description: [a brief explanation of the purpose of this value]
556
Parameters: [list any keyword-specific parameters, specify their
557
meanings, specify whether they are required or optional; use
558
"none" if there are none]
562
Leiba & Haardt Standards Track [Page 10]
564
RFC 5436 Sieve Notification Mechanism: mailto January 2009
567
Permanent and readily available reference: [identifies
568
the specification that defines the value being registered]
569
Contact: [name and email address to contact for further information]
571
6.3. Initial Registration of Auto-Submitted Header Field Keywords
573
The following are the initial keywords that have been registered in
574
the "Auto-Submitted Header Field Keywords" registry, available from
578
Description: Indicates that a message was NOT automatically
579
generated, but was created by a human. It is the equivalent to
580
the absence of an Auto-Submitted header altogether.
582
Permanent and readily available reference: RFC3834
583
Contact: Keith Moore <moore@network-heretics.com>
585
Keyword value: auto-generated
586
Description: Indicates that a message was generated by an automatic
587
process, and is not a direct response to another message.
589
Permanent and readily available reference: RFC3834
590
Contact: Keith Moore <moore@network-heretics.com>
592
Keyword value: auto-replied
593
Description: Indicates that a message was automatically generated as
594
a direct response to another message.
596
Permanent and readily available reference: RFC3834
597
Contact: Keith Moore <moore@network-heretics.com>
599
Keyword value: auto-notified
600
Description: Indicates that a message was generated by a Sieve
602
Parameters: owner-email, owner-token. At least one is required;
603
both refer to the owner of the Sieve script that generated this
604
message. See the relevant RFC for details.
605
Permanent and readily available reference: RFC 5436
606
Contact: Michael Haardt <michael.haardt@freenet.ag>
610
7.1. Normative References
612
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
613
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
618
Leiba & Haardt Standards Track [Page 11]
620
RFC 5436 Sieve Notification Mechanism: mailto January 2009
623
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate
624
Requirement Levels", BCP 14, RFC 2119, March 1997.
626
[Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
627
Martin, "Sieve Email Filtering: Extension for
628
Notifications", RFC 5435, January 2009.
630
[RFC3834] Moore, K., "Recommendations for Automatic Responses to
631
Electronic Mail", RFC 3834, August 2004.
633
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
636
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An
637
Email Filtering Language", RFC 5228, January 2008.
639
[mailto] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
640
URL scheme", RFC 2368, July 1998.
642
7.2. Informative References
644
[RFC5321] Klensin, J., Ed., "Simple Mail Transfer Protocol",
645
RFC 5321, October 2008.
647
[Variables] Homme, K., "Sieve Extension: Variables", RFC 5229,
653
IBM T.J. Watson Research Center
658
Phone: +1 914 784 7941
659
EMail: leiba@watson.ibm.com
665
Duesseldorf, NRW 40549
668
Phone: +49 241 53087 520
669
EMail: michael.haardt@freenet.ag
674
Leiba & Haardt Standards Track [Page 12]
added
removed
pigeonhole/doc/rfc/notify-mailto.rfc5436.txt
