idnits 2.17.1 draft-santos-smtpgrey-00.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 316 has weird spacing: '...let-alg is th...' -- The document date (October 24, 2011) is 4566 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3463' is defined on line 659, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1651 (Obsoleted by RFC 1869) ** Obsolete normative reference: RFC 4408 (Obsoleted by RFC 7208) ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Santos, Ed. 3 Internet-Draft Santronics Software, Inc. 4 Intended status: Standards Track E. Harris 5 Expires: April 26, 2012 puremagic.com 6 October 24, 2011 8 SMTP Service Extension for Greylisting Operations 9 draft-santos-smtpgrey-00 11 Abstract 13 GREYLIST is a SMTP extension to formalize the widely supported 14 Greylisting mail filtering method and to help support SMTP rejected 15 transports by following a new formal structured 4yz server temporary 16 rejection response by including a retry=time tag string which SMTP 17 clients can use to optimize the rescheduling of the mail delivery 18 attempts. With adoption, network overhead reduction in wasteful mail 19 delivery attempts will be realized. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 26, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Document Conventions . . . . . . . . . . . . . . . . . . . 5 58 1.3. Definitions and Acronyms . . . . . . . . . . . . . . . . . 6 59 1.4. Out of Scope Considerations . . . . . . . . . . . . . . . 6 60 2. Greylisting Basic Framework . . . . . . . . . . . . . . . . . 6 61 2.1. Recording Sender Information (Triplet) . . . . . . . . . . 7 62 2.2. SMTP Server Rejection Points . . . . . . . . . . . . . . . 8 63 2.2.1. Connection Greeting . . . . . . . . . . . . . . . . . 8 64 2.2.2. MAIL FROM . . . . . . . . . . . . . . . . . . . . . . 8 65 2.2.3. RCPT TO . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.2.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 2.3. 4yz Format Structure . . . . . . . . . . . . . . . . . . . 9 68 2.3.1. 421 vs 45z Reply Codes . . . . . . . . . . . . . . . . 11 69 2.4. Recommended Blocking Times . . . . . . . . . . . . . . . . 12 70 3. SMTP Service Keyword . . . . . . . . . . . . . . . . . . . . . 12 71 3.1. SMTP Client/Server Implementation . . . . . . . . . . . . 13 72 3.1.1. SMTP Server Implementation . . . . . . . . . . . . . . 13 73 3.1.2. SMTP Client Implementation . . . . . . . . . . . . . . 13 74 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Appendix A. Additional Greylist Parameters . . . . . . . . . . . 16 82 Appendix B. Augmenting Other Standard Email Filters Methods . . . 16 83 Appendix C. TO DO LIST . . . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 In 2003, a non-IETF technology called GreyListing was invented by 89 Evan Harris [HARRIS] as a very effective method of enhancing the 90 abilities of SMTP [RFC5321] mail systems to limit the amount of 91 unwanted, abusive mail that they receive and deliver to their users. 92 Mail systems supporting GreyListing has grown over the years to 93 become a "pseudo standard" among many SMTP operations. 95 This specification provides a formal IETF specification to the 96 Greylisting framework, learned practices and introduces a SMTP 97 extension to reduce the network, traffic overheads and mail delivery 98 delays associated with SMTP Greylisting operations. 100 1.1. Background 102 Greylisting was originally tested on a few small scale mail hosts 103 (less than 100 users, though with a fairly diverse set of senders 104 from all over the world, and volumes over 10,000 email attempts a 105 day). Currently, Greylisting is in use on many mail servers, 106 including ones processing several millions of messages per day. It 107 was designed to be scalable and marginal impact to both 108 administrators and users, and should be acceptable for use on a wide 109 range of systems. Of course, performance issues are very dependent 110 on implementation details. 112 _How does Greylisting work?_ 114 Greylisting works by leveraging the standard SMTP client design 115 expectation to retry sending mail after an initial 4yz temporary 116 rejection response is issued by the server. When the greylisted 117 recorded SMTP client reschedules and retries the same transaction, 118 the GreyListing server will allow the greylisted recorded sender to 119 continue with the transaction. 121 While the idea of using an intentional 4yz rejection to force SMTP 122 clients to retry sending mail would naturally be considered a radical 123 concept for the IETF purist and most likely would not have been 124 endorsed as an IETF standard protocol, the proof of concept has long 125 been established as a very effective means to control certain types 126 of malicious and abusive mail senders and today, Greylisting is a 127 widely recognized mail filtering method and Greylisting SMTP Servers 128 are widely implemented by many in the IETF mail community. 130 _What sort of mail senders does Greylisting address?_ 132 By leveraging the SMTP retry expectation for clients, Greylisting is 133 very effective against mail senders who anonymously and randomly 134 perform a "Single Shot" mail sending attempt and will never repeat 135 the same transaction after the sender has been initially rejected. 136 The high payoff has been the nearly 100% of all mail senders behaving 137 as "single shot" mail senders are abusive and/or malicious in nature. 139 Greylisting can not address abusive mail senders using compliant SMTP 140 mail clients. However, it has been observed that many abusive mail 141 senders will retry again and often immediately within a short time 142 delay. Hence, the Greylisting concept includes the idea of using a 143 "Blocking Time" factor where a greylisted recorded mail sender is 144 blocked for a certain time period. Only when the blocking time has 145 expired, will the GreyListing server finally allow the mail sender to 146 continue with the transaction. 148 _What sort of impact has Greylisting had with Mail Delivery?_ 150 Greylisting has been designed since its conception to satisfy certain 151 criteria: 153 o Enforce SMTP compliance with expected SMTP retry strategies, 155 o Limit abusive mail senders ability to circumvent the blocking, 157 o Have minimal impact on users, and 159 o Require minimal maintenance at both the user and administrator 160 level. 162 The first immediate impact are the increasing delays in mail delivery 163 due to the wide range in Greylisting blocking time values which can 164 be seconds, minutes to hours. Since SMTP has a standard 165 recommendation to implement a Progressive Retry queuing strategy (see 166 section 4.5.4.1 in RFC5321 [RFC5321]) where the first few attempts 167 have short delays (i.e. two attempts within the first hour) with a 168 progressive back off longer delay before the maximum attempts (i.e. 169 over 4-5 days) are exhausted, there are increasing wasted attempts 170 and foremost higher delays in delivering mail. When a SMTP client 171 implements an initial retry lower than the remote GreyListing Server 172 blocking time, the SMTP client will have increasing wasted attempts 173 overhead. When the SMTP client implements an initial retry delay 174 higher than the remote GreyListing Server blocking time, the SMTP 175 client will have unnecessary wasted mail delays in delivering mail. 177 With the increasing deployment of Greylisting mail servers, the 178 second impact is such that even the SMTP server who does not employ 179 Greylisting, will more than likely increasingly connect to a remote 180 mail server that does employ Greylisting and will experience the 181 temporary rejection overhead requiring additional mail sending 182 retries. 184 The third impact is that many GreyListing servers now use the 185 rejection idea at the connection level using a 421 greeting response 186 which may be a different retry condition than a 45z rejection 187 response issued at the MAIL FROM or DATA state. Since many MTA 188 clients see a 421 as a possible loading limit, it may use this to 189 immediately reschedule a retry using a different MX/IP host.. 191 Overall, Greylisting was designed to address the high abuse of 192 "single shot" anonymous mail senders, however it was done at the 193 expense of legitimate mail senders experiencing wasted mail attempts 194 and increasing delivery delays and with improper GreyListing server 195 and client settings, SMTP clients may now have to revisit their 196 queuing strategies to address the Greylisting overhead related 197 issues. 199 This specification provides insights into preparing a low impact 200 Greylisting Server by providing some recommendations for blocking 201 delays and defining a formal structure GreyListing server to 202 optionally include a suggested retry=time information in the server's 203 4yz temporary text responses. 205 This specification does not attempt to alter existing IETF standard 206 SMTP and non-IETF standard Greylisting protocols other than to 207 provide augmented Greylisting techniques to help alleviate the 208 overhead associated with Greylisting in the client/server SMTP 209 transport process. 211 The Greylisting method specified in this document is a complementary 212 method to any other existing mail filtering control systems, and is 213 not intended as a replacement for those other methods. In fact, it 214 is expected that abusive mail senders will eventually try to minimize 215 the effectiveness of this method of blocking, and Greylisting is 216 designed to limit options available to the mail senders when 217 attempting to do so. The positive outcome of Greylisting is that the 218 only methods of circumventing it will tend to make other mail 219 filtering control techniques just that much more effective (primarily 220 DNS and other methods of blacklisting based on IP address) even after 221 any adaptation by the abusive mail senders has occurred. 223 1.2. Document Conventions 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in RFC 2119 [RFC2119]. 229 1.3. Definitions and Acronyms 231 MTA Mail Transfer Agent. Sender or Receiver of mail. Generally 232 viewed as a router within a MSA intra-network where there is a 233 inherent authentication. 235 MUA Mail User Agent. Online or offline mail reader/writer software. 236 Typically has its own MTA component for sending mail. 238 MSA Mail Submission Agent. Generally associated with a MUA sending 239 message to a ISP or ESP where there is an authorized or 240 authenticated association with the MUA. 242 MDA Mail Destination Agent. Generally associated as the final 243 destination of the message where the message is typically 244 targeted for a local user. If the MDA is going to route the 245 mail, then its behaving more as a MSA or MTA. 247 1.4. Out of Scope Considerations 249 The following are out of scope considerations in this specification: 251 o how Greylisting information is recorded in databases, 253 o what additional mail information is recorded in databases beyond 254 the Triplet recording, and 256 o server reasons for an 4yz response outside a Greylisting reason, 257 such as SMTP Traffic Control concepts. 259 2. Greylisting Basic Framework 261 The basic idea of GreyListing is: 263 1. MTA Client initiates a mail delivery attempt to a remote 264 GreyListing compliant mail receiver (MDA), 266 2. The GreyListing Server collects first time session information 267 about the sender such as connection IP, MAIL FROM and RCPT TO 268 called the Triplet. 270 3. If the Triplet was never recorded before, the Triplet is recorded 271 and a 4yz rejection server response with a recommended retry=time 272 hint is issued where the time reflects the blocking time the 273 sender can attempt again and proceed with the transaction. 275 4. If the Triplet was recorded, a check is performed to determine if 276 the blocking time has expired. If not, another 4yz rejection 277 response with a new retry=time hint reflecting the new blocking 278 time is issued. 280 5. When the sender tries again with the same recorded information 281 after the blocking time has expired, then the sender has passed 282 the server's greylist test and is allowed to proceed to send the 283 mail. 285 One of the essential goals of this specification is to reduce the 286 network and communications overhead in sender attempts and to reduce 287 mail delivery delays by implementing the server retry=time hints in 288 the 4yz greylist responses. 290 2.1. Recording Sender Information (Triplet) 292 In the classic Greylisting protocol described in HARRIS [HARRIS], a 293 Triplet is the unique combination of connection IP, the reverse 294 address (MAIL FROM) and the forwarding address (RCPT TO) used to 295 track the sender. When the sender retries with the same triplet, a 296 lookup can be perform to determine its Greylist status. However, 297 depending on the Greylist server implementation, it can reject at 298 different points in the SMTP state machine and may not collect the 299 entire triplet information. 301 While it is out of scope how a SMTP session Triplet is collected and 302 what SMTP session data points it contains, the key point is a 303 specific Triplet used to track the MTA for an initial transaction 304 attempt and subsequent retries in order to control it during the 305 Greylisting Server blocking time. 307 The following is an implementation example for triplet recording: 309 Sender-Triplet = triplet-alg(CIP, RPATH, FPATH) 311 where 313 CIP is the connection IP address of the client, 314 RPATH is the MAIL FROM reverse-address or domain, 315 FPATH is the RCPT TO forwarding address 316 triplet-alg is the algorithm used to generate a database tracking key 318 One example of a triplet-alg is using a standard hashing algorithm as 319 such SHA1 with BASE32 encoding. 321 BASE64(SHA1(CIP, RPATH, FPATH)) 323 Other tracking methods such as index keys in SQL database tables are 324 often common with Greylisting server implementations. This 325 specification does not define an formal triple-alg method. Any SMTP 326 data can be used as long as it represents Greylisting servers method 327 for consistent tracking transactions , its initial rejection and 328 subsequent acceptance with expected retries. 330 2.2. SMTP Server Rejection Points 332 Greylisting assumes a triplet recording (IP, FROM and TO), however a 333 Greylisting server can reject at any point in the SMTP state machine 334 by recording less information about the sender. This specification 335 hopes to assist the MTA to determine when a temporary rejection is 336 greylist related apart from other reasons which can be a factor in 337 how an MTA client will reschedule new attempts. 339 2.2.1. Connection Greeting 341 Many SMTP servers will use a 421 response during the greeting as a 342 way to limit connections and control load. 344 A GreyListing server deciding to greylist a client at the connection 345 greeting MUST use a 421 reply code and SHOULD include a retry=time 346 hint as part of the text response. 348 The retry=time hint will help the MTA decide what sort of rejection 349 was imposed by distinguishing between loading limit or greylist 350 rejection. Without the retry=hint, a MTA can try an alternative MX 351 immediately (without delay) and the rejection may still occur. 352 Including the retry=hint will assist the MTA to better reschedule the 353 retry. 355 A GreyListing Server rejecting at the connection level is recording 356 only the connection IP to track the sender. 358 2.2.2. MAIL FROM 360 A GreyListing server deciding to greylist a client as a response to 361 the MAIL FROM command SHOULD use a 451 reply code and SHOULD include 362 a retry=time hint as part of the text response. The retry=time hint 363 will help the MTA decide when a new attempt should be attempted. 365 A GreyListing Server rejecting at the MAIL FROM is recording the 366 connection IP and MAIL FROM sender address. 368 2.2.3. RCPT TO 370 A GreyListing server deciding to greylist a client as a response to 371 the RCPT TO command SHOULD use a 451 reply code and SHOULD include a 372 retry=time hint as part of the text response. The retry=time hint 373 will help the MTA decide when a new attempt should be attempted. 375 A GreyListing Server rejecting at the RCPT TO is recording the 376 connection IP, MAIL FROM and RCPT TO addresses. 378 2.2.4. DATA 380 A GreyListing server deciding to greylist a client as a response to 381 the DATA End of Data (EOD) SHOULD use a 451 reply code and SHOULD 382 include a retry=time hint as part of the text response. The 383 retry=time hint will help the MTA decide when a new attempt should be 384 attempted. 386 Generally, a GreyListing server will allow the DATA command in order 387 to capture the actual RFC5322 [RFC5322] message before a greylist 388 response is issued. The reasons are beyond the scope of this 389 specification. 391 A GreyListing Server rejecting at the DATA may be recording more 392 information besides the triplet information, i.e. Message-Id header. 394 2.3. 4yz Format Structure 396 Many current Greylisting Servers use varying text responses with 397 informal language try again time text information. The following are 398 known forms of existing Greylisting Servers which expose a form of 399 time hints within the text response: 401 421 This server implements greylisting, please try again in # 402 seconds 404 450 4.7.1 : Recipient address rejected: Greylisted for # 405 minutes 407 450 4.7.1 : Recipient address rejected: Greylisted for # 408 seconds 410 451 4.7.1 Greylisting in action, please come back in HH:MM:SS 411 451 Greylisted for # seconds 413 451 Greylisted, please try again in # seconds 415 451 Greylisting enabled, try again in # minutes 417 It is possible for existing MTA clients currently supporting the 418 parsing and extraction of the time factor with the known informal 419 responses from existing Greylisting servers and this specification 420 does not attempt to limit specific MTA client implementations which 421 may already exist. 423 This specification offers a formal structure the Greylisting Server 424 MAY use within their 4yz responses and the MTA client MAY use to 425 detect and extract the retry information consistently without error 426 using a single format within the 4yz response containing the 427 following structured "retry=" tag: 429 retry=[DD-]HH:MM:SS 431 The [DD-]HH:MM:SS part is the time delay the MTA SHOULD wait before 432 attempting to send the mail again. It is not a specific time of day, 433 but rather the amount of GreyListing Server blocking time expected by 434 the server before the client SHOULD try again. An MTA client 435 ignoring this information, attempting again before the blocking time 436 has expired, is a wasted attempt and can delay the mail delivery well 437 beyond the GreyListing server blocking time. 439 In ABNF, GreyListing server response syntax is: 441 Reply-Line = ( Reply-Code [ SP textstring [SP retrytime] ] CRLF ) / 442 ( Reply-Code "-" [ SP textstring ] CRLF 443 *( Reply-Code "-" [ SP textstring ] CRLF ) 444 Reply-Code [ SP textstring [SP retrytime ] ] CRLF ) 446 textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII 448 retrytime = "retry=" [days "-"] hours ":" minutes ":" seconds 450 days = 2DIGIT ; 00-99 452 hours = 2DIGIT ; 00-23 454 minutes = 2DIGIT ; 00-59 456 seconds = 2DIGIT ; 00-59 458 Reply-code = "421 / 450 / 451" 459 Examples: 460 Single line responses: 462 451 4.7.1. Greylist enabled. retry=00:02:00 464 451 Temporary rejection. retry=00:00:30 466 450 Temporary Greylist rejection. retry=01-00:10:00 468 451 retry=01:00:00 Try again at the suggested retry time. 470 421 Your connection is greylisted. Please try again later (retry=00:01:00) 472 Multiple lines response: 474 451-Greylisted. See policy http://example.com/GreyList-Policy 475 451 Retry=00:02:00 477 The retrytime MUST be provided in the first and only line for a 478 single line response or the last line for a multiple line response. 480 2.3.1. 421 vs 45z Reply Codes 482 GreyListing Servers may issue 421 or 45z responses at any point in 483 the SMTP session. However, RFC5321 recommends 421 be used at the 484 greeting and for server interruption events. This specification 485 recommends keeping with the SMTP RFC5321 recommendations for 421 and 486 only use 45z for non-Greeting rejections responses. All SMTP 487 compliant MTA will always follow 4yz for scheduling a retry, but the 488 difference is a 421 can trigger an immediate retry attempt without 489 delay at the next MX IP address, if any, where a GreyListing server 490 will most likely reject the new attempt due to the blocking time. 492 IMPLEMENTATION NOTE: RFC5321 recommends a specific 450 reply code 493 for temporary rejections related to local policy reasons. HARRIS 494 used 451 to make it distinctive as a greylist response. This 495 specification recommends using 450, however, it is recognized that 496 many existing Greylisting servers already use 451 as the reply 497 code. MTA MUST NOT depend on 450 or 451 to make retry decisions. 498 All 4yz responses MUST be interpreted as a temporary rejection. 500 When the retry=time hint is implemented in the response, compliant 501 MTA will be able to determine the difference between a load 502 restriction and a greylisted rejection to appropriately reschedule a 503 new attempt at the GreyListing server's suggested time hint. 505 2.4. Recommended Blocking Times 507 This specification does not impose any specific blocking delay value 508 when 4yz rejections are issues by servers, other than to suggest that 509 timely delivery of mail to users remains to be an inherent 510 expectation by SMTP clients and SMTP servers. 512 The GreyListing server blocking times vary greatly in practice, but 513 there is empirical evidence a majority of systems use a 1 to 5 minute 514 delay. Many use 10 minutes or 15 minutes. Many use less than 1 515 minute, like 30 to 55 seconds. The latter tend to be systems who 516 wish to lower impact with immediate and timely mail delivery delays. 517 However, this can be wasteful attempts when the MTA is operating 518 blindly with unknown blocking times imposed by Greylisting Servers. 520 When it comes to a recommendation, there is no GreyListing logic to 521 suggest that long delays be use when the goal of Greylisting senders 522 is to address the anonymous random "single shot" senders where their 523 triplet will never be the same. Delaying good SMTP senders for 524 extended unreasonable periods defeats the goal of Greylisting. 526 Since there is no clear recommendation for a blocking time delay 527 (other than to keep it short as possible), this specification offers 528 the retry=time hint as a method to alleviate the uncertainty in the 529 wasted attempts and delays in timely mail delivery. 531 3. SMTP Service Keyword 533 GREYLIST is a new ESMTP [RFC1651] service keyword. The GreyListing 534 Server MAY add this optional keyword as a response to EHLO command. 535 EHLO response Format: 537 250-GREYLIST [server-options] 539 If the GREYLIST keyword is presented as part of the EHLO response, it 540 means the server has Greylisting implemented and 4yz responses are 541 possible due to a Greylist decision by the server to impose on the 542 client. The keyword is not necessary and the server can still 543 provide 4yz temporary rejections. 545 The optional server-options provides space separated attributes 546 reflecting the server Greylisting information the server wishes to 547 expose. Currently the following optional attributes are defined: 549 RETRY means that 4yz responses related to GreyListing will have 550 retry=time information. The attribute is optional and not 551 required to issue 4yz responses with retry=time hints. 553 3.1. SMTP Client/Server Implementation 555 3.1.1. SMTP Server Implementation 557 The SMTP server MAY add support for the GREYLIST keyword in the EHLO 558 response. 560 The SMTP Server MAY add "retry=" tag support to 4yz responses. 562 3.1.2. SMTP Client Implementation 564 The SMTP client MAY use the GREYLIST keyword exposed by the EHLO 565 response. 567 The SMTP client MAY support the usage of the "retry=" tag in 4yz 568 responses and are not obligated to honor the SMTP servers recommended 569 retry delay. 571 4. Examples 573 Example with no extended codes: 575 S: serverdomain.com, welcome ESMTP v2.0 576 C: EHLO mail.clientdomain.com 577 S: 250-GREYLIST 578 S: 250-HELP 579 C: MAIL FROM: 580 S: 250 User OK 581 C: RCPT TO: 582 S: 451 Greylisted. Please Disconnect now. retry=00:05:00 583 C: QUIT 584 S: 221 Goodbye 586 Example with extended codes: 588 S: serverdomain.com, welcome ESMTP v2.0 589 C: EHLO mail.clientdomain.com 590 S: 250-ENHANCEDSTATUSCODES 591 S: 250-GREYLIST 592 S: 250-HELP 593 C: MAIL FROM: 594 S: 250 2.1.0 User OK 595 C: RCPT TO: 596 S: 450 4.7.1 Greylisted. Please Disconnect now. retry=2 minutes 597 C: QUIT 598 S: 221 Goodbye 600 Example of connection rejection: 602 S: 421 4.7.1 Greylist enabled. Try again later. retry=5 minutes 604 5. IANA Considerations 606 This document makes no request of IANA. 608 Note to RFC Editor: this section may be removed on publication as an 609 RFC. 611 6. Security Considerations 613 One possible security concern envisioned is a DoS attack when 614 retry=time information is exposed by the GreyListing server where by 615 a malicious sender may attempt to overwhelm the server during the 616 server's retry time exposing a time window when the server has 617 indicated system availability for mail acceptability. However, since 618 security measures to mitigate DoS is a required operational factor, a 619 GreyListing Server will inherently be prepared for DoS attacks with 620 managed loading limits with or without retry=time Greylist responses, 621 thus there is no expected technical concern by exposing Greylist 622 retry=time hints. With or without this specification, all SMTP 623 servers SHOULD be prepared for DoS attacks of all kinds. 625 Another arguable security concern is related to the idea a formal 626 SMTP extension can possibly lower the effectiveness of Greylisting 627 when abusive mail senders adapt to the server's suggested retry 628 times. This concern does not seem to have weight since adaptation 629 can occur with or without the extension simply by complying to SMTP 630 retry recommendations. Greylisting remains effective because legacy 631 abusive systems do not adapt. In fact, a retry=time hint 632 implementation provides a means to help avoid abusive redundancy and 633 reduced random overloading of connections at unmanaged random times 634 by MTA clients of all flavors. A retry=time hint may actually be 635 purposely calculated to provide a time window when there is less 636 loading for legitimate and abusive senders. 638 7. Acknowledgements 640 The following individuals contributed input and guidance in the 641 production of this specification: 643 Tim Kehres, John Klensin, S. Moonesamy, Keith Moore, Paul Smith. 645 Please note acknowledgement does not imply any specific endorsement 646 of this specification other than they have provided important pros 647 and cons input which helped mold the specification. 649 8. References 651 8.1. Normative References 653 [RFC1651] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 654 Crocker, "SMTP Service Extensions", RFC 1651, July 1994. 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, March 1997. 659 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 660 RFC 3463, January 2003. 662 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 663 for Authorizing Use of Domains in E-Mail, Version 1", 664 RFC 4408, April 2006. 666 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 667 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 668 Signatures", RFC 4871, May 2007. 670 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 671 October 2008. 673 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 674 October 2008. 676 8.2. Informative References 678 [HARRIS] Harris, E., "The Next Step in the Spam Control War: 679 Greylisting", 2003, . 682 Appendix A. Additional Greylist Parameters 684 Greylisting Servers vary in ways which include what factors are used 685 in tracking a sender and how accepted senders are temporarily or 686 permanently white listed. 688 Whitelist Record Expiration Whitelist Record Expiration is used to 689 allow a previous greylisted sender a time window where it can be 690 temporarily or permanently whitelisted depending on the 691 implementation. This is a local policy consideration, however, 692 it should be noted that redundant greylisting of a common MTA is 693 not considered reasonable. At some point, the MTA is a trusted 694 source of mail and the MTA SHOULD be permanently whitelisted. 695 The main idea with a temporary whitelisting is that its possible 696 a future transaction can be a compromised user transaction. 698 Class C IP Address Tracking Class C IP Address Tracking allows a 699 Greylisting server to control a greylisted MTA who retries using 700 a different class C address. This is typical in larger outbound 701 farms where many machines are used to send mail. If Class C is 702 not considered, MTAs using a different IP will be unnecessarily 703 rejected after delaying within a blocked time. 705 Appendix B. Augmenting Other Standard Email Filters Methods 707 It is possible for a GreyListing server to combine other mail 708 filtering techniques, methods and session information to determine if 709 a sender should be greylisted. While the augmentation of these 710 additional methods is out of the scope, the following are some 711 suggestions that may help minimize a GreyListing Server impact. on 712 MTAs. 714 SPF SPF (Sender Policy Framework) [RFC4408] can be used to help 715 validate a sender's IP association with the return path domain. 716 A SPF SOFTFAIL or FAIL (if not used for rejection) result could 717 be used to help decide when Greylisting should be employed on 718 the sender. While a PASS result is not a trusted condition, a 719 local policy may use a PASS to skip Greylisting mail checks. 721 DKIM DKIM (Domain Key Identified Mail) [RFC4871] can be used to help 722 authenticate the transactions from trusted DKIM mail signers. 723 If the signer is considered is trusted source, this can help 724 eliminate the need to greylist the sender. 726 Appendix C. TO DO LIST 728 1. Possible section showing real proof of concept examples. 730 2. Review the SMTP Service Keyword and determine how SHOULD|MAY|MUST 731 is applied. 733 3. Address concerns the SMTP extension attempts to modifed RFC5321. 735 There is no intent to do so - its an extension and its very 736 nature, optional. This extension could only alter a Greylisting 737 Server implemenation for 4yz text responses which is out of scope 738 in RFC5321 or the implementation for a MTA retry and queing 739 method where the extact methods used are aleady out of scope in 740 RFC5321. 742 Authors' Addresses 744 Hector Santos (editor) 745 Santronics Software, Inc. 746 15600 SW 158 ST Suite #306 747 Homestead, Florida, FL 33033 748 United States of America 750 Email: hsantos@santronics.com 751 URI: http://www.santronics.com 753 Evan Harris 754 puremagic.com 756 Email: eharris@puremagic.com