1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 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 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 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 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426
|
Network Working Group
Internet Draft: Sieve -- IMAP flag Extension A. Melnikov
Document: draft-melnikov-sieve-imapflags-03.txt Messaging Direct, Ltd.
Expires: January 2001 July 2000
Sieve -- IMAP flag Extension
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The protocol discussed in this document is experimental and subject
to change. Persons planning on either implementing or using this
protocol are STRONGLY URGED to get in touch with the author before
embarking on such a project.
Copyright
Copyright (C) The Internet Society 2000. All Rights Reserved.
Abstract
Recent discussions have shown that it is desirable to set
different [IMAP] flags on message delivery. This can be done, for
example, by a SIEVE interpreter that works as a part of a Mail Delivery
Agent.
This document describes an extension to the Sieve mail filtering
language for setting [IMAP] flags. The extension allows to set both
[IMAP] system flags and [IMAP] keywords.
0. Meta-information on this draft
This information is intended to facilitate discussion. It will be
removed when this document leaves the Internet-Draft stage.
0.1. Discussion
This draft is intended to be compared with the Sieve mail filtering
language, an Internet-Draft being discussed on the MTA Filters
mailing list at <ietf-mta-filters@imc.org>. Subscription requests
can be sent to <ietf-mta-filters-request@imc.org> (send an email
message with the word "subscribe" in the body). More information on
the mailing list along with a WWW archive of back messages is
available at <http://www.imc.org/ietf-mta-filters/>.
0.2. Changes from the version submitted to the SIEVE mailing list
1. Added addflag and removeflag actions
2. Changed the semantics of setflag (setflag is not additive any more)
3. Corrected section "Interaction with Other Sieve Actions".
Removed incorrect reference to the forward action as to an
action that prohibits setflag.
4. Added paragraph about the mutual order of fileinto/keep and
setflag/addflag/removeflag actions.
0.3. Changes from the revision 00
1. Corrected Capability Identifier section (Section 2)
2. Corrected "Interaction with Other Sieve Actions" section (Section 4)
3. Examples were updated to be compatible with Sieve-07 draft
4. Added "mark" and "unmark" actions
0.4. Changes from the revision 01
1. Some language fixes based on Tony Hansen comments
2. Clarified that the extension allows to set both IMAP System Flags and Keywords
0.5. Changes from the revision 02
1. BugFix: all backslashes must be escaped
2. Added extended example and more detailed description of addflag/removeflag additivity.
3. Minor example bugfixes
1. Introduction
This is an extension to the Sieve language defined by [SIEVE] for
setting [IMAP] flags. It defines several new actions "setflag",
"addflag", "removeflag", "mark" and "unmark".
This document doesn't dictate how the SIEVE interpreter will set the [IMAP]
flags. In particular, the SIEVE interpreter may work as an IMAP client,
or may have direct access to the mailstore.
SIEVE interpreters that don't support integration with IMAP
SHOULD ignore this extension.
Conventions for notations are as in [SIEVE] section 1.1, including
use of [KEYWORDS].
2. Capability Identifier
The capability string associated with extension defined in this document
is "imapflags".
3. Actions
All actions described in this specification (setflag, addflag, removeflag,
mark, unmark) operate on an internal variable that contains the set of [IMAP] flags
associated with the message being delivered. When the interpreter starts executing
a script this variable contains an empty set. The 'addflag' action adds flags
to the existing set. The 'removeflag' action removes flags from the existing set.
The 'setflag' action replaces the existing set of flags with a new set.
Whenever the interpreter encounters a 'fileinto' or 'keep' action it files
the message with the current set of flags.
3.1. Setflag Action
Syntax: setflag <list-of-flags>
Setflag is used for setting [IMAP] system flags or keywords. Setflag
replaces any previously set flags. It should be used together with keep
or fileinto. It MUST be ignored if mailstore or target mailbox doesn't
support the storing of any flags.
Flags can be set only for the message that is currently being processed by
SIEVE. When called with keep, setflag sets flags in the user's main
mailbox. When called with fileinto, setflag sets flags in the
mailbox indicated by the parameter.
The order of setflag/fileinto or setflag/keep is important in the
script. Any setflag action applies only to subsequent fileinto/keep
actions in a script till next occurence of setflag/addflag/removeflag/mark/unmark.
Server MUST ignore all flags that it can't store permanently. This
means, in particular, that if the user's main mailbox can't store any
flags, then the following SIEVE script produces no actions
Example: if size :over 500K {
setflag "\\Deleted";
}
A more substantial example is:
Example:
if header :contains "from" "boss@frobnitzm.edu" {
setflag "\\Flagged";
fileinto "INBOX.From Boss";
}
3.2. Addflag action
Syntax: addflag <list-of-flags>
Addflag is used for setting [IMAP] flags. However unlike setflag it
doesn't replace any previously set flags. This means that multiple
occurrences of addflag are treated additively.
For example, the following two actions
addflag "\\Deleted";
addflag "\\Answered";
produce the same result as the single action
addflag ["\\Deleted", "\\Answered"];
In all other respects addflag behaves the same way as
setflag.
3.3. Removeflag Action
Syntax: removeflag <list-of-flags>
Removeflag is used for setting [IMAP] flags. Removeflag clears
flags previously set by setflag/addflag. Calling removeflag with a
flag that wasn't set before is not an error and is ignored.
Multiple occurrences of removeflag are treated additively.
In all other respects removeflag behaves the same way as
setflag.
Example:
if header :contains "Disposition-Notification-To" "mel@example.com" {
addflag "$MDNRequired";
}
if header :contains "from" "imap@cac.washington.edu" {
removeflag "$MDNRequired";
fileinto "INBOX.imap-list";
}
3.4. Mark and Unmark Actions
Syntax: mark
Syntax: unmark
The mark action allows a message to be marked as urgent. Implementers are free
to choose any flag or any combination of [IMAP] flags, however it is
RECOMMENDED that the [IMAP] \Flagged flag be used. The mark action is
semantically equivalent to 'addflag "\\Flagged"'.
The unmark action allows the flag previously set by the Mark
action to be unset. Unmark SHOULD at least clear the [IMAP] \Flagged flag
and MUST clear all flags that could be added with mark.
Unmark MAY clear other flags as well. The unmark action is semantically
equivalent to 'removeflag "\\Flagged"'.
3.5 Extended example
#
# Example Sieve Filter
# Declare any optional features or extension used by the script
#
require ["fileinto", "reject", "imapflags"];
#
# Reject any large messages
#
if size :over 1M
{
if header :is "From" "boss@company.com"
{
addflag "\\Flagged $Big";
# The message will be marked as "\Flagged $Big" when filed into mailbox "Big messages"
}
fileinto "Big messages";
}
if header :is "From" "grandma@example.net"
{
addflag ["\\Answered", "$MDNSent"];
# If the message is bigger than 1Mb it will be marked as "\Flagged $Big \Answered $MDNSent"
# when filed into mailbox "grandma". If the message is shorter than 1Mb it will be marked as
# "\Answered $MDNSent"
fileinto "GrandMa"; # move to "GrandMa" folder
}
#
# Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter folder
#
if header :is "Sender" "owner-ietf-mta-filters@imc.org"
{
setflag "\\Flagged";
# Message will always have just "\Flagged" flag
keep;
}
#
# Keep all messages to or from people in my company
#
elsif anyof address :domain :is ["From", "To"] "company.com"
{
keep; # keep in "In" folder
}
#
# Try and catch unsolicited email. If a message is not to me,
# or it contains a subject known to be spam, file it away.
#
elsif anyof (not address :all :contains
["To", "Cc", "Bcc"] "me@company.com",
header :matches "subject"
["*make*money*fast*", "*university*dipl*mas*"])
{
removeflag "\\Flagged";
# If message header does not contain my address,
# it's from a list.
fileinto "spam"; # move to "spam" folder
}
else
{
# Move all other (non-company) mail to "personal"
# folder.
fileinto "personal";
}
4. Interaction with Other Sieve Actions
Sieve actions sometimes prohibit each other in order to make
filtering scripts less likely to cause serious problems.
It is strongly discouraged to use setflag/addflag/removeflag/mark/unmark
actions together with reject, because that action doesn't allow keeping a
received message.
The SIEVE interpreter MUST ignore any setflag/addflag/removeflag/mark/unmark
commands when they are used with reject. The SIEVE interpreter MUST ignore these
commands when no keep (implicit or explicit) or fileinto actions will be taken.
A SIEVE verifier SHOULD reject a script that contains a
setflag/addflag/removeflag/mark/unmark action together with reject.
5. Other Considerations
This extension intentionally doesn't allow setting [IMAP] flags on an
arbitrary message in the [IMAP] message store.
6. Security Considerations
Security considerations are discussed in the [IMAP] and [SIEVE].
It is belived that this extension doesn't introduce any
additional security concerns.
7. Formal Grammar
The grammar used in this section is the same as the ABNF described in
[ABNF].
action =/ setflag / addflag / removeflag / mark / unmark
setflag = "setflag" WSP string-list
;; a list of [IMAP] flags
addflag = "addflag" WSP string-list
;; a list of [IMAP] flags
removeflag = "removeflag" WSP string-list
;; a list of [IMAP] flags
mark = "mark"
unmark = "unmark"
8. Acknowledgments
This document has been revised in part based on comments and
discussions which took place on and off the SIEVE mailing list.
The help of those who took the time to review the draft and make
suggestions is appreciated, especially that of Tim Showalter,
Barry Leiba, and Randall Gellens. Special thanks to Tony Hansen,
David Lamb and Roman Migal for helping me explain better the concept.
9. Author's Address
Alexey Melnikov
Messaging Direct, Ltd.
Address : #900, 10117 Jasper Avenue, Edmonton, Alberta, Canada,
T5J1W8
Email: mel@messagingdirect.com
Appendices
Appendix A. References
[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint,
Work in Progress, draft-showalter-sieve-XX.txt
[ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
Internet Mail Consortium, RFC 2234, November, 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", Harvard University, RFC 2119, March 1997.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
University of Washington, RFC 2060, December 1996.
Appendix B. Full Copyright Statement
Copyright (C) The Internet Society 2000. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|