idnits 2.17.1 draft-santos-smtpgrey-02.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 2 instances of too long lines in the document, the longest one being 9 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 349 has weird spacing: '...let-alg is th...' -- The document date (April 26, 2012) is 4381 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 748, but no explicit reference was found in the text == Unused Reference: 'RFC4871' is defined on line 755, 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) ** Obsolete normative reference: RFC 5672 (Obsoleted by RFC 6376) Summary: 5 errors (**), 0 flaws (~~), 5 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: October 28, 2012 puremagic.com 6 April 26, 2012 8 SMTP Service Extension for Greylisting Operations 9 draft-santos-smtpgrey-02 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-delay" tag string which 17 SMTP clients can use to optimize the rescheduling of the mail 18 delivery attempts. With adoption, network overhead reduction in 19 wasteful mail 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 October 28, 2012. 38 Copyright Notice 40 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . 6 58 1.3. Definitions and Acronyms . . . . . . . . . . . . . . . . . 6 59 1.4. Syntactic Notation . . . . . . . . . . . . . . . . . . . . 6 60 1.5. Out of Scope Considerations . . . . . . . . . . . . . . . 6 61 2. Greylisting Basic Framework . . . . . . . . . . . . . . . . . 7 62 2.1. Greylist Recording Parameters . . . . . . . . . . . . . . 7 63 2.2. Recording Sender Information (Triplet) . . . . . . . . . . 8 64 2.3. SMTP Server Rejection Points . . . . . . . . . . . . . . . 9 65 2.3.1. Connection Greeting . . . . . . . . . . . . . . . . . 9 66 2.3.2. EHLO/HELO . . . . . . . . . . . . . . . . . . . . . . 9 67 2.3.3. MAIL FROM . . . . . . . . . . . . . . . . . . . . . . 9 68 2.3.4. RCPT TO . . . . . . . . . . . . . . . . . . . . . . . 10 69 2.3.5. DATA . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 2.4. 4yz Format Structure . . . . . . . . . . . . . . . . . . . 10 71 2.4.1. 421 vs 45z Reply Codes . . . . . . . . . . . . . . . . 13 72 2.5. Recommended Blocking Times . . . . . . . . . . . . . . . . 13 73 3. SMTP Service Keyword . . . . . . . . . . . . . . . . . . . . . 14 74 3.1. SMTP Client/Server Implementation . . . . . . . . . . . . 14 75 3.1.1. SMTP Server Implementation . . . . . . . . . . . . . . 14 76 3.1.2. SMTP Client Implementation . . . . . . . . . . . . . . 14 77 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 84 Appendix A. Additional Greylist Parameters . . . . . . . . . . . 18 85 Appendix B. Augmenting Other Standard Email Filters Methods . . . 19 86 Appendix C. TO DO LIST . . . . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 In 2003, a non-IETF technology called GreyListing was invented by 92 Evan Harris [HARRIS] as a very effective method of enhancing the 93 abilities of SMTP [RFC5321] mail systems to limit the amount of 94 unwanted, abusive mail that they receive and deliver to their users. 95 Mail systems supporting GreyListing has grown over the years to 96 become a "pseudo standard" among many SMTP operations. 98 This specification provides a formal IETF specification to the 99 Greylisting framework, learned practices and introduces a SMTP 100 extension to reduce the network, traffic overheads and mail delivery 101 delays associated with SMTP Greylisting operations. 103 1.1. Background 105 Greylisting was originally tested on a few small scale mail hosts 106 (less than 100 users, though with a fairly diverse set of senders 107 from all over the world, and volumes over 10,000 email attempts a 108 day). Currently, Greylisting is in use on many mail servers, 109 including ones processing several millions of messages per day. It 110 was designed to be scalable and marginal impact to both 111 administrators and users, and should be acceptable for use on a wide 112 range of systems. Of course, performance issues are very dependent 113 on implementation details. 115 _How does Greylisting work?_ 117 Greylisting works by leveraging the standard SMTP client design 118 expectation to retry sending mail after an initial 4yz temporary 119 rejection response is issued by the server. When the greylisted 120 recorded SMTP client reschedules and retries the same transaction, 121 the GreyListing server will allow the greylisted recorded sender to 122 continue with the transaction. 124 While the idea of using an intentional 4yz rejection to force SMTP 125 clients to retry sending mail would naturally be considered a radical 126 concept for the IETF purist and most likely would not have been 127 endorsed as an IETF standard protocol, the proof of concept has long 128 been established as a very effective means to control certain types 129 of malicious and abusive mail senders and today, Greylisting is a 130 widely recognized mail filtering method and Greylisting SMTP Servers 131 are widely implemented by many in the IETF mail community. 133 _What sort of mail senders does Greylisting address?_ 135 By leveraging the SMTP retry expectation for clients, Greylisting is 136 very effective against mail senders who anonymously and randomly 137 perform a "Single Shot" mail sending attempt and will never repeat 138 the same transaction after the sender has been initially rejected. 139 The high payoff has been the nearly 100% of all mail senders behaving 140 as "single shot" mail senders are abusive and/or malicious in nature. 142 Greylisting can not address abusive mail senders using compliant SMTP 143 mail clients. However, it has been observed that many abusive mail 144 senders will retry again and often immediately within a short time 145 delay. Hence, the Greylisting concept includes the idea of using a 146 "Blocking Time" factor where a greylisted recorded mail sender is 147 blocked for a certain time period. Only when the blocking time has 148 expired, will the GreyListing server finally allow the mail sender to 149 continue with the transaction. 151 _What sort of impact has Greylisting had with Mail Delivery?_ 153 Greylisting has been designed since its conception to satisfy certain 154 criteria: 156 o Enforce SMTP compliance with expected SMTP retry strategies, 158 o Limit abusive mail senders ability to circumvent the blocking, 160 o Have minimal impact on users, and 162 o Require minimal maintenance at both the user and administrator 163 level. 165 The first immediate impact are the increasing delays in mail delivery 166 due to the wide range in Greylisting blocking time values which can 167 be seconds, minutes to hours. Since SMTP has a standard 168 recommendation to implement a Progressive Retry queuing strategy (see 169 section 4.5.4.1 in RFC5321 [RFC5321]) where the first few attempts 170 have short delays (i.e. two attempts within the first hour) with a 171 progressive back off longer delay before the maximum attempts (i.e. 172 over 4-5 days) are exhausted, there are increasing wasted attempts 173 and foremost higher delays in delivering mail. When a SMTP client 174 implements an initial retry lower than the remote GreyListing Server 175 blocking time, the SMTP client will have increasing wasted attempts 176 overhead. When the SMTP client implements an initial retry delay 177 higher than the remote GreyListing Server blocking time, the SMTP 178 client will have unnecessary wasted mail delays in delivering mail. 180 With the increasing deployment of Greylisting mail servers, the 181 second impact is such that even the SMTP server who does not employ 182 Greylisting, will more than likely increasingly connect to a remote 183 mail server that does employ Greylisting and will experience the 184 temporary rejection overhead requiring additional mail sending 185 retries. 187 The third impact is that many GreyListing servers now use the 188 rejection idea at the connection level using a 421 greeting response 189 which may be a different retry condition than a 45z rejection 190 response issued at the MAIL FROM or DATA state. Since many MTA 191 clients see a 421 as a possible loading limit, it may use this to 192 immediately reschedule a retry using a different MX/IP host.. 194 Overall, Greylisting was designed to address the high abuse of 195 "single shot" anonymous mail senders, however it was done at the 196 expense of legitimate mail senders experiencing wasted mail attempts 197 and increasing delivery delays and with improper GreyListing server 198 and client settings, SMTP clients may now have to revisit their 199 queuing strategies to address the Greylisting overhead related 200 issues. 202 This specification provides insights into preparing a low impact 203 Greylisting Server by providing some recommendations for blocking 204 delays and defining a formal structure GreyListing server to 205 optionally include a suggested "retry=time-delay" information in the 206 server's 4yz temporary text responses. 208 This specification does not attempt to alter existing IETF standard 209 SMTP and non-IETF standard Greylisting protocols other than to 210 provide augmented Greylisting techniques to help alleviate the 211 overhead associated with Greylisting in the client/server SMTP 212 transport process. SMTP servers supporting this extension will only 213 be altering 4yz greylisting responses which is out of scope in 214 RFC5321. Greylisting is not part of SMTP and is implemented as an 215 "add-on" component. SMTP clients supporting this extension will only 216 be factoring in a new time factor for their existing retry and 217 queuing method where the exact retry and queuing methods in placed is 218 also out of scope in RFC5321. 220 The Greylisting method specified in this document is a complementary 221 method to any other existing mail filtering control systems, and is 222 not intended as a replacement for those other methods. In fact, it 223 is expected that abusive mail senders will eventually try to minimize 224 the effectiveness of this method of blocking, and Greylisting is 225 designed to limit options available to the mail senders when 226 attempting to do so. The positive outcome of Greylisting is that the 227 only methods of circumventing it will tend to make other mail 228 filtering control techniques just that much more effective (primarily 229 DNS and other methods of blacklisting based on IP address) even after 230 any adaptation by the abusive mail senders has occurred. 232 1.2. Document Conventions 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in RFC 2119 [RFC2119]. 238 1.3. Definitions and Acronyms 240 MTA Mail Transfer Agent. Sender or Receiver of mail. Generally 241 viewed as a router within a MSA intra-network where there is a 242 inherent authentication. 244 MUA Mail User Agent. Online or offline mail reader/writer software. 245 Typically has its own MTA component for sending mail. 247 MSA Mail Submission Agent. Generally associated with a MUA sending 248 message to a ISP or ESP where there is an authorized or 249 authenticated association with the MUA. 251 MDA Mail Destination Agent. Generally associated as the final 252 destination of the message where the message is typically 253 targeted for a local user. If the MDA is going to route the 254 mail, then its behaving more as a MSA or MTA. 256 1.4. Syntactic Notation 258 This specification uses the Augmented Backus-Naur Form (ABNF 259 [RFC5234]) notation for the formal definition of the syntax for the 260 "retry=time-delay" hint. 262 1.5. Out of Scope Considerations 264 The following are out of scope considerations in this specification: 266 o how Greylisting information is recorded in databases, 268 o what additional mail information is recorded in databases beyond 269 the Triplet recording, and 271 o server reasons for an 4yz response outside a Greylisting reason, 272 such as SMTP Traffic Control concepts. 274 2. Greylisting Basic Framework 276 The basic idea of GreyListing is: 278 1. MTA Client initiates a mail delivery attempt to a remote 279 GreyListing compliant mail receiver (MDA), 281 2. The GreyListing Server collects first time session information 282 about the sender such as connection IP, MAIL FROM and RCPT TO 283 called the Triplet. 285 3. If the Triplet was never recorded before, the Triplet is recorded 286 and a 4yz rejection server response with a recommended 287 "retry=time-delay" hint is issued where the time reflects the 288 blocking time the sender can attempt again and proceed with the 289 transaction. 291 4. If the Triplet was recorded, a check is performed to determine if 292 the blocking time has expired. If not, another 4yz rejection 293 response with a new "retry=time-delay" hint reflecting the new 294 blocking time is issued. 296 5. When the sender tries again with the same recorded information 297 after the blocking time has expired, then the sender has passed 298 the server's greylist test and is allowed to proceed to send the 299 mail. 301 One of the essential goals of this specification is to reduce the 302 network and communications overhead in sender attempts and to reduce 303 mail delivery delays by implementing the server "retry=time-delay" 304 hints in the 4yz greylist responses. 306 2.1. Greylist Recording Parameters 308 Greylisting Server implementations vary in ways which may include 309 many factors including how senders are traced, accepted, how record 310 expires, the history of sender transactions and including but not 311 limited to how senders are temporarily or permanently white listed. 312 The original Harris [HARRIS] Greylisting specifications offers a 313 range of ideas that are considered. 315 This specification concentrate on the three principle parameters that 316 make up the fundamental backgound of a Greylist system: 318 Sender Triplet 320 Blocking Time Delay 322 Triplet Expiration Time 324 2.2. Recording Sender Information (Triplet) 326 In the classic Greylisting protocol described in HARRIS [HARRIS], a 327 Triplet is the unique combination of connection IP, the reverse 328 address (MAIL FROM) and the forwarding address (RCPT TO) used to 329 track the sender. When the sender retries with the same triplet, a 330 lookup can be perform to determine its Greylist status. However, 331 depending on the Greylist server implementation, it can reject at 332 different points in the SMTP state machine and may not collect the 333 entire triplet information. 335 While it is out of scope how a SMTP session Triplet is collected and 336 what SMTP session data points it contains, the key point is a 337 specific Triplet used to track the MTA for an initial transaction 338 attempt and subsequent retries in order to control it during the 339 Greylisting Server blocking time. 341 The following is an implementation example for triplet recording: 342 Sender-Triplet = triplet-alg(CIP, RPATH, FPATH) 344 where 346 CIP is the connection IP address of the client, 347 RPATH is the MAIL FROM reverse-address or domain, 348 FPATH is the RCPT TO forwarding address 349 triplet-alg is the algorithm used to generate a database 350 tracking key. 352 One example of a triplet-alg is using a standard hashing algorithm as 353 such SHA1 with BASE64 encoding. 355 BASE64(SHA1(CIP, RPATH, FPATH)) 357 Other tracking methods such as index keys in SQL database tables are 358 often common with Greylisting server implementations. This 359 specification does not define an formal triple-alg method. Any SMTP 360 data can be used as long as it represents Greylisting servers method 361 for consistent tracking transactions , its initial rejection and 362 subsequent acceptance with expected retries. 364 2.3. SMTP Server Rejection Points 366 Greylisting assumes a triplet recording (IP, FROM and TO), however a 367 Greylisting server can reject at any point in the SMTP state machine 368 by recording less information about the sender. This specification 369 hopes to assist the MTA to determine when a temporary rejection is 370 greylist related apart from other reasons which can be a factor in 371 how an MTA client will reschedule new attempts. 373 2.3.1. Connection Greeting 375 Many SMTP servers will use a 421 response during the greeting as a 376 way to limit connections and control load. 378 A GreyListing server deciding to greylist a client at the connection 379 greeting MUST use a 421 reply code and SHOULD include a "retry=time- 380 delay" hint as part of the text response. 382 The "retry=time-delay" hint will help the MTA decide what sort of 383 rejection was imposed by distinguishing between loading limit or 384 greylist rejection. Without the "retry=time-delay" hint, a MTA can 385 try an alternative MX immediately (without delay) and the rejection 386 may still occur. Including the "retry=time-delay" hint will assist 387 the MTA to better reschedule the retry. 389 A GreyListing Server rejecting at the connection level is recording 390 only the connection IP to track the sender. 392 2.3.2. EHLO/HELO 394 A GreyListing server deciding to greylist a client as a response to 395 the EHLO or HELO command SHOULD use a 451 reply code and SHOULD 396 include a "retry=time-delay" hint as part of the text response. The 397 hint will help the MTA decide when a new attempt should be attempted. 399 A GreyListing Server rejecting at the EHLO is recording the 400 connection IP and EHLO/HELO machine host name. 402 Note: The editor has no information on the existence of Greylisting 403 servers that perform a 4yz rejection at the EHLO or HELO command for 404 greylisting reasons. 406 2.3.3. MAIL FROM 408 A GreyListing server deciding to greylist a client as a response to 409 the MAIL FROM command SHOULD use a 451 reply code and SHOULD include 410 a "retry=time-delay" hint as part of the text response. The hint 411 will help the MTA decide when a new attempt should be attempted. 413 A GreyListing Server rejecting at the MAIL FROM is recording the 414 connection IP and MAIL FROM sender address. 416 2.3.4. RCPT TO 418 A GreyListing server deciding to greylist a client as a response to 419 the RCPT TO command SHOULD use a 451 reply code and SHOULD include a 420 "retry=time-delay" hint as part of the text response. The hint will 421 help the MTA decide when a new attempt should be attempted. 423 A GreyListing Server rejecting at the RCPT TO is recording the 424 connection IP, MAIL FROM and RCPT TO addresses. 426 2.3.5. DATA 428 A GreyListing server deciding to greylist a client as a response to 429 the DATA End of Data (EOD) SHOULD use a 451 reply code and SHOULD 430 include a "retry=time-delay" hint as part of the text response. The 431 hint will help the MTA decide when a new attempt should be attempted. 433 Generally, a GreyListing server will allow the DATA command in order 434 to capture the actual RFC5322 [RFC5322] message before a greylist 435 response is issued. The reasons are beyond the scope of this 436 specification. 438 A GreyListing Server rejecting at the DATA may be recording more 439 information besides the triplet information, i.e. Message-Id header. 441 2.4. 4yz Format Structure 443 Many current Greylisting Servers use varying text responses with 444 informal language try again time text information. The following are 445 known forms of existing Greylisting Servers which expose a form of 446 time hints within the text response: 448 421 This server implements greylisting, please try again in # 449 seconds 451 450 4.7.1 : Recipient address rejected: Greylisted for # 452 minutes 454 450 4.7.1 : Recipient address rejected: Greylisted for # 455 seconds 457 451 4.7.1 Greylisting in action, please come back in HH:MM:SS 459 451 Greylisted for # seconds 460 451 Greylisted, please try again in # seconds 462 451 Greylisting enabled, try again in # minutes 464 It is possible for existing MTA clients currently supporting the 465 parsing and extraction of the time factor with the known informal 466 responses from existing Greylisting servers and this specification 467 does not attempt to limit specific MTA client implementations which 468 may already exist. 470 This specification offers a formal structure the Greylisting Server 471 MAY use within their 4yz responses and the MTA client MAY use to 472 detect and extract the retry information consistently without error 473 using a single format within the 4yz response containing the 474 following structured "retry=time-delay" tag: 476 retry=[DD-]HH:MM:SS 478 The [DD-]HH:MM:SS part is the time delay the MTA SHOULD wait before 479 attempting to send the mail again. It is not a specific time of day, 480 but rather the amount of GreyListing Server blocking time expected by 481 the server before the client SHOULD try again. An MTA client 482 ignoring this information, attempting again before the blocking time 483 has expired, is a wasted attempt and can delay the mail delivery well 484 beyond the GreyListing server blocking time. 486 In ABNF [RFC5234], GreyListing server response syntax is: 488 Reply-Line = ( Reply-Code [ SP textstring ] CRLF ) / 489 ( Reply-Code "-" [ SP textstring ] CRLF 490 *( Reply-Code "-" [ textstring ] CRLF ) 491 Reply-Code [ SP textstring ] CRLF ) 493 Reply-Code = "421" / "450" / "451" 495 textstring = 1*(%x09 / %x20-7E) [SP retryhint [ SP expirehint ] ] 497 retryhint = "retry=" time-delay 499 expirehint = "expire=" time-expire 501 time-delay = ( [days "-"] hours ":" minutes ":" seconds) / totalsecs 503 time-expire = ( [days "-"] hours ":" minutes ":" seconds) / totalsecs 505 days = 2DIGIT ; 00-99 507 hours = 2DIGIT ; 00-23 509 minutes = 2DIGIT ; 00-59 511 seconds = 2DIGIT ; 00-59 513 totalsecs = 6*DIGIT ; 0-999999 515 Examples: 517 Single line responses: 519 450 4.7.1. Greylist enabled. retry=00:02:00 520 451 Temporary rejection. retry=00:00:30 521 450 4.7.1. Temporary Greylist rejection. retry=01-00:10:00 522 451 TempFail Retry=00:00:55 523 421 Your connection is greylisted. Please try again later (retry=00:01:00) 525 Multiple lines response: 527 451-Greylisted. See policy http://example.com/GreyList-Policy 528 451 Retry=00:02:00 530 For multiple lines responses, the retryhint MUST be provided in the 531 last line of the response. 533 2.4.1. 421 vs 45z Reply Codes 535 GreyListing Servers may issue 421 or 45z responses at any point in 536 the SMTP session. However, RFC5321 recommends 421 be used at the 537 greeting and for server interruption events. This specification 538 recommends keeping with the SMTP RFC5321 recommendations for 421 and 539 only use 45z for non-Greeting rejections responses. All SMTP 540 compliant MTA will always follow 4yz for scheduling a retry, but the 541 difference is a 421 can trigger an immediate retry attempt without 542 delay at the next MX IP address, if any, where a GreyListing server 543 will most likely reject the new attempt due to the blocking time. 545 IMPLEMENTATION NOTE: RFC5321 recommends a specific 450 reply code 546 for temporary rejections related to local policy reasons. HARRIS 547 used 451 to make it distinctive as a greylist response. This 548 specification recommends using 450, however, it is recognized that 549 many existing Greylisting servers already use 451 as the reply 550 code. MTA MUST NOT depend on 450 or 451 to make retry decisions. 551 All 4yz responses MUST be interpreted as a temporary rejection. 553 When the "retry=time-delay" hint is implemented in the response, 554 compliant MTA will be able to determine the difference between a load 555 restriction and a greylisted rejection to appropriately reschedule a 556 new attempt at the GreyListing server's suggested time hint. 558 2.5. Recommended Blocking Times 560 This specification does not impose any specific blocking delay value 561 when 4yz rejections are issued by servers, other than to suggest that 562 timely delivery of mail to users remains to be an inherent 563 expectation by SMTP clients and SMTP servers. 565 The GreyListing server blocking times vary greatly in practice, but 566 there is empirical evidence a majority of systems use a 1 to 5 minute 567 delay. Many use 10 minutes or 15 minutes. Many use less than 1 568 minute, like 30 to 55 seconds. The latter tend to be systems who 569 wish to lower impact with immediate and timely mail delivery delays. 570 However, this can be wasteful attempts when the MTA is operating 571 blindly with unknown blocking times imposed by Greylisting Servers. 573 When it comes to a recommendation, there is no GreyListing logic to 574 suggest that long delays be use when the goal of Greylisting senders 575 is to address the anonymous random "single shot" senders where their 576 triplet will never be the same. Delaying good SMTP senders for 577 extended unreasonable periods defeats the goal of Greylisting. 579 Since there is no clear recommendation for a blocking time delay 580 (other than to keep it short as possible), this specification offers 581 the "retry=time-delay" hint as a method to alleviate the uncertainty 582 in the wasted attempts and delays in timely mail delivery. 584 3. SMTP Service Keyword 586 GREYLIST is a new ESMTP [RFC1651] service keyword. The GreyListing 587 Server MAY add this optional keyword as a response to EHLO command. 588 EHLO response Format: 590 250-GREYLIST [server-options] 592 If the GREYLIST keyword is presented as part of the EHLO response, it 593 means the server has Greylisting implemented and 4yz responses are 594 possible due to a Greylist decision by the server to impose on the 595 client. The keyword is not necessary and the server can still 596 provide 4yz temporary rejections. 598 The optional server-options provides space separated attributes 599 reflecting the server Greylisting information the server wishes to 600 expose. Currently the following optional attributes are defined: 602 RETRY means that 4yz responses related to GreyListing will have 603 "retry=time-delay" information. The attribute is optional and not 604 required to issue 4yz responses with "retry=time-delay" hints. 606 3.1. SMTP Client/Server Implementation 608 3.1.1. SMTP Server Implementation 610 The SMTP server MAY add support for the GREYLIST service keyword in 611 the EHLO response. If the SMTP server adds the GREYLIST service 612 keyword without the RETRY attribute, it MAY add the "retry=time- 613 delay" hint to 4yz responses. If the SMTP server adds the GREYLIST 614 service keyword with the RETRY attribute, it MUST add the 615 "retry=time-delay" hint to to 4yz responses. 617 3.1.2. SMTP Client Implementation 619 The SMTP client MAY read the GREYLIST service keyword exposed by the 620 EHLO response and it MAY support the usage of the "retry=time-delay" 621 hint in 4yz responses and are not obligated to honor the SMTP servers 622 recommended retry delay. 624 If the SMTP server offers the GREYLIST keyword with the RETRY 625 attribute, the SMTP client SHOULD consider supporting the usage of 626 the server's recommended retry delay in 4yz responses with 627 "retry=time-delay" hints. 629 If a SMTP client is rejected by the Greylisting Server during the 630 session, the client SHOULD NOT attempt to start a new transaction 631 during the same session and SHOULD immediately issue a QUIT command 632 to end the session. Its been observed that some mail senders will 633 hold the connection for 1-5 minutes and retry the same mail 634 transaction or a new transaction. The SMTP server rejecting the 635 initial transaction MAY stop accepting any new transactions attempts 636 during the same session. 638 If a SMTP server offers a "retry=time-delay" hint which results in a 639 wasted 2nd attempt and requires additional attempts, the SMTP client 640 MAY begin to ignore the server's "retry=time-delay" hint after the 641 2nd wasted retry. The SMTP client implementation can decide what 642 limits to place on honoring "retry=time-delay" hints and wasted 643 attempts it provides. 645 4. Examples 647 Example with no extended codes: 649 S: serverdomain.com, welcome ESMTP v2.0 650 C: EHLO mail.clientdomain.com 651 S: 250-GREYLIST 652 S: 250-HELP 653 C: MAIL FROM: 654 S: 250 User OK 655 C: RCPT TO: 656 S: 451 Greylisted. Please Disconnect now. retry=00:01:00 657 C: QUIT 658 S: 221 Goodbye 660 In the above example, the client can extract the "retry=00:01:00" 661 information and rechedule a 2nd mail delivery attempt at the current 662 attempt time plus 1 minute later and not before. It can reschedule 663 at a later time it if chooses to do so. 665 Example with extended codes: 667 S: serverdomain.com, welcome ESMTP v2.0 668 C: EHLO mail.clientdomain.com 669 S: 250-ENHANCEDSTATUSCODES 670 S: 250-GREYLIST 671 S: 250-HELP 672 C: MAIL FROM: 673 S: 250 2.1.0 User OK 674 C: RCPT TO: 675 S: 450 4.7.1 Greylisted. Please Disconnect now. retry=00:10:00 expire=02-00:00:00 676 C: QUIT 677 S: 221 2.3.0 Goodbye 679 In the above example, the client can extract the "retry=00:05:00" 680 information and rechedule a 2nd mail delivery attempt at the current 681 attempt time plus 10 minutes and not before. It can reschedule at a 682 later time, however since a "expire=time-expire" hint was provide, it 683 should complete the new attempts before the indicated 2 days 684 expiration. If the attempt is done after 2 days, the server will 685 greylist reject the MTA again. 687 Example of connection rejection: 689 S: 421 4.7.1 Greylist enabled. Try again later. retry=00:10:00 691 5. IANA Considerations 693 This document makes no request of IANA. 695 Note to RFC Editor: this section may be removed on publication as an 696 RFC. 698 6. Security Considerations 700 One possible security concern envisioned is a DoS attack when 701 "retry=time-delay" information is exposed by the GreyListing server 702 where by a malicious sender may attempt to overwhelm the server 703 during the server's retry time exposing a time window when the server 704 has indicated system availability for mail acceptability. However, 705 since security measures to mitigate DoS is a required operational 706 factor, a GreyListing Server will inherently be prepared for DoS 707 attacks with managed loading limits with or without "retry=time- 708 delay" Greylist responses, thus there is no expected technical 709 concern by exposing Greylist "retry=time-delay" hints. With or 710 without this specification, all SMTP servers SHOULD be prepared for 711 DoS attacks of all kinds. 713 Another arguable security concern is related to the idea a formal 714 SMTP extension can possibly lower the effectiveness of Greylisting 715 when abusive mail senders adapt to the server's suggested retry 716 times. This concern does not seem to have weight since adaptation 717 can occur with or without the extension simply by complying to SMTP 718 retry recommendations. Greylisting remains effective because legacy 719 abusive systems do not adapt. In fact, a "retry=time-delay" hint 720 implementation provides a means to help avoid abusive redundancy and 721 reduced random overloading of connections at unmanaged random times 722 by MTA clients of all flavors. A "retry=time-delay" hint may 723 actually be purposely calculated to provide a time window when there 724 is less loading for legitimate and abusive senders. 726 7. Acknowledgements 728 The following individuals contributed input and guidance in the 729 production of this specification: 731 Claus Assmann, Frank Ellerrman, Tim Kehres, John Klensin, S. 732 Moonesamy, Keith Moore, Ken Raeburn, Paul Smith. 734 Please note acknowledgement does not imply any specific endorsement 735 of this specification other than they have provided important pros 736 and cons input which helped mold the specification. 738 8. References 740 8.1. Normative References 742 [RFC1651] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 743 Crocker, "SMTP Service Extensions", RFC 1651, July 1994. 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 749 RFC 3463, January 2003. 751 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 752 for Authorizing Use of Domains in E-Mail, Version 1", 753 RFC 4408, April 2006. 755 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 756 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 757 Signatures", RFC 4871, May 2007. 759 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 760 Specifications: ABNF", STD 68, RFC 5234, January 2008. 762 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 763 October 2008. 765 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 766 October 2008. 768 [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 769 Signatures -- Update", RFC 5672, August 2009. 771 8.2. Informative References 773 [HARRIS] Harris, E., "The Next Step in the Spam Control War: 774 Greylisting", 2003, . 777 Appendix A. Additional Greylist Parameters 779 Greylisting Server implementations vary in ways which may include 780 many factors including how senders are traced, accepted, how record 781 expires, the history of sender transactions and including but not 782 limited to how senders are temporarily or permanently white listed. 783 The original Harris [HARRIS] Greylisting specifications offers a 784 range of ideas that are considered. The following are just of a few 785 of additional parameters that are considered by servers: 787 o Whitelist Record Expiration: 789 Whitelist Record Expiration is used to allow a previous greylisted 790 sender a time window where it can be temporarily or permanently 791 whitelisted depending on the implementation. This is a local 792 policy consideration, however, it should be noted that redundant 793 greylisting of a common MTA is not considered reasonable. At some 794 point, the MTA is a trusted source of mail and the MTA SHOULD be 795 permanently whitelisted. The main idea with a temporary 796 whitelisting is that its possible a future transaction can be a 797 compromised user transaction. 799 o Class C IP Address Tracking: 801 Class C IP Address Tracking allows a Greylisting server to control 802 a greylisted MTA who retries using a different class C address. 803 This is typical in larger outbound farms where many machines are 804 used to send mail. If Class C is not considered, MTAs using a 805 different IP will be unnecessarily rejected after delaying within 806 a blocked time. 808 Appendix B. Augmenting Other Standard Email Filters Methods 810 It is possible for a GreyListing server to combine other mail 811 filtering techniques, methods and session information to determine if 812 a sender should be greylisted. While the augmentation of these 813 additional methods is out of the scope, the following are some 814 suggestions that may help minimize a GreyListing Server impact. on 815 MTAs. 817 SPF SPF (Sender Policy Framework) [RFC4408] can be used to help 818 validate a sender's IP association with the return path domain. 819 A SPF SOFTFAIL or FAIL (if not used for rejection) result could 820 be used to help decide when Greylisting should be employed on 821 the sender. While a PASS result is not a trusted condition, a 822 local policy may use a PASS to skip Greylisting mail checks. 824 DKIM DKIM (Domain Key Identified Mail) [RFC5672] can be used to help 825 authenticate the transactions from trusted DKIM mail signers. 826 If the signer is considered is trusted source, this can help 827 eliminate the need to greylist the sender. 829 Appendix C. TO DO LIST 831 1. Possible section showing real proof of concept examples. 833 2. Review the SMTP Service Keyword and determine how SHOULD|MAY|MUST 834 is applied. 836 Authors' Addresses 838 Hector Santos (editor) 839 Santronics Software, Inc. 840 15600 SW 158 ST Suite #306 841 Homestead, Florida, FL 33033 842 United States of America 844 Email: hsantos@santronics.com 845 URI: http://www.santronics.com 846 Evan Harris 847 puremagic.com 849 Email: eharris@puremagic.com