| < draft-ietf-extra-sieve-special-use-03.txt | draft-ietf-extra-sieve-special-use-04.txt > | |||
|---|---|---|---|---|
| EXTRA S. Bosch | EXTRA S. Bosch | |||
| Internet-Draft Dovecot Oy | Internet-Draft Dovecot Oy | |||
| Intended status: Standards Track September 5, 2018 | Intended status: Standards Track November 27, 2018 | |||
| Expires: March 9, 2019 | Expires: May 31, 2019 | |||
| Sieve Email Filtering: Delivering to Special-Use Mailboxes | Sieve Email Filtering: Delivering to Special-Use Mailboxes | |||
| draft-ietf-extra-sieve-special-use-03 | draft-ietf-extra-sieve-special-use-04 | |||
| Abstract | Abstract | |||
| The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows | The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows | |||
| clients to identify special-use mailboxes; e.g., where draft or sent | clients to identify special-use mailboxes; e.g., where draft or sent | |||
| messages should be put. This simplifies client configuration. In | messages should be put. This simplifies client configuration. In | |||
| contrast, the Sieve mail filtering language (RFC 5228) currently has | contrast, the Sieve mail filtering language (RFC 5228) currently has | |||
| no such capability. This memo defines a Sieve extension that fills | no such capability. This memo defines a Sieve extension that fills | |||
| this gap: it adds a test for checking whether a special-use attribute | this gap: it adds a test for checking whether a special-use attribute | |||
| is assigned for a particular mailbox or any mailbox, and it adds the | is assigned for a particular mailbox or any mailbox, and it adds the | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on March 9, 2019. | This Internet-Draft will expire on May 31, 2019. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 14 ¶ | skipping to change at page 2, line 14 ¶ | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | |||
| 3. Test "specialuse_exists" . . . . . . . . . . . . . . . . . . 3 | 3. Test "specialuse_exists" . . . . . . . . . . . . . . . . . . 3 | |||
| 4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 4 | 3.1. Equivalent IMAP Operations . . . . . . . . . . . . . . . 4 | |||
| 4.1. Mailboxes Created Implicitly by the "fileinto" Command . 5 | 4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 5 | |||
| 5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 6 | 4.1. Mailboxes Created Implicitly by the "fileinto" Command . 6 | |||
| 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.2. Equivalent IMAP Operations . . . . . . . . . . . . . . . 7 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 8 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 9 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 11 | ||||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
| 1. Introduction | 1. Introduction | |||
| Commonly, several mailboxes in an IMAP message store [IMAP] have a | Commonly, several mailboxes in an IMAP message store [IMAP] have a | |||
| special use; e.g. it is where the user's draft messages are stored, | special use; e.g. it is where the user's draft messages are stored, | |||
| where a copy of sent messages are kept, or it is where spam messages | where a copy of sent messages are kept, or it is where spam messages | |||
| are filed automatically at delivery. The SPECIAL-USE capability | are filed automatically at delivery. The SPECIAL-USE capability | |||
| [SPECIAL-USE] of the IMAP protocol defines mailbox attributes that | [SPECIAL-USE] of the IMAP protocol defines mailbox attributes that | |||
| identify these special mailboxes explicitly to the client. This way, | identify these special mailboxes explicitly to the client. This way, | |||
| client configuration is simplified significantly. Using the CREATE- | client configuration is simplified significantly. Using the CREATE- | |||
| skipping to change at page 3, line 24 ¶ | skipping to change at page 3, line 26 ¶ | |||
| 2. Conventions Used in This Document | 2. Conventions Used in This Document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [KEYWORDS]. | document are to be interpreted as described in [KEYWORDS]. | |||
| Conventions for notations are as in [SIEVE] Section 1.1, including | Conventions for notations are as in [SIEVE] Section 1.1, including | |||
| use of the "Usage:" label for the definition of action and tagged | use of the "Usage:" label for the definition of action and tagged | |||
| arguments syntax. | arguments syntax. | |||
| In [IMAP] examples, "C:" and "S:" indicate lines sent by the client | ||||
| and server respectively. If such lines are wrapped without a new | ||||
| "C:" or "S:" label, then the wrapping is for editorial clarity and is | ||||
| not part of the command. | ||||
| 3. Test "specialuse_exists" | 3. Test "specialuse_exists" | |||
| Usage: specialuse_exists [<mailbox: string>] | Usage: specialuse_exists [<mailbox: string>] | |||
| <special-use-flags: string-list> | <special-use-flags: string-list> | |||
| If the "mailbox" string argument is omitted, the "specialuse_exists" | If the "mailbox" string argument is omitted, the "specialuse_exists" | |||
| test yields true if all of the following statements are true for each | test yields true if all of the following statements are true for each | |||
| of the special-use flags listed in the "special-use-flags" argument: | of the special-use flags listed in the "special-use-flags" argument: | |||
| a. at least one mailbox exists in the user's personal namespace | a. at least one mailbox exists in the user's personal namespace | |||
| skipping to change at page 3, line 44 ¶ | skipping to change at page 4, line 4 ¶ | |||
| [NAMESPACE] that has that particular special-use flag assigned, | [NAMESPACE] that has that particular special-use flag assigned, | |||
| and | and | |||
| b. that mailbox allows the user in whose context the Sieve script | b. that mailbox allows the user in whose context the Sieve script | |||
| runs to "deliver" messages into it. | runs to "deliver" messages into it. | |||
| If the "mailbox" argument is specified, the "specialuse_exists" test | If the "mailbox" argument is specified, the "specialuse_exists" test | |||
| yields true if all of the following statements are true: | yields true if all of the following statements are true: | |||
| a. the indicated mailbox exists, | a. the indicated mailbox exists, | |||
| b. that mailbox allows the user in whose context the Sieve script | b. that mailbox allows the user in whose context the Sieve script | |||
| runs to "deliver" messages into it, and | runs to "deliver" messages into it, and | |||
| c. that mailbox has all of the special-use flags listed in the | c. that mailbox has all of the special-use flags listed in the | |||
| "special-use-flags" argument assigned to it. | "special-use-flags" argument assigned to it. | |||
| Refer to the specification of the "mailboxexists" test in Section 3.1 | Refer to the specification of the "mailboxexists" test in Section 3.1 | |||
| of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of | of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of | |||
| messages into a mailbox is deemed possible. | messages into a mailbox is deemed possible. | |||
| 3.1. Equivalent IMAP Operations | ||||
| To clarify, a sequence of [IMAP] commands that a client could send to | ||||
| perform an assessment without Sieve that is equivalent to the | ||||
| "specialuse_exists" test is shown in the following IMAP protocol | ||||
| examples. | ||||
| First, the client queries which namespaces are available using the | ||||
| NAMESPACE command [NAMESPACE]: | ||||
| C: A01 NAMESPACE | ||||
| S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/")) | ||||
| S: A01 OK NAMESPACE command completed | ||||
| Subsequently, when no particular mailbox is of interest (i.e., the | ||||
| "specialuse_exists" test has no mailbox argument), the client lists | ||||
| all mailboxes with special-use flags in the two returned personal | ||||
| namespaces (this extended LIST command requires the LIST-EXTENDED | ||||
| IMAP capability [LIST-EXTENDED]): | ||||
| C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") | ||||
| RETURN (SPECIAL-USE) | ||||
| S: * LIST (\Drafts) "/" INBOX/Drafts | ||||
| S: * LIST (\Trash) "/" INBOX/Trash | ||||
| S: * LIST (\Sent) "/" INBOX/Sent | ||||
| S: * LIST (\Archive) "/" Archive/Default | ||||
| S: A02 OK LIST command completed | ||||
| Finally, using the MYRIGHTS command [IMAP-ACL], the client determines | ||||
| the access rights it has for the mailbox or mailboxes that have all | ||||
| the requested flags assigned. This way, it can determine whether | ||||
| messages can be saved to any of those. In this example, an | ||||
| "\Archive" special-use mailbox is sought: | ||||
| C: A03 MYRIGHTS Archive/Default | ||||
| S: * MYRIGHTS Archive/Default lrwsip | ||||
| S: A03 OK Myrights completed | ||||
| The MYRIGHTS response indicates that the the user has "insert" rights | ||||
| [IMAP-ACL] for the "Archive/Default" mailbox, meaning that the client | ||||
| can deliver (APPEND) messages to that mailbox and that the Sieve | ||||
| "specialuse_exists" test would yield "true" in this case. | ||||
| 4. ":specialuse" Argument to "fileinto" Command | 4. ":specialuse" Argument to "fileinto" Command | |||
| Usage: fileinto [:specialuse <special-use-flag: string>] | Usage: fileinto [:specialuse <special-use-flag: string>] | |||
| <mailbox: string> | <mailbox: string> | |||
| Normally, the "fileinto" command delivers the message in the mailbox | Normally, the "fileinto" command delivers the message in the mailbox | |||
| specified using its positional mailbox argument. However, if the | specified using its positional mailbox argument. However, if the | |||
| optional ":specialuse" argument is also specified, the "fileinto" | optional ":specialuse" argument is also specified, the "fileinto" | |||
| command first checks whether a mailbox exists in the user's personal | command first checks whether a mailbox exists in the user's personal | |||
| namespace [NAMESPACE] with the specified special-use flag assigned to | namespace [NAMESPACE] with the specified special-use flag assigned to | |||
| skipping to change at page 6, line 5 ¶ | skipping to change at page 7, line 5 ¶ | |||
| change: the Sieve interpreter will implicitly create the specified | change: the Sieve interpreter will implicitly create the specified | |||
| default mailbox if needed. This need arises when both the special- | default mailbox if needed. This need arises when both the special- | |||
| use mailbox and the default mailbox are not found. | use mailbox and the default mailbox are not found. | |||
| If the server implementation supports the CREATE-SPECIAL-USE | If the server implementation supports the CREATE-SPECIAL-USE | |||
| capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special- | capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special- | |||
| use flags to new mailboxes) it SHOULD assign the special-use flag | use flags to new mailboxes) it SHOULD assign the special-use flag | |||
| specified with the ":specialuse" argument to the newly created | specified with the ":specialuse" argument to the newly created | |||
| mailbox. | mailbox. | |||
| 4.2. Equivalent IMAP Operations | ||||
| To clarify, a sequence of [IMAP] commands that a client could send to | ||||
| perform an action without Sieve that is equivalent to the "fileinto" | ||||
| action with the ":specialuse" argument is shown in the following IMAP | ||||
| protocol examples. The following Sieve script is assumed: | ||||
| require "fileinto"; | ||||
| require "special-use"; | ||||
| fileinto :specialuse "\\Archive" "INBOX/Archive"; | ||||
| First, the client proceeds as in Section 3.1 to find out whether the | ||||
| indicated special-use flag is assigned to any mailbox in the user's | ||||
| personal namespace. If a matching special-use mailbox is found, the | ||||
| message is delivered there using the IMAP APPEND command. If no | ||||
| matching special-use mailbox is found, the client attempts to deliver | ||||
| the message to the indicated default mailbox: | ||||
| C: A04 APPEND INBOX/Archive {309} | ||||
| S: A04 NO [TRYCREATE] Mailbox does not exist: Archive/Personal | ||||
| In this example, the default mailbox does not exist either. In that | ||||
| case, the client MAY create the default mailbox and assign the | ||||
| indicated special-use flag to it: | ||||
| C: A05 CREATE INBOX/Archive (USE (\Archive)) | ||||
| S: A05 OK Create completed | ||||
| Finally, the client completes the delivery: | ||||
| C: A06 APPEND INBOX/Archive {309} | ||||
| S: + OK | ||||
| C: Date: Wed, 18 Jul 2018 22:00:09 +0200 | ||||
| C: From: mooch@owatagu.siam.edu | ||||
| C: To: Fred Foobar <foobar@Blurdybloop.com> | ||||
| C: Subject: afternoon meeting | ||||
| C: Message-Id: <Q234234-01012222@owatagu.siam.edu> | ||||
| C: MIME-Version: 1.0 | ||||
| C: Content-Type: text/plain; charset=UTF-8 | ||||
| C: | ||||
| C: Hi Fred, do you think we can meet again at 3:30 tomorrow? | ||||
| C: | ||||
| S: A06 OK [APPENDUID 1533375901 2312] Append completed. | ||||
| 5. Sieve Capability Strings | 5. Sieve Capability Strings | |||
| A Sieve implementation that defines the "specialuse_exists" test and | A Sieve implementation that defines the "specialuse_exists" test and | |||
| the ":specialuse" argument for the "fileinto" command will advertise | the ":specialuse" argument for the "fileinto" command will advertise | |||
| the capability string "special-use". | the capability string "special-use". | |||
| 6. Examples | 6. Examples | |||
| The following example saves the message in the mailbox where messages | The following example saves the message in the mailbox where messages | |||
| deemed to be junk mail are held. This mailbox is identified using | deemed to be junk mail are held. This mailbox is identified using | |||
| skipping to change at page 9, line 25 ¶ | skipping to change at page 11, line 25 ¶ | |||
| [VARIABLES] | [VARIABLES] | |||
| Homme, K., "Sieve Email Filtering: Variables Extension", | Homme, K., "Sieve Email Filtering: Variables Extension", | |||
| RFC 5229, January 2008. | RFC 5229, January 2008. | |||
| 10.2. Informative References | 10.2. Informative References | |||
| [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | |||
| 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | |||
| <http://www.rfc-editor.org/info/rfc3501>. | <http://www.rfc-editor.org/info/rfc3501>. | |||
| [IMAP-ACL] | ||||
| Melnikov, A., "IMAP4 Access Control List (ACL) Extension", | ||||
| RFC 4314, DOI 10.17487/RFC4314, December 2005, | ||||
| <https://www.rfc-editor.org/info/rfc4314>. | ||||
| [IMAPSIEVE] | [IMAPSIEVE] | |||
| Leiba, B., "Support for Internet Message Access Protocol | Leiba, B., "Support for Internet Message Access Protocol | |||
| (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, | (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, | |||
| November 2012, <http://www.rfc-editor.org/info/rfc6785>. | November 2012, <http://www.rfc-editor.org/info/rfc6785>. | |||
| [LIST-EXTENDED] | ||||
| Leiba, B. and A. Melnikov, "Internet Message Access | ||||
| Protocol version 4 - LIST Command Extensions", RFC 5258, | ||||
| DOI 10.17487/RFC5258, June 2008, <https://www.rfc- | ||||
| editor.org/info/rfc5258>. | ||||
| Author's Address | Author's Address | |||
| Stephan Bosch | Stephan Bosch | |||
| Dovecot Oy | Dovecot Oy | |||
| Lars Sonckin Kaari 12 | Lars Sonckin Kaari 12 | |||
| Espoo 02600 | Espoo 02600 | |||
| Finland | Finland | |||
| Email: stephan.bosch@dovecot.fi | Email: stephan.bosch@dovecot.fi | |||
| End of changes. 10 change blocks. | ||||
| 16 lines changed or deleted | 120 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||