← Back to branch summary

~ubuntu-dev/ubuntu/lucid/dovecot/lucid-201002101901

« back to all changes in this revision

Viewing changes to libsieve/doc/rfc/notify-mailto.rfc5436.txt

  • Committer: Chuck Short
  • Date: 2010-01-21 20:21:25 UTC
  • mfrom: (4.1.11 squeeze)
  • Revision ID: zulcss@ubuntu.com-20100121202125-pme73o491kfwj5nc
http://bugs.debian.org/493803
http://bugs.debian.org/523810
http://bugs.debian.org/545582
http://bugs.debian.org/549944
http://bugs.debian.org/554306
http://bugs.debian.org/554710
http://bugs.debian.org/557601
http://bugs.debian.org/558040
https://launchpad.net/bugs/164837
https://launchpad.net/bugs/254721
https://launchpad.net/bugs/329878
* Merge from debian testing, remaining changes:
  + Add new binary pkg dovecot-postfix that integrates postfix and dovecot
    automatically: (LP: #164837)
  + debian/control:
    - add new binary with short description
    - set Architecture all for dovecot-postfix (LP: #329878)
  + debian/dovecot-postfix.postinst:
    - create initial certificate symlinks to snakeoil.
    - set up postfix with postconf to:
      - use Maildir/ as the default mailbox.
      - use dovecot as the sasl authentication server.
      - use dovecot LDA (deliver).
      - use tls for smtp{d} services.
    - fix certificates paths in postfix' main.cf
    - add reject_unauth_destination to postfix' recipient restrictions
    - add reject_unknown_sender_domain to postfix' sender restriction
    - rename configuration name on remove, delete on purge
    - restart dovecot after linking certificates
    - handle use case when postfix is unconfigurated
  + debian/dovecot-postfix.dirs: create backup directory for postfix's config
    configuration
  + restart postfix and dovecot.
  + debian/dovecot-postfix.postrm:
    - remove all dovecot related configuration from postfix.
    - restart postfix and dovecot.
  + debian/dovecot-common.init:
    - check if /etc/dovecot/dovecot-postfix.conf exists and use it
      as the configuration file if so.
  + debian/patches/warning-ubuntu-postfix.dpatch
    - add warning about dovecot-postfix.conf in dovecot default
      configuration file
  + debian/patches/dovecot-postfix.conf.diff:
    - Ubuntu server custom changes to the default dovecot configuration for
      better interfation with postfix.
    - enable sieve plugin.
    - Ubuntu server custom changes to the default dovecot configuration for
      better integration with postfix:
      - enable imap, pop3, imaps, pop3s and managesieve by default.
      - enable dovecot LDA (deliver).
      - enable SASL auth socket in postfix private directory
   + debian/rules:
     - copy, patch and install dovecot-postfix.conf in /etc/dovecot/.
     - build architecure independent packages too
   + Use Snakeoil SSL certificates by default.
     - debian/control: Depend on ssl-cert.
     - debian/patches/ssl-cert-snakeoil.dpatch: Change default SSL cert
       paths to snakeoil.
     - debian/dovecot-common.postinst: Relax grep for SSL_* a bit.
   + Add autopkgtest to debian/tests/*.
   + Fast TearDown: Update the lsb init header to not stop in level 6.
   + Add ufw integration:
     - Created debian/dovecot-common.ufw.profile.
     - debian/rules: install profile.
     - debian/control: suggest ufw.
   + debian/{control,rules}: enable PIE hardening.
   + dovecot-imapd, dovecot-pop3: Replaces dovecot-common (<< 1:1.1). (LP: #254721)
   + debian/control: Update Vcs-* headers.
   + Add SMTP-AUTH support for Outlook (login auth mechanism)
* New upstream release.
* debian/patches/gold-fix.patch: Removed. Fixed upstream.
* Moved libexec to lib corrections in dovecot-managesieve.patch and
  dovecot-managesieve-dist.patch to dovecot-example.patch
* debian/patches/dovecot-mboxlocking.patch: Regenerated to avoid FTBFS
  when quilt isn't installed.
* debian/patches/quota-mountpoint.patch: Removed. Not needed anymore.
* debian/patches/dovecot-quota.patch: Removed. Quotas aren't properly
  enabled unless mail_plugins = quota imap_quota.
* debian/patches/gold-fix.patch: Fixed configure script to build even
  with binutils-gold or --no-add-needed linker flag (Closes: #554306)
* debian/dovecot-common.init: fixed LSB headers. Thanks to Pascal Volk.
  (Closes: #558040)
* debian/changelog: added CVE references to previous changelog entry.
* debian/rules: checked up the build system. It's not fragile anymore.
  (Closes: 493803)
* debian/dovecot-common.postinst: Now invoking dpkg-reconfigure
  on dovecot-common is enough to generate new certificates
  if the previous ones were removed. (Closes: #545582)
* debian/rules: No longer install convert-tool in /usr/bin.
  It isn't an user utility and it should stay in /usr/lib/dovecot
  like all other similar tool.
* New upstream release. (Closes: #557601)
* [SECURITY] Fixes local information disclosure and denial of service.
  (see: http://www.dovecot.org/list/dovecot-news/2009-November/000143.html
  and CVE-2009-3897)
* Added myself to uploaders.
* Switched to the new source format "3.0 (quilt)":
  - removed dpatch from build-depends
  - removed debian/README.source because now we use only standard
    dpkg features
  - regenerated all patches
* Prepared to switch to multi-origin source:
  - recreated dovecot-libsieve.patch and dovecot-managesieve-dist.patch
    starting from the upstream tarball
  - removed all autotools related build-depends and build-conflict
  - renamed dovecot-libsieve and dovecot-managesieve directories
    to libsieve and managesieve.
* debian/rules: Moved the configuration of libsieve and managesieve from
  the build phase to the configuration phase
* Added dovecot-dbg package  with debugging symbols.  Thanks Stephan Bosch.
  (Closes: #554710)
* Fixed some stray libexec'isms in the default configuration.
* New upstream release.
* debian/dovecot-common.init:
  - use $CONF when starting the daemon. (Closes: #549944)
  - always output start/stop messages. (Closes: #523810)

Show diffs side-by-side

added added

removed removed

Lines of Context:
libsieve/doc/rfc/notify-mailto.rfc5436.txt
 
1
 
 
2
 
 
3
 
 
4
 
 
5
 
 
6
 
 
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
 
11
                                                            January 2009
 
12
 
 
13
 
 
14
                  Sieve Notification Mechanism: mailto
 
15
 
 
16
Status of This Memo
 
17
 
 
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.
 
23
 
 
24
Copyright Notice
 
25
 
 
26
   Copyright (c) 2009 IETF Trust and the persons identified as the
 
27
   document authors.  All rights reserved.
 
28
 
 
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.
 
34
 
 
35
Abstract
 
36
 
 
37
   This document describes a profile of the Sieve extension for
 
38
   notifications, to allow notifications to be sent by electronic mail.
 
39
 
 
40
 
 
41
 
 
42
 
 
43
 
 
44
 
 
45
 
 
46
 
 
47
 
 
48
 
 
49
 
 
50
 
 
51
 
 
52
 
 
53
 
 
54
 
 
55
 
 
56
 
 
57
 
 
58
Leiba & Haardt              Standards Track                     [Page 1]
 
59
 
 
60
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
61
 
 
62
 
 
63
Table of Contents
 
64
 
 
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
 
88
 
 
89
 
 
90
 
 
91
 
 
92
 
 
93
 
 
94
 
 
95
 
 
96
 
 
97
 
 
98
 
 
99
 
 
100
 
 
101
 
 
102
 
 
103
 
 
104
 
 
105
 
 
106
 
 
107
 
 
108
 
 
109
 
 
110
 
 
111
 
 
112
 
 
113
 
 
114
Leiba & Haardt              Standards Track                     [Page 2]
 
115
 
 
116
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
117
 
 
118
 
 
119
1.  Introduction
 
120
 
 
121
1.1.  Overview
 
122
 
 
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.
 
127
 
 
128
1.2.  Conventions Used in This Document
 
129
 
 
130
   Conventions for notations are as in Section 1.1 of [Sieve], including
 
131
   the use of [Kwds].
 
132
 
 
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].
 
136
 
 
137
2.  Definition
 
138
 
 
139
   The mailto mechanism results in the sending of a new email message (a
 
140
   "notification message") to notify a recipient about a "triggering
 
141
   message".
 
142
 
 
143
2.1.  Notify Parameter "method"
 
144
 
 
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".
 
149
 
 
150
2.2.  Test notify_method_capability
 
151
 
 
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
 
156
   method.
 
157
 
 
158
2.3.  Notify Tag ":from"
 
159
 
 
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
 
165
   messages.
 
166
 
 
167
 
 
168
 
 
169
 
 
170
Leiba & Haardt              Standards Track                     [Page 3]
 
171
 
 
172
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
173
 
 
174
 
 
175
2.4.  Notify Tag ":importance"
 
176
 
 
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).
 
183
 
 
184
2.5.  Notify Tag ":options"
 
185
 
 
186
   This tag is not used by the mailto method.
 
187
 
 
188
2.6.  Notify Tag ":message"
 
189
 
 
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.
 
195
 
 
196
2.7.  Other Definitions
 
197
 
 
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
 
202
   avoidance.
 
203
 
 
204
   Implementations SHOULD NOT trigger notifications for messages
 
205
   containing "Auto-Submitted:" header fields with any value other than
 
206
   "No".
 
207
 
 
208
   Implementations MUST allow messages with empty envelope senders to
 
209
   trigger notifications.
 
210
 
 
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.
 
219
 
 
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
 
223
 
 
224
 
 
225
 
 
226
Leiba & Haardt              Standards Track                     [Page 4]
 
227
 
 
228
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
229
 
 
230
 
 
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
 
234
   good idea here.
 
235
 
 
236
   The overall notification message is composed using the following
 
237
   guidelines (see [RFC5322] for references to message header fields):
 
238
 
 
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.
 
252
 
 
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").
 
256
 
 
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.
 
264
 
 
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.
 
276
 
 
277
 
 
278
 
 
279
 
 
280
 
 
281
 
 
282
Leiba & Haardt              Standards Track                     [Page 5]
 
283
 
 
284
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
285
 
 
286
 
 
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").
 
290
 
 
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.
 
298
 
 
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.
 
302
 
 
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
 
307
      message.
 
308
 
 
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.
 
314
 
 
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].
 
321
 
 
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.
 
329
 
 
330
2.7.1.  The Auto-Submitted Header Field
 
331
 
 
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"
 
335
 
 
336
 
 
337
 
 
338
Leiba & Haardt              Standards Track                     [Page 6]
 
339
 
 
340
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
341
 
 
342
 
 
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.
 
348
 
 
349
   The header field "Auto-Submitted: auto-notified" MUST include one or
 
350
   both of the following parameters:
 
351
 
 
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"
 
359
 
 
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
 
368
 
 
369
   See Section 5 for discussion of possible uses of these parameters.
 
370
 
 
371
3.  Examples
 
372
 
 
373
   Triggering message (received by recipient@example.org):
 
374
 
 
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
 
382
      Precedence: list
 
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
 
389
 
 
390
      I just finished a great new sweater!
 
391
 
 
392
 
 
393
 
 
394
Leiba & Haardt              Standards Track                     [Page 7]
 
395
 
 
396
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
397
 
 
398
 
 
399
   Sieve script (run on behalf of recipient@example.org):
 
400
 
 
401
      require ["enotify", "variables"];
 
402
 
 
403
      if header :contains "list-id" "knitting.example.com" {
 
404
        if header :matches "Subject" "[*] *" {
 
405
          notify :message "From ${1} list: ${2}"
 
406
              :importance "3"
 
407
              "mailto:0123456789@sms.example.net?to=backup@example.com";
 
408
        }
 
409
      }
 
410
 
 
411
 
 
412
   Notification message:
 
413
 
 
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
 
424
 
 
425
   Note that:
 
426
 
 
427
   o  Fields such as "Message-ID:" and "Date:" were generated afresh for
 
428
      the notification message, and do not relate to the triggering
 
429
      message.
 
430
 
 
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
 
434
      field.
 
435
 
 
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
 
441
      for identification.
 
442
 
 
443
4.  Internationalization Considerations
 
444
 
 
445
   This specification introduces no specific internationalization issues
 
446
   that are not already addressed in [Sieve] and in [Notify].
 
447
 
 
448
 
 
449
 
 
450
Leiba & Haardt              Standards Track                     [Page 8]
 
451
 
 
452
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
453
 
 
454
 
 
455
5.  Security Considerations
 
456
 
 
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.
 
461
 
 
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.
 
474
 
 
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
 
479
   sorts of situations.
 
480
 
 
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.
 
493
 
 
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.
 
501
 
 
502
 
 
503
 
 
504
 
 
505
 
 
506
Leiba & Haardt              Standards Track                     [Page 9]
 
507
 
 
508
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
509
 
 
510
 
 
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.
 
519
 
 
520
   Additional security considerations are discussed in [Sieve] and in
 
521
   [Notify].
 
522
 
 
523
6.  IANA Considerations
 
524
 
 
525
6.1.  Registration of Notification Mechanism
 
526
 
 
527
   The following template specifies the IANA registration of the Sieve
 
528
   notification mechanism specified in this document:
 
529
 
 
530
   To: iana@iana.org
 
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>
 
538
 
 
539
   This information should be added to the list of Sieve notification
 
540
   mechanisms available from http://www.iana.org.
 
541
 
 
542
6.2.  New Registry for Auto-Submitted Header Field Keywords
 
543
 
 
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].
 
548
 
 
549
   This defines the template to be used to register new keywords.
 
550
   Initial entries to this registry follow in Section 6.3.
 
551
 
 
552
   To: iana@iana.org
 
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]
 
559
 
 
560
 
 
561
 
 
562
Leiba & Haardt              Standards Track                    [Page 10]
 
563
 
 
564
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
565
 
 
566
 
 
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]
 
570
 
 
571
6.3.  Initial Registration of Auto-Submitted Header Field Keywords
 
572
 
 
573
   The following are the initial keywords that have been registered in
 
574
   the "Auto-Submitted Header Field Keywords" registry, available from
 
575
   http://www.iana.org.
 
576
 
 
577
   Keyword value: no
 
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.
 
581
   Parameters: none
 
582
   Permanent and readily available reference: RFC3834
 
583
   Contact: Keith Moore <moore@network-heretics.com>
 
584
 
 
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.
 
588
   Parameters: none
 
589
   Permanent and readily available reference: RFC3834
 
590
   Contact: Keith Moore <moore@network-heretics.com>
 
591
 
 
592
   Keyword value: auto-replied
 
593
   Description: Indicates that a message was automatically generated as
 
594
      a direct response to another message.
 
595
   Parameters: none
 
596
   Permanent and readily available reference: RFC3834
 
597
   Contact: Keith Moore <moore@network-heretics.com>
 
598
 
 
599
   Keyword value: auto-notified
 
600
   Description: Indicates that a message was generated by a Sieve
 
601
      notification system.
 
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>
 
607
 
 
608
7.  References
 
609
 
 
610
7.1.  Normative References
 
611
 
 
612
   [IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an
 
613
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
 
614
                May 2008.
 
615
 
 
616
 
 
617
 
 
618
Leiba & Haardt              Standards Track                    [Page 11]
 
619
 
 
620
RFC 5436          Sieve Notification Mechanism: mailto      January 2009
 
621
 
 
622
 
 
623
   [Kwds]       Bradner, S., "Key words for use in RFCs to Indicate
 
624
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 
625
 
 
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.
 
629
 
 
630
   [RFC3834]    Moore, K., "Recommendations for Automatic Responses to
 
631
                Electronic Mail", RFC 3834, August 2004.
 
632
 
 
633
   [RFC5322]    Resnick, P., Ed., "Internet Message Format", RFC 5322,
 
634
                October 2008.
 
635
 
 
636
   [Sieve]      Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An
 
637
                Email Filtering Language", RFC 5228, January 2008.
 
638
 
 
639
   [mailto]     Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
 
640
                URL scheme", RFC 2368, July 1998.
 
641
 
 
642
7.2.  Informative References
 
643
 
 
644
   [RFC5321]    Klensin, J., Ed., "Simple Mail Transfer Protocol",
 
645
                RFC 5321, October 2008.
 
646
 
 
647
   [Variables]  Homme, K., "Sieve Extension: Variables", RFC 5229,
 
648
                January 2008.
 
649
 
 
650
Authors' Addresses
 
651
 
 
652
   Barry Leiba
 
653
   IBM T.J. Watson Research Center
 
654
   19 Skyline Drive
 
655
   Hawthorne, NY  10532
 
656
   US
 
657
 
 
658
   Phone: +1 914 784 7941
 
659
   EMail: leiba@watson.ibm.com
 
660
 
 
661
 
 
662
   Michael Haardt
 
663
   freenet.de GmbH
 
664
   Willstaetter Str. 13
 
665
   Duesseldorf, NRW  40549
 
666
   Germany
 
667
 
 
668
   Phone: +49 241 53087 520
 
669
   EMail: michael.haardt@freenet.ag
 
670
 
 
671
 
 
672
 
 
673
 
 
674
Leiba & Haardt              Standards Track                    [Page 12]
 
675