← Back to branch summary

~ubuntu-branches/ubuntu/utopic/dovecot/utopic

« back to all changes in this revision

Viewing changes to pigeonhole/doc/rfc/copy.rfc3894.txt

  • Committer: Package Import Robot
  • Author(s): James Page, James Page, Ante Karamatic
  • Date: 2013-02-11 12:41:24 UTC
  • mfrom: (4.1.33 sid)
  • Revision ID: package-import@ubuntu.com-20130211124124-v7bdegzftlhw7yfr
Tags: 1:2.1.7-7ubuntu1
https://launchpad.net/bugs/1117613
https://launchpad.net/bugs/1075456
https://launchpad.net/bugs/671065
[ James Page ]
* Merge from Debian unstable (LP: #1117613, #1075456), remaining changes:
  + Add mail-stack-delivery package:
    - Update d/rules
    - d/control: convert existing dovecot-postfix package to a dummy
      package and add new mail-stack-delivery package.
    - Update maintainer scripts.
    - Rename d/dovecot-postfix.* to debian/mail-stack-delivery.*
    - d/mail-stack-delivery.preinst: Move previously installed backups and
      config files to a new package namespace.
    - d/mail-stack-delivery.prerm: Added to handle downgrades.
  + Use Snakeoil SSL certificates by default:
    - d/control: Depend on ssl-cert.
    - d/dovecot-core.postinst: Relax grep for SSL_* a bit.
  + Add autopkgtest to debian/tests/*.
  + Add ufw integration:
    - d/dovecot-core.ufw.profile: new ufw profile.
    - d/rules: install profile in dovecot-core.
    - d/control: dovecot-core - suggest ufw.
  + d/dovecot-core.dirs: Added usr/share/doc/dovecot-core
  + Add apport hook:
    - d/rules, d/source_dovecot.py
  + Add upstart job:
    - d/rules, d/dovecot-core.dovecot.upstart, d/control,
      d/dovecot-core.dirs, dovecot-imapd.{postrm, postinst, prerm},
      d/dovecot-pop3d.{postinst, postrm, prerm}.
      d/mail-stack-deliver.postinst: Convert init script to upstart.
  + d/control: Added Pre-Depends: dpkg (>= 1.15.6) to dovecot-dbg to support
    xz compression in Ubuntu.
  + d/control: Demote dovecot-common Recommends: to Suggests: to prevent
    install of extra packages on upgrade.
  + d/patches/dovecot-drac.patch: Updated with version for dovecot >= 2.0.0.
* Dropped changes, included in Debian:
  + d/{control,rules}: enable PIE hardening.
  + d/control: Drop B-D on systemd.
* d/p/mail-stack-delivery.postinst: Updated to ensure that configured SSL
  cert and key locations are used when configuring postfix, sorted out
  formatting.
* d/p/dovecot-core.postinst: Create compat links to old style, existing
  SSL cert and key if found.
* d/rules: Don't pass hardening flags for DRAC plugin.
* d/dovecot-{pop3d,imapd}.prerm: Re-sync with Debian.
* d/dovecot-core.lintian-overrides: Drop override for DRAC plugin as not
  required in Ubuntu.
* d/01-mail-stack-delivery: Renamed 99-mail-stack-delivery to ensure that
  the mail-stack-delivery configuration overrides configuration options
  set elsewhere, updated with new cert/key file locations.

[ Ante Karamatic ]
* Change configuration file for LDA on new installs and upgrades
  (LP: #671065).

Show diffs side-by-side

added added

removed removed

Lines of Context:
pigeonhole/doc/rfc/copy.rfc3894.txt
1
 
 
2
 
 
3
 
 
4
 
 
5
 
 
6
 
 
7
 
Network Working Group                                         J. Degener
8
 
Request for Comments: 3894                                Sendmail, Inc.
9
 
Category: Standards Track                                   October 2004
10
 
 
11
 
 
12
 
             Sieve Extension: Copying Without Side Effects
13
 
 
14
 
Status of this Memo
15
 
 
16
 
   This document specifies an Internet standards track protocol for the
17
 
   Internet community, and requests discussion and suggestions for
18
 
   improvements.  Please refer to the current edition of the "Internet
19
 
   Official Protocol Standards" (STD 1) for the standardization state
20
 
   and status of this protocol.  Distribution of this memo is unlimited.
21
 
 
22
 
Copyright Notice
23
 
 
24
 
   Copyright (C) The Internet Society (2004).
25
 
 
26
 
Abstract
27
 
 
28
 
   The Sieve scripting language allows users to control handling and
29
 
   disposal of their incoming e-mail.  By default, an e-mail message
30
 
   that is processed by a Sieve script is saved in the owner's "inbox".
31
 
   Actions such as "fileinto" and "redirect" cancel this default
32
 
   behavior.
33
 
 
34
 
   This document defines a new keyword parameter, ":copy", to be used
35
 
   with the Sieve "fileinto" and "redirect" actions.  Adding ":copy" to
36
 
   an action suppresses cancellation of the default "inbox" save.  It
37
 
   allows users to add commands to an existing script without changing
38
 
   the meaning of the rest of the script.
39
 
 
40
 
1.  Introduction
41
 
 
42
 
   The Sieve scripting language [SIEVE] allows users to control handling
43
 
   and disposal of their incoming e-mail.  Two frequently used Sieve
44
 
   commands are "fileinto" (saving into a local message store, such as
45
 
   an IMAP server) and "redirect" (forwarding to another e-mail
46
 
   address).  Both of these cancel the Sieve default behavior of saving
47
 
   into the user's "inbox".
48
 
 
49
 
   But some users have the notion of forwarding an extra copy of a
50
 
   message for safekeeping to another e-mail address, or of saving a
51
 
   copy in a folder - in addition to the regular message delivery, which
52
 
   shouldn't be affected by the copy.
53
 
 
54
 
 
55
 
 
56
 
 
57
 
 
58
 
Degener                     Standards Track                     [Page 1]
59
 
 
60
 
RFC 3894      Sieve Extension - Copy Without Side Effects   October 2004
61
 
 
62
 
 
63
 
   If saving an extra copy is all the user wanted to do,
64
 
 
65
 
      fileinto "unfiltered";
66
 
      keep;
67
 
 
68
 
   would do the job.  The "keep" command does explicitly what the
69
 
   cancelled default behavior did.  But the explicit "keep" is a poor
70
 
   substitute for the implicit "keep" when more processing follows:
71
 
 
72
 
      fileinto "unfiltered";
73
 
      keep;
74
 
 
75
 
      if header "Subject" "MAKE MONEY FAST!!!"
76
 
      {
77
 
              discard;
78
 
      }
79
 
 
80
 
   In this example, the "discard" is ineffective against the explicit
81
 
   "keep"; the discarded message still ends up in the user's inbox.
82
 
 
83
 
   It is possible to generate Sieve code that perfectly expresses a
84
 
   user's wishes, but such code quickly grows unwieldy because it needs
85
 
   to keep track of the state that the implicit "keep" would have had
86
 
   without the "fileinto" or "redirect" command.
87
 
 
88
 
   This extension tries to make life easier for user interface designers
89
 
   and script writers by allowing them to express the "copy" semantics
90
 
   directly.
91
 
 
92
 
2.  Conventions used
93
 
 
94
 
   Conventions for notations are as in [SIEVE] section 1.1, including
95
 
   use of [KEYWORDS] and "Syntax:" label for the definition of action
96
 
   and tagged arguments syntax.
97
 
 
98
 
   The capability string associated with extension defined in this
99
 
   document is "copy".
100
 
 
101
 
3.  ":copy" extension to the "fileinto" and "redirect" commands
102
 
 
103
 
   Syntax:
104
 
        "fileinto" [":copy"] <folder: string>
105
 
        "redirect" [":copy"] <address: string>
106
 
 
107
 
   If the optional ":copy" keyword is specified with "fileinto" or
108
 
   "redirect", the tagged command does not cancel the implicit "keep".
109
 
   Instead, it merely files or redirects a copy in addition to whatever
110
 
   else is happening to the message.
111
 
 
112
 
 
113
 
 
114
 
Degener                     Standards Track                     [Page 2]
115
 
 
116
 
RFC 3894      Sieve Extension - Copy Without Side Effects   October 2004
117
 
 
118
 
 
119
 
   Example:
120
 
 
121
 
      require ["copy", "fileinto"];
122
 
      fileinto :copy "incoming";
123
 
 
124
 
      # ... more processing follows ...
125
 
 
126
 
4.  Security Considerations
127
 
 
128
 
   The "copy" extension makes it easier to eavesdrop on a user's message
129
 
   stream without the user noticing.  This was technically possible
130
 
   before if an attacker gained read/write access to a user's Sieve
131
 
   scripts, but now an attacker no longer needs to parse a script in
132
 
   order to modify it.  Write access to Sieve scripts must be protected
133
 
   as strongly as read/write access to e-mail, for example by using
134
 
   secure directory protocols such as correctly parameterized LDAP over
135
 
   TLS [LDAP].
136
 
 
137
 
   Organizations that wish to monitor their users' e-mail traffic must
138
 
   familiarize themselves with local data protection laws before
139
 
   creating stores of old e-mail traffic without control, or perhaps
140
 
   even knowledge, of the sender or intended recipients.
141
 
 
142
 
   Organizations that legally use "redirect :copy" to eavesdrop on
143
 
   correspondence (for example, by keeping a log to answer questions
144
 
   about insider trading at a later time) can avoid future problems by
145
 
   setting users' privacy expectations correctly.
146
 
 
147
 
5.  IANA Considerations
148
 
 
149
 
   The following template specifies the IANA registration of the "copy"
150
 
   Sieve extension specified in this document.
151
 
 
152
 
   To: iana@iana.org
153
 
   Subject: Registration of new Sieve extension
154
 
 
155
 
   Capability name: copy
156
 
   Capability keyword: copy
157
 
   Capability arguments: N/A
158
 
   Standards Track: RFC 3894
159
 
   Person and email address to contact for further information:
160
 
 
161
 
      Jutta Degener
162
 
      Sendmail, Inc.
163
 
      6425 Christie Ave, 4th Floor
164
 
      Emeryville, CA 94608
165
 
 
166
 
      Email: jutta@sendmail.com
167
 
 
168
 
 
169
 
 
170
 
Degener                     Standards Track                     [Page 3]
171
 
 
172
 
RFC 3894      Sieve Extension - Copy Without Side Effects   October 2004
173
 
 
174
 
 
175
 
   This information has been added to the list of Sieve extensions given
176
 
   on http://www.iana.org/assignments/sieve-extensions.
177
 
 
178
 
6.  Acknowledgments
179
 
 
180
 
   Thanks to Eric Allman, Ned Freed, Will Lee, Nigel Swinson, and Rand
181
 
   Wacker for corrections and comments.
182
 
 
183
 
7.  References
184
 
 
185
 
7.1.  Normative References
186
 
 
187
 
   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
188
 
              Requirement Levels", BCP 14, RFC 2119, March 1997.
189
 
 
190
 
   [SIEVE]    Showalter, T., "Sieve: A Mail Filtering Language", RFC
191
 
              3028, January 2001.
192
 
 
193
 
7.2.  Informative References
194
 
 
195
 
   [LDAP]     Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
196
 
              "Authentication Methods for LDAP", RFC 2829, May 2000.
197
 
 
198
 
Author's Address
199
 
 
200
 
   Jutta Degener
201
 
   Sendmail, Inc.
202
 
   6425 Christie Ave, 4th Floor
203
 
   Emeryville, CA 94608
204
 
 
205
 
   EMail: jutta@sendmail.com
206
 
 
207
 
 
208
 
 
209
 
 
210
 
 
211
 
 
212
 
 
213
 
 
214
 
 
215
 
 
216
 
 
217
 
 
218
 
 
219
 
 
220
 
 
221
 
 
222
 
 
223
 
 
224
 
 
225
 
 
226
 
Degener                     Standards Track                     [Page 4]
227
 
 
228
 
RFC 3894      Sieve Extension - Copy Without Side Effects   October 2004
229
 
 
230
 
 
231
 
Full Copyright Statement
232
 
 
233
 
   Copyright (C) The Internet Society (2004).
234
 
 
235
 
   This document is subject to the rights, licenses and restrictions
236
 
   contained in BCP 78, and except as set forth therein, the authors
237
 
   retain all their rights.
238
 
 
239
 
   This document and the information contained herein are provided on an
240
 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
241
 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
242
 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
243
 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
244
 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
245
 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
246
 
 
247
 
Intellectual Property
248
 
 
249
 
   The IETF takes no position regarding the validity or scope of any
250
 
   Intellectual Property Rights or other rights that might be claimed to
251
 
   pertain to the implementation or use of the technology described in
252
 
   this document or the extent to which any license under such rights
253
 
   might or might not be available; nor does it represent that it has
254
 
   made any independent effort to identify any such rights.  Information
255
 
   on the IETF's procedures with respect to rights in IETF Documents can
256
 
   be found in BCP 78 and BCP 79.
257
 
 
258
 
   Copies of IPR disclosures made to the IETF Secretariat and any
259
 
   assurances of licenses to be made available, or the result of an
260
 
   attempt made to obtain a general license or permission for the use of
261
 
   such proprietary rights by implementers or users of this
262
 
   specification can be obtained from the IETF on-line IPR repository at
263
 
   http://www.ietf.org/ipr.
264
 
 
265
 
   The IETF invites any interested party to bring to its attention any
266
 
   copyrights, patents or patent applications, or other proprietary
267
 
   rights that may cover technology that may be required to implement
268
 
   this standard.  Please address the information to the IETF at ietf-
269
 
   ipr@ietf.org.
270
 
 
271
 
Acknowledgement
272
 
 
273
 
   Funding for the RFC Editor function is currently provided by the
274
 
   Internet Society.
275
 
 
276
 
 
277
 
 
278
 
 
279
 
 
280
 
 
281
 
 
282
 
Degener                     Standards Track                     [Page 5]
283