idnits 2.17.1 draft-ordogh-spam-reporting-using-imap-04.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 (March 11, 2013) is 4054 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IMAP' is mentioned on line 423, 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 March 11, 2013 5 Expires: September 12, 2013 7 Spam reporting using IMAP: SREP 8 draft-ordogh-spam-reporting-using-imap-04 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 September 12, 2013. 48 Copyright Notice 49 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . 16 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 using an IMAP MOVE 297 [IMAPMOVE] command. 298 - The DELETE the client requests that the message should be 299 deleted. The server MUST delete the message as if another client 300 performed this action. 301 The server MUST ignore the destination mailbox in case it is nil, or, 302 the request action is KEYWORD or DELETE. It is assumed that the 303 server is pre-configured with the location where user's spam messages 304 are stored. If the server is not configured with such information 305 and the destination mailbox in a RELOCATE action is nil, or, 306 destination mailbox in a RELOCATE action is otherwise inaccessible to 307 the user (does not exist, insufficient permission, etc) the the 308 server MUST reject the request (see BAD response in Section 3.6). 309 NOTE: While the DELETE action does not seem appropriate in case the 310 directive argument is CLEAR, it is permitted. The formal syntax of 311 the request action argument is defined in Section 3.7. 313 3.6. Responses and Results 315 The SREP command MAY result in system flag changes, keyword changes, 316 message relocation, message removal, or a combination of these. 318 The result of the command MUST be either OK, NO or BAD: 319 - The OK result MUST be returned only in case the server parsed 320 and completed the command successfully. 321 - The NO result MUST be returned only in case the server parsed 322 the command successfully, but there is a problem with the 323 referenced message(s) that prevents the server from completing the 324 requested actions, such as one or more messages do not exist on 325 the server, one or more messages are not properly authorized by 326 URLAUTH, etc. 327 - The BAD result MUST be returned only in case the server cannot 328 parse the command, or a configuration error is preventing the 329 server from completing the requested actions. 331 When the result is OK, the response to a SET directive MUST be either 332 KEYWORD, RELOCATE, RELOCATED, DELETE, or DELETED. 334 When the result is OK, the response to a CLEAR directive MUST be 335 either KEYWORD, RELOCATE, or RELOCATED. 337 The server responses are: 339 - The KEYWORD response occurs in case this specific action has 340 been explicitly requested by the client, or, in case the server 341 decided that only the keywords should be updated either because it 342 does not wish to give any recommendation to the client (RELOCATE 343 or DELETE), or, because it does not have sufficient information 344 either internally, or, from the spam aggregator service that it is 345 configured to use. 346 - The RELOCATE response occurs in case the server decided that the 347 message should be relocated, however leaves this action to the 348 client. The client MAY decide what to do with the message. 349 - The RELOCATED response occurs in case this specific action has 350 been explicitly requested by the client, or, in case the server 351 decided that the message should be relocated and it performed 352 relocation of the message to the appropriate location before the 353 response was sent. The server MUST relocate the message by 354 copying the message to the appropriate location and removing the 355 original as if another connected client requested this action 356 using an IMAP MOVE [IMAPMOVE] command. 357 - The DELETE response occurs in case the server decided that the 358 message should be deleted, however leaves this action to the 359 client. The client MAY decide what to do with the message. 360 - The DELETED response occurs in case this specific action has 361 been explicitly requested by the client, or, in case the server 362 decided that the message should be deleted, and performed deletion 363 of the message before the response was sent. The server MUST 364 delete the message as if another client performed this action. 366 The KEYWORD, RELOCATE and DELETE responses MUST include the list of 367 flags/keywords that have been added or removed. Added keywords MUST 368 be prefixed with a plus sign ('+'), while removed keywords MUST be 369 prefixed with a minus sign ('-'). The RELOCATED and DELETED 370 responses MUST NOT include keywords. The formal syntax of the 371 actions is defined in Section 3.7. 373 3.7. Formal Syntax 375 This document extends the formal syntax defined in [IMAP4] using the 376 Augmented Backus-Naur Form (ABNF) notation specified in [ABNF]. 377 Note: all string literals are case insensitive. 379 srep-command = "SREP" SP directive *1(SP abuse-type) SP \ 380 reference *1(SP part-id-list) \ 381 *1(SP request-action) 382 directive = "SET" / "CLEAR" / directive-ext 383 directive-ext = atom 384 ; It is not required that new directives 385 ; begin with "X-", see [XDASH] 386 abuse-type = "AT" SP abuse-type-id 387 abuse-type-id = 1*DIGIT 388 ; no leading zeroes or signs 389 ; New abuse types MUST be registered with 390 ; IANA as standard or standards-track 391 reference = reference-type SP reference-value 392 reference-type = "UID" / "SEQ" / "URLAUTH" / reference-type-ext 393 reference-type-ext = atom 394 ; It is not required that new reference types 395 ; begin with "X-", see [XDASH] 396 reference-value = uniqueid / ; see [IMAP] 397 sequence-set / ; see [IMAP] 398 authorized-url / ; see [URLAUTH] 399 reference-value-ext 400 authorized-url = authimapurlfull / ; see [URLAUTH] 401 authimapurlrump ; see [URLAUTH] 402 reference-value-ext = atom 403 ; New reference values MUST correspond to 404 ; reference-type-ext 405 part-id-list = "(" part-id *(SP part-id) ")" 406 part-id = header-id / body-id 407 header-id = "header." header-fld-name 408 ; see header-fld-name in [IMAP] 409 body-id = "body" *("." 1*DIGIT) 410 ; no leading zeroes or signs in numberic part 411 request-action = "DO" SP req-action *1(SP destination-box) 412 req-action = "KEYWORD" / 413 "RELOCATE" / 414 "DELETE" 415 destination-box = mailbox / nil 416 resp-text-code = resp-spam-actions ; responses specific to 417 ; this command, extending 418 ; existing resp-text-code 419 ; defined in [IMAP] 420 resp-spam-actions = "KEYWORD" flag-list / ; see flag-list in [IMAP] 421 "RELOCATE" flag-list /; see flag-list in [IMAP] 422 "RELOCATED" / 423 "DELETE" flag-list / ; see flag-list in [IMAP] 424 "DELETED" 426 3.8. Examples to report spam 428 Report single message as spam; no identified parts; server only flags 429 the message and hints that it should be moved: 430 C: Z020 SREP SET SEQ 10 431 S: Z020 OK [RELOCATE +$OMAEVVM10-spam-user-identified] SREP 432 Completed. 434 Report single message as spam; header and body identified; server 435 adds the appropriate flags and hints that it should be deleted: 436 C: Z040 SREP SET SEQ 9 (header.from body.2) 437 S: Z040 OK [DELETE (+$OMAEVVM10-spam-user-identified-field.from 438 +$OMAEVVM10-spam-user-identified-body.2)] SREP Completed. 440 Report single message as spam; no identified parts; server moves the 441 message (may clear/set flags too, but that is irrelevant because the 442 client will need to reconcile anyway). 443 C: Z060 SREP SET SEQ 8 444 S: Z060 OK [RELOCATED] SREP Completed. 446 Report single message as spam; no identified parts; server deletes 447 the message. 448 C: Z080 SREP SET SEQ 6 449 S: Z080 OK [DELETED] SREP Completed. 451 Report single message as spam; no identified parts; client requests 452 explicitly to delete the message, server deletes the message as the 453 client requested. 454 C: Z100 SREP SET SEQ 4 DO DELETE NIL 455 S: Z100 OK [DELETED] SREP Completed. 457 3.9. Examples to report messages as no longer spam 459 Report single message as no longer spam; no identified parts; server 460 only clears the appropriate flags from the message. 461 C: Z020 SREP CLEAR SEQ 10 462 S: A020 OK [KEYWORD -$OMAEVVM10-spam-user-identified] SREP 463 Completed. 465 Report single message as no longer spam; earlier the header and body 466 were identified as spam; the server clears the appropriate flags. 467 C: Z040 SREP CLEAR SEQ 9 468 S: A040 OK [KEYWORD (-$OMAEVVM10-spam-user-identified-field.from 469 -$OMAEVVM10-spam-user-identified-body.2)] SREP Completed. 471 Report single message as no longer spam; no identified parts; server 472 moves the message (may set/clear flags, too but that is irrelevant 473 because the client will need to reconcile anyway). 475 C: Z060 SREP CLEAR SEQ 8 476 S: A060 OK [RELOCATED] SREP Completed. 478 3.10. Example flows 480 The new command specified in this document allows a client to save 481 significant bandwidth by sending only reference(s) instead of full- 482 blown spam reports that most if the time include the entire message. 483 By doing so, the responsibility of recording metadata and handling 484 the message designated as spam has been shifted to the server side. 485 It is not the purpose of IMAP servers to deal with various aspects of 486 spam reporting, such as creating and storing metadata, making the 487 metadata available when new messages arrive, etc. IMAP servers 488 should take advantage of an aggregator service and perform the 489 exchanges related to spam reporting in the background, delegating the 490 work to the aggregator service. Spam aggregator services are 491 expected to collect and store metadata in very large volumes, 492 evaluate the stored metadata and support queries to decide whether an 493 incoming message is a spam or not. Open Mobile Alliance (OMA) 494 specified the [OMA-SPAMREP] enabler release that supports deploying 495 such aggregator services. 497 The flows in the following sub-sections illustrate informative 498 examples for various scenarios that may be triggered by the SREP 499 command defined in Section 3. 501 3.10.1. The server simply flags a message 503 1. The user finds a voicemail that he/she deems to be spam. 504 2. He invokes the appropriate functions on the client to report the 505 message as spam. 506 3. The client reports the spam using the appropriate command to the 507 server: SREP SET SEQ 10 508 4. The server prepares the message referenced by the command for 509 inquiry. 510 5. The server queries its internal database for precedence. 511 6. The server gets a 'not found' response from the internal 512 database. 513 7. The server queries an external database for precedence, such as 514 an aggregator service based on [OMA-SPAMREP]. 515 8. The server gets a 'not found' response from the external 516 database as well. 517 9. No records of the message are found; the server prepares the 518 message to be recorded for future reference. 519 10. The server reports the message as spam to its internal database. 520 11. The server gets an 'ok' response from the internal database. 522 12. The server reports the message as spam to external database, 523 such as an aggregator service based on [OMA-SPAMREP]. 524 13. The server gets an 'ok' response from the external database. 525 14. The server checks the user's preferences and finds no guidance 526 about handing the spam, so 527 15. ... it checks the service provider policies - and yet again, 528 finds no instructions. 529 16. In the end, lacking any sort of guidance, the end the server 530 stores a keyword for the message, and 531 17. ... informs that client about that using the appropriate 532 response: OK [KEYWORD +$OMAEVVM10-spam-user-identified] 533 Completed. 534 18. The client updates its representation of the voicemail 535 repository and 536 19. ... the message turns red on the user interface. 537 20. The user cheers. 539 User Client Server Server Aggregator 540 DB Service DB 541 |---- | | | | 542 | | 1 | | | | 543 |<--- | | | | 544 | 2 | | | | 545 |--------->| 3 | | | 546 | |--------->| | | 547 | | |---- | | 548 | | | | 4 | | 549 | | |<--- | | 550 | | | 5 | | 551 | | |--------->| | 552 | | | 6 | | 553 | | |<---------| | 554 | | | 7 | 555 | | |-------------------->| 556 | | | 8 | 557 | | |<--------------------| 558 | | |---- | | 559 | | | | 9 | | 560 | | |<--- | | 561 | | | 10 | | 562 | | |--------->| | 563 | | | 11 | | 564 | | |<---------| | 565 | | | 12 | 566 | | |-------------------->| 567 | | | 13 | 568 | | |<--------------------| 569 | | |---- | | 570 | | | | 14 | | 571 | | |<--- | | 572 | | |---- | | 573 | | | | 15 | | 574 | | |<--- | | 575 | | |---- | | 576 | | | | 16 | | 577 | | 17 |<--- | | 578 | |<---------| | | 579 | |---- | | | 580 | | | 18 | | | 581 | 19 |<--- | | | 582 |<---------| | | | 583 |---- | | | | 584 | | 20 | | | | 585 |<--- | | | | 586 | | | | | 588 4. Acknowledgements 590 The author acknowledges and appreciates the work and comments from 591 Josh Soref, Gaelle Martin-Cocher, Suresh Chitturi, Clara Severino and 592 Christophe Le Thierry D'Ennequin. 594 5. IANA Considerations 596 This document constitutes registration of the SREP capability in the 597 imap4-capabilities registry. 599 SREP command directives are registered by publishing a standards 600 track or IESG-approved experimental RFC. The registry is currently 601 located at: http://www.iana.org/assignments/spam-directive-registry 603 SREP command abuse types are registered by publishing a standards 604 track or IESG-approved experimental RFC. The registry is currently 605 located at: http://www.iana.org/assignments/spam-abuse-type-registry 607 SREP command reference types are registered by publishing a standards 608 track or IESG-approved experimental RFC. The registry is currently 609 located at: 610 http://www.iana.org/assignments/spam-reference-type-registry 612 All registries are case insensitive. 614 This document constitutes the following registrations with IANA: 616 IMAP SREP Directive Registry 618 Directive Reference 619 --------- --------- 620 SET [this document] 621 CLEAR [this document] 622 IMAP SREP Abuse Type Registry 624 Abuse Type Reference 625 ---------- --------- 626 1 - Phishing [this document] 627 2 - Malware [this document] 629 IMAP SREP Reference Type Registry 631 Reference Type Reference 632 -------------- --------------- 633 UID [this document] 634 SEQ [this document] 635 URLAUTH [this document] 637 Note to RFC Editor: replace "[this document]" with the RFC number 638 before publication. 640 6. Security Considerations 642 When an aggregator service is actively involved in a deployment, the 643 service provider MUST ensure that: 644 - a mutual trust relation is in place between the IMAP server and 645 the aggregator service, and, 646 - the aggregator service does not leak any information. 648 See additional security considerations in [IMAP4] and [URLAUTH], 649 respectively. 651 7. References 653 7.1. Normative References 655 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 656 Specifications: ABNF", RFC 5234, January 2008. 658 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - 659 VERSION 4rev1", RFC 3501, March 2003. 661 [IMAPMOVE] Gulbrandsen, A. and N. Freed, "Internet Message Access 662 Protocol (IMAP) - MOVE Extension", RFC 6851, 663 January 2013. 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) 669 - URLAUTH Extension", RFC 4467, May 2006. 671 [XDASH] Saint-Andre, P., Crocker, D., and M. Nottingham, 672 "Deprecating the "X-" Prefix and Similar Constructs in 673 Application Protocols", RFC 6648, June 2012. 675 7.2. Informative References 677 [OLD-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for 678 the Reporting of Mail System Administrative Messages", 679 RFC 3462, January 2003. 681 [OMA-SPAMREP] Open Mobile Alliance, "Mobile Spam Reporting 1.0, OMA- 682 ERP-SpamRep-V1_0". 684 [REPORT] Kucherawy, M., "The Multipart/Report Content Type for 685 the Reporting of Mail System Administrative Messages", 686 RFC 6522, January 2012. 688 Author's Address 690 Zoltan Ordogh 691 Research In Motion Limited 692 1875 Buckhorn Gate 693 Mississauga, Ontario L4W 5P1 694 Canada 696 Phone: +19056294746x15674 697 Fax: +12892615950 698 EMail: zordogh@blackberry.com