idnits 2.17.1 draft-ordogh-spam-reporting-using-imap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 30, 2012) is 4229 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IMAP' is mentioned on line 421, but not defined ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3462 (ref. 'OLD-REPORT') (Obsoleted by RFC 6522) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Ordogh 3 Internet-Draft Research In Motion Limited 4 Intended status: Experimental August 30, 2012 5 Expires: March 3, 2013 7 Spam reporting using IMAP: SREP 8 draft-ordogh-spam-reporting-using-imap-03 10 Abstract 12 This document defines an IMAP extension which allows a client to 13 report spam by reference and allows an IMAP server to perform any 14 action on the reported messages, including leaving the action at the 15 client's discretion. 17 In addition, this document discusses how an IMAP server can tap into 18 spam aggregator services, ultimately allowing the IMAP server to 19 improve its decision-making process. 21 Conventions Used In This Document 23 In examples, "C:" and "S:" indicate lines sent by the client or the 24 server, respectively. 26 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 27 in this document are to be interpreted as described in [RFC2119]. 29 This specification follows the recommendations in [XDASH]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 3, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. The SREP command . . . . . . . . . . . . . . . . . . . . . . . 4 79 3.1. Directives . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3.2. Abuse types . . . . . . . . . . . . . . . . . . . . . . . 5 81 3.3. References . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3.4. Part identifiers . . . . . . . . . . . . . . . . . . . . . 6 83 3.5. Request Action . . . . . . . . . . . . . . . . . . . . . . 6 84 3.6. Responses and Results . . . . . . . . . . . . . . . . . . 7 85 3.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 8 86 3.8. Examples to report spam . . . . . . . . . . . . . . . . . 10 87 3.9. Examples to report messages as no longer spam . . . . . . 10 88 3.10. Example flows . . . . . . . . . . . . . . . . . . . . . . 11 89 3.10.1. The server simply flags a message . . . . . . . . . . 11 90 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 The Internet Message Access Protocol [IMAP4] does not support 100 reporting spam on its own. There are a number of solutions available 101 based on the multipart/report content type defined in [OLD-REPORT] 102 and its revision, [REPORT]. However, these solutions require 103 including the message contents and hence, consume bandwidth to 104 transmit the entire message. In bandwidth-constrained environments - 105 such as mobile networks - it is highly desirable to send only a 106 minimum set of information - a reference - instead of the entire 107 message. Solutions that exist today employ manipulating proprietary 108 flags in the IMAP storage to achieve the bare minimum, however more 109 advanced solutions cannot be developed by using flags only; the IMAP 110 server needs to be involved actively in the spam reporting process. 112 Furthermore, it is highly desirable to permit individual server 113 implementations to handle spam in any way these systems choose to: do 114 nothing, flag, perform deletion or relocation, recommend deletion or 115 relocation to the client, or, leave the decision at the client's 116 discretion as a whole. However, in order to make such a decision on 117 the server side, a spam aggregator service, such as [OMA-SPAMREP], 118 needs to be involved in the decision-making process. 120 This document specifies a new IMAP command, SREP, along with its 121 syntax, which allows a client to inform the server that the user 122 considered a message (or parts thereof) spam, or, that the user no 123 longer considers a message (or parts thereof) spam. Since all 124 information about the message is readily available on the server, the 125 command also allows the server to implement a more intelligent and 126 accurate decision logic, which may be invoked when the spam is 127 reported and the server can respond with its decision to the client. 129 Additionally, this document contains example flows, illustrating 130 various decisions that the server may choose to evaluate, including 131 invoking an aggregator service, such as one based on [OMA-SPAMREP]. 133 The SREP command allows: 134 reporting spam; i.e. set the spam condition, and, 135 reporting that a message (that was reported spam earlier) is no 136 longer spam; i.e. clear the spam condition. 138 2. Scope 140 This document focuses only on the client-server interactions and the 141 scope is limited to messages that either exist on the IMAP server, 142 or, exist elsewhere and the IMAP server is configured to access them. 143 Consequently, deposit-time filtering, messages that have been 144 deleted, and messages that exist in an external storage but are 145 accessible only via an access protocol unknown to the IMAP server are 146 out of scope. 148 3. The SREP command 150 The SREP command follows the conventions of [IMAP4]. 152 Arguments: 153 directive; see Section 3.1 154 OPTIONAL abuse type; see Section 3.2 155 reference; see Section 3.3 156 OPTIONAL list of part identifiers; see Section 3.4 157 OPTIONAL request action; see Section 3.5 159 Responses; see Section 3.6: 160 OPTIONAL OK response: RELOCATE 161 OPTIONAL OK response: RELOCATED 162 OPTIONAL OK response: DELETE 163 OPTIONAL OK response: DELETED 164 OPTIONAL OK response: KEYWORD 166 Result: 167 OK - command completed successfully 168 NO - the server cannot access one or more messages (deleted or 169 unauthorized) 170 BAD - there was an error during processing the command (syntax or 171 unsupported parameter) 173 The formal syntax of the SREP command is defined in Section 3.7. 175 The SREP command allows: 176 - reporting spam; i.e. set the spam condition, and, 177 - reporting that a message (that was reported spam earlier) is no 178 longer spam; i.e. clear the spam condition. 180 The SREP command may be used with any IMAP4 server implementation 181 that returns "SREP" as one of the supported capabilities in response 182 to the CAPABILITY command. If the server does not indicate support 183 for the SREP capability, the client MUST NOT use the SREP command. 185 The SREP command may result in ambiguity, therefore the client MUST 186 NOT send any commands before the result of the SREP command has been 187 received, see Section 5.5 in [IMAP]. 189 The command MAY be issued on one or more messages at a time, in the 190 currently selected mailbox. 192 The command MAY be extended in the future with new parameters 193 (actions, directives, reference types, etc). Servers MUST be able to 194 recognize parameters unknown to them and respond with a BAD response 195 in case they encounter such a parameter. 197 3.1. Directives 199 The directive argument tells the server whether a message is being 200 reported as a spam, or, it is being reported as no longer a spam. 201 The SREP command MUST include the directive. To report a spam, the 202 directive MUST be SET. To report that a message is no longer 203 considered to be a spam, the directive MUST be CLEAR. 205 Extensions are permitted, as defined in Section 3.7. 207 3.2. Abuse types 209 The client may have additional information about the spam regarding 210 the nature of the abuse. When such information is available, the 211 client SHOULD include the abuse type argument in the request. When 212 such information is not available, the client MUST omit the abuse 213 type argument from the request. When the directive argument is 214 CLEAR, the client MUST omit the abuse type argument from the request. 215 This specification defines the following abuse types: 217 1. Phishing (forgery, link manipulation, etc.): an attempt to 218 divulge information from the recipient by masquerading the sender 219 and/or the content(s) of the message as a trustworthy form of 220 communication. 221 2. Malware (virus, spyware, etc.): a malicious piece of software 222 code embedded or attached to the message specifically designed to 223 disrupt normal operation, gather sensitive information, gain 224 unauthorized access, and/or perform other abusive behavior upon 225 execution. 227 Extensions are permitted, as defined in Section 3.7. 229 3.3. References 231 The reference argument consists of a reference type and a reference 232 value. In general, the reference type MUST indicate the format of 233 the reference while the reference value MUST contain a value 234 corresponding to the indicated reference format. To use a unique 235 identifier specified in [IMAP4], the reference type MUST be UID and 236 the reference value MUST be a number expressing the unique identifier 237 of the message. To use a sequence set specified in [IMAP4], the 238 reference type MUST be SEQ and the reference value MUST be sequence 239 numbers corresponding to the specified message sequence number set. 240 To use an authorized URL specified in [URLAUTH], the reference type 241 MUST be URLAUTH and the reference value MUST be an URLAUTH-authorized 242 URL, authorizing the entire message. 244 Extensions are permitted, as defined in Section 3.7. 246 3.4. Part identifiers 248 When the reference identifies one and only one message, the list of 249 part identifiers MAY be included to improve the accuracy of spam 250 detection. When the reference identifies more than one message, the 251 list of part identifiers MUST be omitted. 253 The list of part identifiers is a parenthesized list of part 254 identifiers. Part identifiers MAY identify header fields or bodies. 255 Header field identifiers MUST be prefixed with the word 'header' and 256 the dot ('.') character MUST be used as the separator character. 257 Header fields MUST be identified by the name of the header field. 259 Example: 260 The 'From' header field is identified as 'header.from'. 262 Body identifiers MUST be prefixed with the word 'body' and the dot 263 ('.') character MUST be used as the separator character. Bodies MUST 264 be identified by their positions within the message hierarcy, where 265 the first position is 1 and the main level is 1. To refer the entire 266 body of a message (or all bodies of a multipart message), the 267 separator character, the position MUST be omitted. 269 Examples: 270 - The entire body of a message (or all bodies of a multipart 271 message) is identified as 'body'. 272 - Considering a simple multipart message, the part following the 273 first boundary is identified as 'body.1'. 274 - Considering a multipart message that includes an email 275 attachment following the second boundary, and the email attachment 276 containing text following the first boundary, the text within the 277 email message is identified as 'body.2.1'. 278 The formal syntax of the part-id-list is defined in Section 3.7. 280 3.5. Request Action 282 The request action argument explicitly tells the server what to do 283 with the the message. To request a specific action from the server 284 explicitly, the SREP command MUST include the request action 285 argument. To not request a specific action, the SREP command MUST 286 NOT include the request action argument; in this case, the server 287 MUST decide the course of action. The client MAY specify either one 288 of the following actions: 290 - The KEYWORD the client requests that only keyword(s) should be 291 added to the message. The server MUST add the appropriate 292 keyword. 293 - The RELOCATE the client requests that the message should be 294 relocated. The server MUST relocate the message by copying the 295 message to the destination mailbox removing the original as if 296 another connected client requested this action. 297 - The DELETE the client requests that the message should be 298 deleted. The server MUST delete the message as if another client 299 performed this action. 300 The server MUST ignore the destination mailbox in case it is nil, or, 301 the request action is KEYWORD or DELETE. It is assumed that the 302 server is pre-configured with the location where user's spam messages 303 are stored. If the server is not configured with such information 304 and the destination mailbox in a RELOCATE action is nil, or, 305 destination mailbox in a RELOCATE action is otherwise inaccessible to 306 the user (does not exist, insufficient permission, etc) the the 307 server MUST reject the request (see BAD response in Section 3.6). 308 NOTE: While the DELETE action does not seem appropriate in case the 309 directive argument is CLEAR, it is permitted. The formal syntax of 310 the request action argument is defined in Section 3.7. 312 3.6. Responses and Results 314 The SREP command MAY result in system flag changes, keyword changes, 315 message relocation, message removal, or a combination of these. 317 The result of the command MUST be either OK, NO or BAD: 318 - The OK result MUST be returned only in case the server parsed 319 and completed the command successfully. 320 - The NO result MUST be returned only in case the server parsed 321 the command successfully, but there is a problem with the 322 referenced message(s) that prevents the server from completing the 323 requested actions, such as one or more messages do not exist on 324 the server, one or more messages are not properly authorized by 325 URLAUTH, etc. 326 - The BAD result MUST be returned only in case the server cannot 327 parse the command, or a configuration error is preventing the 328 server from completing the requested actions. 330 When the result is OK, the response to a SET directive MUST be either 331 KEYWORD, RELOCATE, RELOCATED, DELETE, or DELETED. 333 When the result is OK, the response to a CLEAR directive MUST be 334 either KEYWORD, RELOCATE, or RELOCATED. 336 The server responses are: 338 - The KEYWORD response occurs in case this specific action has 339 been explicitly requested by the client, or, in case the server 340 decided that only the keywords should be updated either because it 341 does not wish to give any recommendation to the client (RELOCATE 342 or DELETE), or, because it does not have sufficient information 343 either internally, or, from the spam aggregator service that it is 344 configured to use. 345 - The RELOCATE response occurs in case the server decided that the 346 message should be relocated, however leaves this action to the 347 client. The client MAY decide what to do with the message. 348 - The RELOCATED response occurs in case this specific action has 349 been explicitly requested by the client, or, in case the server 350 decided that the message should be relocated and it performed 351 relocation of the message to the appropriate location before the 352 response was sent. The server MUST relocate the message by 353 copying the message to the appropriate location and removing the 354 original as if another connected client requested this action. 355 - The DELETE response occurs in case the server decided that the 356 message should be deleted, however leaves this action to the 357 client. The client MAY decide what to do with the message. 358 - The DELETED response occurs in case this specific action has 359 been explicitly requested by the client, or, in case the server 360 decided that the message should be deleted, and performed deletion 361 of the message before the response was sent. The server MUST 362 delete the message as if another client performed this action. 364 The KEYWORD, RELOCATE and DELETE responses MUST include the list of 365 flags/keywords that have been added or removed. Added keywords MUST 366 be prefixed with a plus sign ('+'), while removed keywords MUST be 367 prefixed with a minus sign ('-'). The RELOCATED and DELETED 368 responses MUST NOT include keywords. The formal syntax of the 369 actions is defined in Section 3.7. 371 3.7. Formal Syntax 373 This document extends the formal syntax defined in [IMAP4] using the 374 Augmented Backus-Naur Form (ABNF) notation specified in [ABNF]. 375 Note: all string literals are case insensitive. 377 srep-command = "SREP" SP directive *1(SP abuse-type) SP \ 378 reference *1(SP part-id-list) \ 379 *1(SP request-action) 380 directive = "SET" / "CLEAR" / directive-ext 381 directive-ext = atom 382 ; It is not required that new directives 383 ; begin with "X-", see [XDASH] 384 abuse-type = "AT" SP abuse-type-id 385 abuse-type-id = 1*DIGIT 386 ; no leading zeroes or signs 387 ; New abuse types MUST be registered with 388 ; IANA as standard or standards-track 389 reference = reference-type SP reference-value 390 reference-type = "UID" / "SEQ" / "URLAUTH" / reference-type-ext 391 reference-type-ext = atom 392 ; It is not required that new reference types 393 ; begin with "X-", see [XDASH] 394 reference-value = uniqueid / ; see [IMAP] 395 sequence-set / ; see [IMAP] 396 authorized-url / ; see [URLAUTH] 397 reference-value-ext 398 authorized-url = authimapurlfull / ; see [URLAUTH] 399 authimapurlrump ; see [URLAUTH] 400 reference-value-ext = atom 401 ; New reference values MUST correspond to 402 ; reference-type-ext 403 part-id-list = "(" part-id *(SP part-id) ")" 404 part-id = header-id / body-id 405 header-id = "header." header-fld-name 406 ; see header-fld-name in [IMAP] 407 body-id = "body" *("." 1*DIGIT) 408 ; no leading zeroes or signs in numberic part 409 request-action = "DO" SP req-action *1(SP destination-box) 410 req-action = "KEYWORD" / 411 "RELOCATE" / 412 "DELETE" 413 destination-box = mailbox / nil 414 resp-text-code = resp-spam-actions ; responses specific to 415 ; this command, extending 416 ; existing resp-text-code 417 ; defined in [IMAP] 418 resp-spam-actions = "KEYWORD" flag-list / ; see flag-list in [IMAP] 419 "RELOCATE" flag-list /; see flag-list in [IMAP] 420 "RELOCATED" / 421 "DELETE" flag-list / ; see flag-list in [IMAP] 422 "DELETED" 424 3.8. Examples to report spam 426 Report single message as spam; no identified parts; server only flags 427 the message and hints that it should be moved: 428 C: Z020 SREP SET SEQ 10 429 S: Z020 OK [RELOCATE +$OMAEVVM10-spam-user-identified] SREP 430 Completed. 432 Report single message as spam; header and body identified; server 433 adds the appropriate flags and hints that it should be deleted: 434 C: Z040 SREP SET SEQ 9 (header.from body.2) 435 S: Z040 OK [DELETE (+$OMAEVVM10-spam-user-identified-field.from 436 +$OMAEVVM10-spam-user-identified-body.2)] SREP Completed. 438 Report single message as spam; no identified parts; server moves the 439 message (may clear/set flags too, but that is irrelevant because the 440 client will need to reconcile anyway). 441 C: Z060 SREP SET SEQ 8 442 S: Z060 OK [RELOCATED] SREP Completed. 444 Report single message as spam; no identified parts; server deletes 445 the message. 446 C: Z080 SREP SET SEQ 6 447 S: Z080 OK [DELETED] SREP Completed. 449 Report single message as spam; no identified parts; client requests 450 explicitly to delete the message, server deletes the message as the 451 client requested. 452 C: Z100 SREP SET SEQ 4 DO DELETE NIL 453 S: Z100 OK [DELETED] SREP Completed. 455 3.9. Examples to report messages as no longer spam 457 Report single message as no longer spam; no identified parts; server 458 only clears the appropriate flags from the message. 459 C: Z020 SREP CLEAR SEQ 10 460 S: A020 OK [KEYWORD -$OMAEVVM10-spam-user-identified] SREP 461 Completed. 463 Report single message as no longer spam; earlier the header and body 464 were identified as spam; the server clears the appropriate flags. 465 C: Z040 SREP CLEAR SEQ 9 466 S: A040 OK [KEYWORD (-$OMAEVVM10-spam-user-identified-field.from 467 -$OMAEVVM10-spam-user-identified-body.2)] SREP Completed. 469 Report single message as no longer spam; no identified parts; server 470 moves the message (may set/clear flags, too but that is irrelevant 471 because the client will need to reconcile anyway). 473 C: Z060 SREP CLEAR SEQ 8 474 S: A060 OK [RELOCATED] SREP Completed. 476 3.10. Example flows 478 The new command specified in this document allows a client to save 479 significant bandwidth by sending only reference(s) instead of full- 480 blown spam reports that most if the time include the entire message. 481 By doing so, the responsibility of recording metadata and handling 482 the message designated as spam has been shifted to the server side. 483 It is not the purpose of IMAP servers to deal with various aspects of 484 spam reporting, such as creating and storing metadata, making the 485 metadata available when new messages arrive, etc. IMAP servers 486 should take advantage of an aggregator service and perform the 487 exchanges related to spam reporting in the background, delegating the 488 work to the aggregator service. Spam aggregator services are 489 expected to collect and store metadata in very large volumes, 490 evaluate the stored metadata and support queries to decide whether an 491 incoming message is a spam or not. Open Mobile Alliance (OMA) 492 specified the [OMA-SPAMREP] enabler release that supports deploying 493 such aggregator services. 495 The flows in the following sub-sections illustrate informative 496 examples for various scenarios that may be triggered by the SREP 497 command defined in Section 3. 499 3.10.1. The server simply flags a message 501 1. The user finds a voicemail that he/she deems to be spam. 502 2. He invokes the appropriate functions on the client to report the 503 message as spam. 504 3. The client reports the spam using the appropriate command to the 505 server: SREP SET SEQ 10 506 4. The server prepares the message referenced by the command for 507 inquiry. 508 5. The server queries its internal database for precedence. 509 6. The server gets a 'not found' response from the internal 510 database. 511 7. The server queries an external database for precedence, such as 512 an aggregator service based on [OMA-SPAMREP]. 513 8. The server gets a 'not found' response from the external 514 database as well. 515 9. No records of the message are found; the server prepares the 516 message to be recorded for future reference. 517 10. The server reports the message as spam to its internal database. 518 11. The server gets an 'ok' response from the internal database. 520 12. The server reports the message as spam to external database, 521 such as an aggregator service based on [OMA-SPAMREP]. 522 13. The server gets an 'ok' response from the external database. 523 14. The server checks the user's preferences and finds no guidance 524 about handing the spam, so 525 15. ... it checks the service provider policies - and yet again, 526 finds no instructions. 527 16. In the end, lacking any sort of guidance, the end the server 528 stores a keyword for the message, and 529 17. ... informs that client about that using the appropriate 530 response: OK [KEYWORD +$OMAEVVM10-spam-user-identified] 531 Completed. 532 18. The client updates its representation of the voicemail 533 repository and 534 19. ... the message turns red on the user interface. 535 20. The user cheers. 537 User Client Server Server Aggregator 538 DB Service DB 539 |---- | | | | 540 | | 1 | | | | 541 |<--- | | | | 542 | 2 | | | | 543 |--------->| 3 | | | 544 | |--------->| | | 545 | | |---- | | 546 | | | | 4 | | 547 | | |<--- | | 548 | | | 5 | | 549 | | |--------->| | 550 | | | 6 | | 551 | | |<---------| | 552 | | | 7 | 553 | | |-------------------->| 554 | | | 8 | 555 | | |<--------------------| 556 | | |---- | | 557 | | | | 9 | | 558 | | |<--- | | 559 | | | 10 | | 560 | | |--------->| | 561 | | | 11 | | 562 | | |<---------| | 563 | | | 12 | 564 | | |-------------------->| 565 | | | 13 | 566 | | |<--------------------| 567 | | |---- | | 568 | | | | 14 | | 569 | | |<--- | | 570 | | |---- | | 571 | | | | 15 | | 572 | | |<--- | | 573 | | |---- | | 574 | | | | 16 | | 575 | | 17 |<--- | | 576 | |<---------| | | 577 | |---- | | | 578 | | | 18 | | | 579 | 19 |<--- | | | 580 |<---------| | | | 581 |---- | | | | 582 | | 20 | | | | 583 |<--- | | | | 584 | | | | | 586 4. Acknowledgements 588 The author acknowledges and appreciates the work and comments from 589 Josh Soref, Gaelle Martin-Cocher, Suresh Chitturi, Clara Severino and 590 Christophe Le Thierry D'Ennequin. 592 5. IANA Considerations 594 This document constitutes registration of the SREP capability in the 595 imap4-capabilities registry. 597 SREP command directives are registered by publishing a standards 598 track or IESG-approved experimental RFC. The registry is currently 599 located at: http://www.iana.org/assignments/spam-directive-registry 601 SREP command abuse types are registered by publishing a standards 602 track or IESG-approved experimental RFC. The registry is currently 603 located at: http://www.iana.org/assignments/spam-abuse-type-registry 605 SREP command reference types are registered by publishing a standards 606 track or IESG-approved experimental RFC. The registry is currently 607 located at: 608 http://www.iana.org/assignments/spam-reference-type-registry 610 All registries are case insensitive. 612 This document constitutes the following registrations with IANA: 614 IMAP SREP Directive Registry 616 Directive Reference 617 --------- --------- 618 SET [this document] 619 CLEAR [this document] 620 IMAP SREP Abuse Type Registry 622 Abuse Type Reference 623 ---------- --------- 624 1 - Phishing [this document] 625 2 - Malware [this document] 627 IMAP SREP Reference Type Registry 629 Reference Type Reference 630 -------------- --------------- 631 UID [this document] 632 SEQ [this document] 633 URLAUTH [this document] 635 Note to RFC Editor: replace "[this document]" with the RFC number 636 before publication. 638 6. Security Considerations 640 When an aggregator service is actively involved in a deployment, the 641 service provider MUST ensure that: 642 - a mutual trust relation is in place between the IMAP server and 643 the aggregator service, and, 644 - the aggregator service does not leak any information. 646 See additional security considerations in [IMAP4] and [URLAUTH], 647 respectively. 649 7. References 651 7.1. Normative References 653 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 654 Specifications: ABNF", RFC 5234, January 2008. 656 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - 657 VERSION 4rev1", RFC 3501, March 2003. 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) 663 - URLAUTH Extension", RFC 4467, May 2006. 665 [XDASH] Saint-Andre, P., Crocker, D., and M. Nottingham, 666 "Deprecating the "X-" Prefix and Similar Constructs in 667 Application Protocols", RFC 6648, June 2012. 669 7.2. Informative References 671 [OLD-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for 672 the Reporting of Mail System Administrative Messages", 673 RFC 3462, January 2003. 675 [OMA-SPAMREP] Open Mobile Alliance, "Mobile Spam Reporting 1.0, OMA- 676 ERP-SpamRep-V1_0". 678 [REPORT] Kucherawy, M., "The Multipart/Report Content Type for 679 the Reporting of Mail System Administrative Messages", 680 RFC 6522, January 2012. 682 Author's Address 684 Zoltan Ordogh 685 Research In Motion Limited 686 1875 Buckhorn Gate 687 Mississauga, Ontario L4W 5P1 688 Canada 690 Phone: +19056294746x15674 691 Fax: +12892615950 692 EMail: zordogh@rim.com