1
2
3
4
5
6
7Network Working Group N. Freed
8Request for Comments: 5183 Sun Microsystems
9Category: Standards Track May 2008
10
11
12 Sieve Email Filtering: Environment Extension
13
14Status 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
22Abstract
23
24 This document describes the "environment" extension to the Sieve
25 email filtering language. The "environment" extension gives a Sieve
26 script access to information about the Sieve interpreter itself,
27 where it is running, and about any transport connection currently
28 involved in transferring the message.
29
301. Introduction
31
32 Sieve [RFC5228] is a language for filtering email messages at or
33 around the time of final delivery. It is designed to be
34 implementable on either a mail client or mail server. It is suitable
35 for running on a mail server where users may not be allowed to
36 execute arbitrary programs, such as on black box Internet Message
37 Access Protocol [RFC3501] servers, as it has no user-controlled loops
38 or the ability to run external programs.
39
40 Although Sieve is intended to be independent of access protocol, mail
41 architecture, and operating system, in some cases it is useful to
42 allow scripts to access information about their execution context.
43 The "environment" extension provides a new environment test that can
44 be used to implement scripts that behave differently when moved from
45 one system to another, when messages arrive from different remote
46 sources or when otherwise operated in different contexts.
47
482. Conventions Used in This Document
49
50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
52 document are to be interpreted as described in [RFC2119].
53
54
55
56
57
58Freed Standards Track [Page 1]
59
60RFC 5183 Sieve Environment Extension May 2008
61
62
63 The terms used to describe the various components of the Sieve
64 language are taken from Section 1.1 of [RFC5228].
65
66 This document refers to the ABNF productions IPv4-address-literal,
67 IPv6-address-literal, and General-address-literal defined in Section
68 4.1.3 of [RFC2821].
69
70 The location item makes use of standard terms for email service
71 components. Additional information and background on these terms can
72 be found in [EMAIL-ARCH].
73
743. Capability Identifiers
75
76 The capability string associated with the extension defined in this
77 document is "environment".
78
794. Environment Test
80
81 Usage: environment [COMPARATOR] [MATCH-TYPE]
82 <name: string>
83 <key-list: string-list>
84
85 The environment test retrieves the item of environment information
86 specified by the name string and matches it to the values specified
87 in the key-list argument. The test succeeds if a match occurs. The
88 type of match defaults to ":is" and the default comparator is
89 "i;ascii-casemap".
90
91 The current message is not a direct source of information for the
92 environment test; the item of information specified by the name
93 string is extracted from the script's operating environment and the
94 key-list argument comes from the script.
95
96 The environment test MUST fail unconditionally if the specified
97 information item does not exist. A script MUST NOT fail with an
98 error if the item does not exist. This allows scripts to be written
99 that handle nonexistent items gracefully. In particular, the test:
100
101 if environment :contains "item" "" { ... }
102
103 only succeeds if "item" is known to the implementation, and always
104 succeeds if it is.
105
106 The "relational" extension [RFC5231] adds a match type called
107 ":count". The count of an environment test is 0 if the environment
108 information returned is the empty string, or 1 otherwise.
109
110
111
112
113
114Freed Standards Track [Page 2]
115
116RFC 5183 Sieve Environment Extension May 2008
117
118
119 Environment items can be standardized or vendor-defined. An IANA
120 registry is defined for both types of items. Extensions designed for
121 interoperable use SHOULD be defined in standards track or
122 experimental RFCs.
123
1244.1. Initial Standard Environment Items
125
126 The initial set of standardized environment items is as follows:
127
128 "domain" => The primary DNS domain associated with the Sieve
129 execution context, usually but not always a proper
130 suffix of the host name.
131
132 "host" => The fully-qualified domain name of the host where
133 the Sieve script is executing.
134
135 "location"
136 => Sieve evaluation can be performed at various
137 different points as messages are processed. This item
138 provides additional information about the type of
139 service that is evaluating the script. Possible values
140 are "MTA", meaning the Sieve is being evaluated by a
141 Message Transfer Agent, "MDA", meaning evaluation is
142 being performed by a Mail Delivery Agent, "MUA",
143 meaning evaluation is being performed by a Mail User
144 Agent, and "MS", meaning evaluation is being performed
145 by a Message Store. Additional information and
146 background on these terms can be found in
147 [EMAIL-ARCH].
148
149 "name" => The product name associated with the Sieve interpreter.
150
151 "phase" => The point relative to final delivery where the
152 Sieve script is being evaluated. Possible values are
153 "pre", "during", and "post", referring respectively to
154 processing before, during, and after final delivery
155 has taken place.
156
157 "remote-host"
158 => Host name of remote SMTP/LMTP/Submission client
159 expressed as a Fully Qualified Domain Name (FQDN),
160 if applicable and available. The empty string will be
161 returned if for some reason this information cannot be
162 obtained for the current client.
163
164
165
166
167
168
169
170Freed Standards Track [Page 3]
171
172RFC 5183 Sieve Environment Extension May 2008
173
174
175 "remote-ip"
176 => IP address of remote SMTP/LMTP/Submission client, if
177 applicable and available. IPv4, IPv6, and other types
178 of addresses are respectively represented in the
179 formats defined by the IPv4-address-literal,
180 IPv6-address-literal, and General-address-literal
181 productions defined in Section 4.1.3 of [RFC2821].
182
183 "version" => The product version associated with the Sieve
184 interpreter. The meaning of the product version string
185 is product-specific and should always be considered
186 in the context of the product name given by the
187 "name" item.
188
189 Implementations SHOULD support as many of the items on this initial
190 list as possible. Additional standardized items can only be defined
191 in standards-track or experimental RFCs.
192
1934.2. Vendor-defined Environment Items
194
195 Environment item names beginning with "vnd." represent vendor-defined
196 extensions. Such extensions are not defined by Internet standards or
197 RFCs, but are still registered with IANA in order to prevent
198 conflicts.
199
2004.3. IANA Registration of Environment Items
201
202 A registry of environment items is provided by IANA. Item names may
203 be registered on a first-come, first-served basis.
204
205 Groups of items defined in a standards track or experimental RFC MAY
206 choose to use a common name prefix of the form "name.", where "name"
207 is a string that identifies the group of related items.
208
209 Items not defined in a standards track or experimental RFC MUST have
210 a name that begins with the "vnd." prefix, and this prefix is
211 followed by the name of the vendor or product, such as
212 "vnd.acme.rocket-sled-status".
213
214
215
216
217
218
219
220
221
222
223
224
225
226Freed Standards Track [Page 4]
227
228RFC 5183 Sieve Environment Extension May 2008
229
230
2314.3.1. Template for Environment Registrations
232
233 The following template is to be used for registering new Sieve
234 environment item names with IANA.
235
236 To: iana@iana.org
237 Subject: Registration of new Sieve environment item
238
239 Item name: [the string for use in the 'environment' test]
240 Description: [a brief description of the semantics of the
241 value the item returns]
242
243 RFC number: [for extensions published as RFCs]
244 Contact address: [email and/or physical address to contact for
245 additional information]
246
247 Multiple items and descriptions MAY be specified in a single
248 registration request. Both standardized and vendor-defined items use
249 this form.
250
2515. Security Considerations
252
253 The environment extension may be used to obtain information about the
254 system the Sieve implementation is running on. This information in
255 turn may reveal details about service provider or enterprise
256 infrastructure.
257
258 An implementation can use any technique to determine the remote-host
259 environment item defined in this specification, and the
260 trustworthiness of the result will vary. One common method will be
261 to perform a PTR DNS lookup on the client IP address. This
262 information may come from an untrusted source. For example, the
263 test:
264
265 if environment :matches "remote-host" "*.example.com" { ... }
266
267 is not a good way to test whether the message came from "outside"
268 because anyone who can create a PTR record can create one that refers
269 to whatever domain they choose.
270
271 All of the security considerations given in the base Sieve
272 specification also apply to this extension.
273
274
275
276
277
278
279
280
281
282Freed Standards Track [Page 5]
283
284RFC 5183 Sieve Environment Extension May 2008
285
286
2876. IANA Considerations
288
289 The following template specifies the IANA registration of the Sieve
290 extension specified in this document:
291
292 To: iana@iana.org
293 Subject: Registration of new Sieve extension
294
295 Capability name: environment
296 Description: The "environment" extension provides a new
297 environment test that can be used to implement
298 scripts that behave differently when moved
299 from one system to another or otherwise
300 operated in different contexts.
301 RFC number: RFC 5183
302 Contact address: Sieve discussion list <ietf-mta-filters@imc.org>
303
304 This specification also defines a new IANA registry for Sieve
305 environment item names. The specifics of this registry are given in
306 Section 4.3. The initial contents of the registry are given in the
307 following section.
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338Freed Standards Track [Page 6]
339
340RFC 5183 Sieve Environment Extension May 2008
341
342
3436.1. Initial Environment Item Registrations
344
345 The following template specifies the initial IANA registrations for
346 the environment items defined in this document:
347
348 To: iana@iana.org
349 Subject: Registration of new Sieve environment items
350
351 Capability name: domain
352 Description: The primary DNS domain associated with the Sieve
353 execution context, usually but not always a
354 proper suffix of the host name.
355
356 Capability name: host
357 Description: The fully-qualified domain name of the host
358 where the Sieve script is executing.
359
360 Capability name: location
361 Description: Type of service executing the Sieve script.
362
363 Capability name: name
364 Description: The product name associated with the Sieve
365 interpreter.
366
367 Capability name: phase
368 Description: Point relative to final delivery at which the
369 Sieve script is being evaluated.
370
371 Capability name: remote-host
372 Description: Host name of remote SMTP client, if applicable
373 and available.
374
375 Capability name: remote-ip
376 Description: IP address of remote SMTP client, if applicable
377 and available.
378
379 Capability name: version
380 Description: The product version associated with the Sieve
381 interpreter.
382
383 RFC number: RFC 5183
384 Contact address: Sieve discussion list <ietf-mta-filters@imc.org>
385
386
387
388
389
390
391
392
393
394Freed Standards Track [Page 7]
395
396RFC 5183 Sieve Environment Extension May 2008
397
398
3997. References
400
4017.1. Normative references
402
403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
404 Requirement Levels", BCP 14, RFC 2119, March 1997.
405
406 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
407 April 2001.
408
409 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email
410 Filtering Language", RFC 5228, January 2008.
411
412 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering:
413 Relational Extension", RFC 5231, January 2008.
414
4157.2. Informative references
416
417 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work
418 in Progress, February 2008.
419
420 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
421 VERSION 4rev1", RFC 3501, March 2003.
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450Freed Standards Track [Page 8]
451
452RFC 5183 Sieve Environment Extension May 2008
453
454
455Appendix A. Acknowledgements
456
457 Brian Carpenter, Dave Crocker, Cyrus Daboo, Philip Guenther, Kjetil
458 Torgrim Homme, John Klensin, Mark Mallett, Alexey Melnikov, and
459 Dilyan Palauzo provided helpful suggestions and corrections.
460
461Author's Address
462
463 Ned Freed
464 Sun Microsystems
465 3401 Centrelake Drive, Suite 410
466 Ontario, CA 92761-1205
467 USA
468
469 Phone: +1 909 457 4293
470 EMail: ned.freed@mrochek.com
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506Freed Standards Track [Page 9]
507
508RFC 5183 Sieve Environment Extension May 2008
509
510
511Full Copyright Statement
512
513 Copyright (C) The IETF Trust (2008).
514
515 This document is subject to the rights, licenses and restrictions
516 contained in BCP 78, and except as set forth therein, the authors
517 retain all their rights.
518
519 This document and the information contained herein are provided on an
520 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
521 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
522 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
523 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
524 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
525 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
526
527Intellectual Property
528
529 The IETF takes no position regarding the validity or scope of any
530 Intellectual Property Rights or other rights that might be claimed to
531 pertain to the implementation or use of the technology described in
532 this document or the extent to which any license under such rights
533 might or might not be available; nor does it represent that it has
534 made any independent effort to identify any such rights. Information
535 on the procedures with respect to rights in RFC documents can be
536 found in BCP 78 and BCP 79.
537
538 Copies of IPR disclosures made to the IETF Secretariat and any
539 assurances of licenses to be made available, or the result of an
540 attempt made to obtain a general license or permission for the use of
541 such proprietary rights by implementers or users of this
542 specification can be obtained from the IETF on-line IPR repository at
543 http://www.ietf.org/ipr.
544
545 The IETF invites any interested party to bring to its attention any
546 copyrights, patents or patent applications, or other proprietary
547 rights that may cover technology that may be required to implement
548 this standard. Please address the information to the IETF at
549 ietf-ipr@ietf.org.
550
551
552
553
554
555
556
557
558
559
560
561
562Freed Standards Track [Page 10]
563
564