7Internet Engineering Task Force (IETF) M. Kucherawy
8Request for Comments: 6647 Cloudmark
9Category: Standards Track D. Crocker
10ISSN: 2070-1721 Brandenburg InternetWorking
14 Email Greylisting: An Applicability Statement for SMTP
18 This document describes the art of email greylisting, the practice of
19 providing temporarily degraded service to unknown email clients as an
22 Greylisting is an established mechanism deemed essential to the
23 repertoire of current anti-abuse email filtering systems.
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc6647.
41 Copyright (c) 2012 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58Kucherawy & Crocker Standards Track [Page 1]
60RFC 6647 Greylisting June 2012
65 1. Introduction ....................................................3
66 1.1. Background .................................................3
67 1.2. Definitions ................................................4
68 2. Types of Greylisting ............................................4
69 2.1. Connection-Level Greylisting ...............................4
70 2.2. SMTP HELO/EHLO Greylisting .................................5
71 2.3. SMTP MAIL Greylisting ......................................5
72 2.4. SMTP RCPT Greylisting ......................................5
73 2.5. SMTP DATA Greylisting ......................................6
74 2.6. Additional Heuristics ......................................7
75 2.7. Exceptions .................................................7
76 3. Benefits and Costs ..............................................8
77 4. Unintended Consequences .........................................9
78 4.1. Unintended Mail Delivery Failures ..........................9
79 4.2. Unintended SMTP Client Failures ...........................10
80 4.3. Address Space Saturation ..................................11
81 5. Recommendations ................................................12
82 6. Measuring Effectiveness ........................................13
83 7. IPv6 Applicability .............................................14
84 8. Security Considerations ........................................14
85 8.1. Trade-Offs ................................................14
86 8.2. Database ..................................................14
87 9. References .....................................................15
88 9.1. Normative References ......................................15
89 9.2. Informative References ....................................15
90 Appendix A. Acknowledgments ......................................17
114Kucherawy & Crocker Standards Track [Page 2]
116RFC 6647 Greylisting June 2012
121 Preferred techniques for handling email abuse explicitly identify
122 good actors and bad actors, giving each significantly different
123 service quality. In some cases, an actor does not have a known
124 reputation; this can justify providing degraded service, until there
125 is a basis for providing better service. This latter approach is
126 known as "greylisting". Broadly, the term refers to any degradation
127 of service for an unknown or suspect source, over a period of time
128 (typically measured in minutes or a small number of hours). The
129 narrow use of the term refers to generation of an SMTP temporary
130 failure reply code for traffic from such sources. There are diverse
131 implementations of this basic concept and predictably, therefore,
132 some blurred terminology.
134 Absent a perfect abuse-detection mechanism that incurs no cost, the
135 current requirement is for an array of techniques to be used by each
136 filtering system. They range in cost, effectiveness, and types of
137 abuse techniques they target.
139 Greylisting happens to be a technique that is cheap and early (in
140 terms of its application in the SMTP sequence) and surprisingly
141 remains useful. Some spamware does indeed route around this
142 technique, but much does not.
144 The firehose of spam over the Internet represents a wide range of
145 sophistication. Greylisting is useful for removing a large amount of
146 simplistic-but-significant traffic.
148 This memo documents common greylisting techniques and discusses their
149 benefits and costs. It also defines terminology to enable clear
150 distinction and discussion of these techniques.
152 There is some confusion in the industry that conflates greylisting
153 with an SMTP temporary failure for any reason. The purpose of this
154 memo is also to dispel such confusion.
158 For many years, large amounts of spam have been sent through purpose-
159 built software, or "spamware", that supports only a constrained
160 version of SMTP. In particular, such software does not perform
161 retransmission attempts after receiving an SMTP temporary failure.
162 That is, if the spamware cannot deliver a message, it just goes on to
163 the next address in its list since, in spamming, volume counts for
164 far more than reliability. Greylisting exploits this by rejecting
165 mail from unfamiliar sources with a "transient (soft) fail" (4xx)
166 [SMTP] error code. Another application of greylisting is to delay
170Kucherawy & Crocker Standards Track [Page 3]
172RFC 6647 Greylisting June 2012
175 mail from newly seen IP addresses on the theory that, if it's a spam
176 source, then by the time it retries, it will appear in a list of
177 sources to be filtered, and the mail will not be accepted.
179 Early references for greylisting descriptions and implementations can
180 be found at [SAUCE] and [PUREMAGIC].
186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
188 document are to be interpreted as described in [KEYWORDS].
1901.2.2. Email Architecture Terminology
192 Readers need to be familiar with the material and terminology
193 discussed in [MAIL], [EMAIL-ARCH], and [SMTP].
1952. Types of Greylisting
197 Greylisting is primarily performed at some phase during an SMTP
198 session. A set of attributes about the client-side SMTP server are
199 used for assessing whether to perform greylisting. At its simplest,
200 the attribute is the IP address of the client, and the assessment is
201 whether it has previously connected recently. More elaborate
202 attribute combinations and more sophisticated assessments can be
203 performed. The following discussion covers the most common
204 combinations and relies on knowledge of [SMTP], its commands, and the
205 distinction between envelope and content.
2072.1. Connection-Level Greylisting
209 Connection-level greylisting decides whether to accept the TCP
210 connection from a "new" [SMTP] client. At this point in the
211 communication between the client and the server, the only information
212 known to the receiving server is the incoming IP address. This, of
213 course, is often (but not always) translatable into a host name.
215 The typical application of greylisting here is to keep a record of
216 SMTP client IP addresses and/or host names (collectively, "sources")
217 that have been seen. Such a database acts as a cache of known
218 senders and might or might not expire records after some period. If
219 the source is not in the database, or the record of the source has
220 not reached some required minimum age (such as 30 minutes since the
221 initial connection attempt), the server does one of the following,
222 inviting a later retry:
226Kucherawy & Crocker Standards Track [Page 4]
228RFC 6647 Greylisting June 2012
231 o returns a 421 SMTP reply and closes the connection, or
233 o returns a different 4yz SMTP reply to all further commands in this
236 A useful variant of the basic known/unknown policy is to limit
237 greylisting to those addresses that are on some list of IP addresses
238 known to be affiliated with bad actors. Whereas the simpler policy
239 affects all new connections, including those from good actors, the
240 constrained policy applies greylisting actions only to sites that
241 already have a negative reputation.
2432.2. SMTP HELO/EHLO Greylisting
245 HELO/EHLO greylisting refers to the first command verb in an SMTP
246 session. It includes a single, required parameter that is supposed
247 to contain the client's fully qualified host name or its literal IP
250 Greylisting implemented at this phase retains a record of sources
251 coupled with HELO/EHLO parameters. It returns 4yz SMTP replies to
252 all commands until the end of the SMTP session if that tuple has not
253 previously been recorded or if the record exists but has not reached
254 some configured minimum age.
2562.3. SMTP MAIL Greylisting
258 MAIL command greylisting refers to the command verb in an SMTP
259 session that initiates a new transaction. It includes at least one
260 required parameter that indicates the return email address
261 (RFC5321.MailFrom) of the message being relayed from the client to
264 Greylisting implemented at this phase retains a record of sources
265 coupled with return email addresses. It returns 4yz SMTP replies to
266 all commands for the remainder of the SMTP session if that tuple has
267 not previously been recorded or if the record exists but has not met
268 some configured minimum age.
2702.4. SMTP RCPT Greylisting
272 RCPT greylisting refers to the command verb in an SMTP session that
273 specifies intended recipients of an email transaction. It includes
274 at least one required parameter that indicates the email address of
275 an intended recipient of the message being relayed from the client to
282Kucherawy & Crocker Standards Track [Page 5]
284RFC 6647 Greylisting June 2012
287 Greylisting implemented at this phase retains a record of tuples that
288 combines the provided recipient address with any combination of the
291 o the source, as described above;
293 o the return email address; and
295 o the other recipient addresses of the message (if any).
297 If the selected tuple is not found in the database, or if the record
298 is present but has not reached some configured minimum age, the
299 greylisting Mail Transfer Agent (MTA) [EMAIL-ARCH] returns 4yz SMTP
300 replies to all commands for the remainder of the SMTP session.
302 Note that often a match on a tuple involving the first valid RCPT is
303 sufficient to identify a retry correctly, and further checks can be
3062.5. SMTP DATA Greylisting
308 DATA greylisting refers to the command verb in an SMTP session that
309 transmits the actual message content, as opposed to its envelope
312 This type of greylisting can be performed at two places in the SMTP
315 1. on receipt of the DATA command, because at that point the entire
316 envelope has been received (i.e., all MAIL and RCPT commands have
319 2. on completion of the DATA command, i.e., after the "." that
320 terminates transmission of the message body, since at that point
321 a digest or other analysis of the message could be performed.
323 Some implementations do filtering here because there are clients that
324 don't bother checking SMTP reply codes to commands other than DATA.
325 Hence, it can be useful to add greylisting capability at that point
328 Numerous greylisting policies are possible at this point. All of
329 them retain a record of tuples that combine the various parts of the
330 SMTP transaction in some combination, including:
332 o the source, as described above;
334 o the return email address;
338Kucherawy & Crocker Standards Track [Page 6]
340RFC 6647 Greylisting June 2012
343 o the recipients of the message, as a set or individually;
345 o identifiers in the message header, such as the contents of the
346 RFC5322.From or RFC5322.To fields;
348 o other prominent parts of the content, such as the RFC5322.Subject
351 o a digest of some or all of the message content, as a test for
354 o analysis of arbitrary portions of the message body.
356 (The last four items in the list above are only possible at the end
357 of DATA, not on receipt of the DATA command.)
359 If the selected tuple is not found in the database, or if the record
360 exists but has not reached some configured minimum age, the
361 greylisting MTA returns 4yz SMTP replies to all commands for the
362 remainder of the SMTP session.
3642.6. Additional Heuristics
366 Since greylisting seeks to target spam senders, it follows that being
367 able to identify spamware within the SMTP context beyond the simple
368 notion of "not seen before" would be desirable. A more targeted
369 approach might also include in its selection heuristics such as the
372 o If a DNS blacklist [DNSBL] lists an IP address but the implementer
373 wishes to be cautious with mitigation actions rather than blocking
374 traffic from the IP address outright, then subject it to
377 o If the value found in a PTR record follows common naming patterns
378 for dynamic IP addresses, then subject it to greylisting.
382 Most greylisting systems provide for an exception mechanism, allowing
383 one to specify IP addresses, IP address Classless Inter-Domain
384 Routing (CIDR) [CIDR] blocks, host names, or domain names that are
385 exempt from greylisting checks and thus whose SMTP client sessions
386 are not subject to such interference.
388 Likely candidates to be excepted from greylisting include those known
389 not to retry according to a pattern that will be observed as
390 legitimate and those that send so rarely that they will age out of
394Kucherawy & Crocker Standards Track [Page 7]
396RFC 6647 Greylisting June 2012
399 the database. In both cases, the excepted source is known not to be
400 an abusive one by the site implementing greylisting. Otherwise,
401 typical non-abusive senders will enter the exception list on the
402 first proper retry and remain there permanently.
404 One could also use a [DNSBL] that lists known good hosts as a
405 greylisting exception set.
409 The most obvious benefit with any of the above techniques is that
410 spamware generally does not retry and is therefore less likely to
411 succeed, absent a record of a previous delivery attempts.
413 The most obvious detriment to implementing greylisting is the
414 imposition of delay on legitimate mail. Some popular MTAs do not
415 retry failed delivery attempts for an hour or more, which can cause
416 expensive delays when delivery of mail is time critical. Worse, some
417 legitimate MTAs do not retry at all. (Note, however, that non-
418 retrying clients are not fully SMTP-capable, per Section 2.1 of
419 [SMTP]. A client does not know, nor is it entitled to know, the
420 reason for the temporary failure status code being returned;
421 greylisting could be in effect, or it could be caused by a local
422 resource issue at the server. A client therefore needs to be
423 equipped to retry in order to be considered fully capable.)
425 The counterargument to this "false positive" problem is that email
426 has always been a "best-effort" mechanism; thus, this cost is
427 ultimately low in comparison to the cost of dealing with high volumes
428 of unwanted mail. Still, the actual effect of such delays can be
429 significant, such as altering the tone or flow of a multi-participant
430 discussion to a mailing list.
432 When the clients are subjected to any kind of reconfiguration,
433 especially network renumbering, the cache of information stored about
434 SMTP client history does not benefit legitimate clients that are
435 already listed for acceptance. To the greylisting implementation,
436 such clients are once again unknown, and they will once again be
437 subjected to the delay.
439 Another obvious cost is for the required database. It has to be
440 large enough to keep the necessary history and fast enough to avoid
441 excessive inefficiencies in the server's operations. The primary
442 consideration is the maximum age of records in the database. If
443 records age out too soon, then hosts that do retry per [SMTP] will be
444 periodically subjected to greylisting even though they are well-
450Kucherawy & Crocker Standards Track [Page 8]
452RFC 6647 Greylisting June 2012
455 behaved; if records age out after too long a period, then eventually
456 spamware that launches a new campaign will not be identified as
457 "unknown" in this manner and will not be required to retry.
459 Presuming that known friendly senders will be manually configured as
460 exceptions to the greylisting check, a steady state will eventually
461 be reached wherein the only mail that is delayed is mail from an IP
462 address that has never sent mail before. Experience suggests that
463 the vast majority of mail comes from places on a developed exception
464 list, so after a training period, only a small proportion of mail is
465 actually affected. The training period could be replaced by
466 processing a history of email traffic and adding the IP addresses
467 from which most traffic arrives to the exception list.
469 Applying greylisting based on actual message content (i.e., post-
470 DATA) is substantially more expensive than any of the other
471 alternatives both in terms of the resources required to accept and
472 temporarily store a complete message body (which can be quite
473 substantial) and any processing that is done on that content. As a
474 consequence, such methods incur more cost during the session and thus
475 are not typical practice.
4774. Unintended Consequences
4794.1. Unintended Mail Delivery Failures
481 There are a few failure modes of greylisting that are worth
482 considering. For example, consider an email message intended for
483 user@example.com. The example.com domain is served by two receiving
484 mail servers, one called mail1.example.com and one called
485 mail2.example.com. On the first delivery attempt, mail1.example.com
486 greylists the client, and thus the client places the message in its
487 outgoing queue for later retry. Later, when a retry is attempted,
488 mail2.example.com is selected for the delivery, either because
489 mail1.example.com is unavailable or because a round-robin [DNS]
490 evaluation produces that result. However, the two example.com hosts
491 do not share greylisting databases, so the second host again denies
492 the attempt. Thus, although example.com has sought to improve its
493 email throughput by having two servers, it has, in fact, amplified
494 the problem of legitimate mail delay introduced by greylisting.
496 Similarly, consider a site with multiple outbound MTAs that share a
497 common queue. On a first outbound delivery attempt to example.com,
498 the attempt is greylisted. On a later retry, a different outbound
499 MTA is selected, which means example.com sees a different source, and
500 once again greylisting occurs on the same message. The same effect
501 can result from the use of [DHCP], where the IP address of an
502 outbound MTA changes between attempts.
506Kucherawy & Crocker Standards Track [Page 9]
508RFC 6647 Greylisting June 2012
511 For systems that do DATA-level greylisting, if any part of the
512 message has changed since the first attempt, the tuple constructed
513 might be different than the one for the first attempt, and the
514 delivery is again greylisted. Some MTAs do reformulate portions of
515 the message at submission time, and this can produce visible
516 differences for each attempt.
518 A host that sends mail to a particular destination infrequently might
519 not remain "known" in the receiving server's database and will
520 therefore be greylisted for a high percentage of mail despite
521 possibly being a legitimate sender.
523 All of these and other similar cases can cause greylisting to be
524 applied improperly to legitimate MTAs multiple times, leading to long
525 delays in delivery or ultimately the return of the message to its
526 sender. Other side effects include out-of-order delivery of related
529 Address translation technologies such as [NAT] cause distinct MTAs to
530 appear to come from a common IP address. This can cause greylisting
531 to be applied only to the first connection attempt from the shared IP
532 address, meaning future MTAs connecting for the first time will be
533 exempted from the protection greylisting provides.
5354.2. Unintended SMTP Client Failures
537 Atypical SMTP client behaviors also need to be considered when
538 deploying greylisting.
540 Some clients do not retry messages for very long periods. Popular
541 open source MTAs implement increasing backoff times when messages
542 receive temporary failure messages and/or degrade queue priority for
543 very large messages. This means greylisting introduces even more
544 delay for MTAs implementing such schemes, and the delay can become
545 large enough to become a nuisance to users.
547 Some clients do not retry messages at all, in violation of [SMTP].
548 This means greylisting will cause outright delivery failure right
549 away for sources, envelopes, or messages that it has not seen before,
550 regardless of the client attempting the delivery, essentially
551 treating legitimate mail and spam the same.
553 If a greylisting scheme requires a database record to have reached a
554 certain age rather than merely testing for the presence of the record
555 in the database, and the client has a retry schedule that is too
556 aggressive, the client could be subjected to rate limiting by the MTA
557 independent of the restrictions imposed by greylisting.
562Kucherawy & Crocker Standards Track [Page 10]
564RFC 6647 Greylisting June 2012
567 Some SMTP implementations make the error of treating all error codes
568 as fatal, contrary to [SMTP]; that is, a 4yz response is treated as
569 if it were a 5yz response, and the message is returned to the sender
570 as undeliverable. This can result in such things as inadvertent
571 removal from mailing lists in response to the perceived rejections.
573 Some clients encode message-specific details in the address parameter
574 to the [SMTP] MAIL command. If doing so causes the parameter to
575 change between retry attempts, a greylisting implementation could see
576 it as a new delivery rather than a retry and disallow the delivery.
577 In such cases, the mail will never be delivered and will be returned
578 to the sender after the retry timeout expires.
580 A client subjected to greylisting might move to the next host found
581 in the ordered [DNS] MX record set for the destination domain and re-
582 attempt delivery. This has several considerations of its own:
584 o Traffic to those alternate servers increases merely as a result of
587 o Alternate (MX) servers SHOULD share the same greylisting database.
588 When they do not -- as is often true when the servers occupy
589 different Administrative Management Domains (ADMDs) -- SMTP
590 clients can see variable treatment if they try to send to
593 o When alternate MX servers relay mail back to the "primary" MX
594 server, the latter SHOULD be configured to permit the other
595 servers to relay mail without being subjected to greylisting.
597 There are some applications that connect to an SMTP server and
598 simulate a transaction up to the point of sending the RCPT command in
599 an attempt to confirm that an address is valid. Some of these are
600 legitimate applications (e.g., mailing list servers), and others are
601 automated programs that attempt to ascertain valid addresses to which
602 to send spam (a "directory harvesting" attack). Greylisting can
603 interfere with both instances, with harmful effects on the former.
6054.3. Address Space Saturation
607 Greylisting is obviously not a foolproof solution to avoiding abusive
608 traffic. Bad actors that send mail with just enough frequency to
609 avoid having their records expire will never be caught by this
610 mechanism after the first instance.
618Kucherawy & Crocker Standards Track [Page 11]
620RFC 6647 Greylisting June 2012
623 Where this is a concern, combining greylisting with some form of
624 reputation service that estimates the likely behavior for IP
625 addresses that are not intercepted by the greylisting function would
630 The following practices are RECOMMENDED based on collected
633 1. Implement greylisting based on a tuple consisting of (IP address,
634 RFC5321.MailFrom, and the first RFC5321.RcptTo). It is
635 sufficient to use only the first RFC5321.RcptTo as legitimate
636 MTAs appear not to reorder recipients between retries. Including
637 RFC5321.MailFrom improves accuracy where the IP address is being
638 matched in clusters (e.g., CIDR blocks) rather than precisely
639 (see below). After a successful retry, allow all further [SMTP]
640 traffic from the IP address in that tuple regardless of envelope
643 2. Include a configurable range of time within which a retry from a
644 greylisted host is considered and outside of which it is
645 otherwise ignored. The range needs to cover typical retry times
646 of common MTA configurations, thus anticipating that a fully
647 capable MTA will retry sometime after the beginning of the range
648 and before the end of it. The default range SHOULD be from one
649 minute to 24 hours. Retries within the range are permitted and
650 satisfy the greylisting test, and the client is thus no longer
651 likely to be a sender of spam. Retries after the end of the
652 range SHOULD be considered to be a new message for the purposes
653 of greylisting evaluation (i.e., reset the "first seen" timestamp
654 for that IP address). Some sites use a higher time value for the
655 low end of the time range to match common legitimate MTA retry
656 timeouts, but additional benefit from doing so appears unlikely.
658 3. Include a timeout for database entries, after which records for
659 IP addresses that have generated no recent traffic are deleted.
660 This step is intended to re-enable greylisting for an IP address
661 in the event that it has changed "owners" and will subject the
662 client to another round of greylisting. The default SHOULD be at
665 4. For an Administrative Management Domain (ADMD), all inbound
666 border MTAs listed in the [DNS] SHOULD share a common greylisting
667 database and common greylisting policies. This handles sequences
668 in which a client's retry goes to a different server after the
669 first 4yz reply, and it lets all servers share the list of hosts
670 that did retry successfully.
674Kucherawy & Crocker Standards Track [Page 12]
676RFC 6647 Greylisting June 2012
679 5. To accommodate those senders that have clusters of outgoing mail
680 servers, greylisting servers MAY track CIDR blocks of a size of
681 its own choosing, such as /24, rather than the full IPv4 address.
682 (Note, however, that this heuristic will not work for clusters
683 having machines on different networks.) A similar grouping
684 capability MAY be established based on the domain name of the
685 mail server if one can be determined.
687 6. Include a manual override capability for adding specific IP
688 addresses or network blocks that always bypass checks. There are
689 legitimate senders that simply don't respond well to greylisting
690 for a variety of reasons, most of which do not conflict with
691 [SMTP]. There are also some highly visible online entities such
692 as email service providers that will be certain to retry; thus,
693 those that are known SHOULD be allowed to bypass the filter.
695 7. Greylisting SHOULD NOT be applied by an ADMD's submission service
696 (see [SUBMISSION]) for authenticated client hosts. It also
697 SHOULD not be applied against any authenticated ADMD session.
698 Authentication can include whatever mechanisms are deemed
699 appropriate for the ADMD, such as known internal IP addresses,
700 protocol-level client authentication, or the like.
702 There is no specific recommendation as to the specific choice of 4yz
703 code to be returned as a result of a greylisting delay. Per [SMTP],
704 however, the only two reasonable choices are 421 if the
705 implementation wishes to terminate the connection immediately and 450
706 otherwise. It is possible that some clients treat different 4yz
707 codes differently, but no data is available on whether using 421
708 versus some other 4yz code is particularly advantageous.
710 There is also no specific recommendation as to the choice of text to
711 include in the SMTP reply, if any. Some implementers argue that
712 indicating that greylisting is in effect can give spamware a hint as
713 to when to try again for successful delivery, while others suspect
714 that it won't matter to spamware and thus the more likely audience is
715 legitimate senders seeking to understand why their mail is being
7186. Measuring Effectiveness
720 A few techniques are common when measuring the effectiveness of
721 greylisting in a particular installation:
723 o Arrange to log the spam versus legitimate determinations of
724 messages and what the greylisting decision would have been if
725 enabled; then determine whether there is a correlation (and, of
726 course, whether too much legitimate email would also be affected).
730Kucherawy & Crocker Standards Track [Page 13]
732RFC 6647 Greylisting June 2012
735 o Continuing from the previous point, query the set of IP addresses
736 subjected to greylisting in any popular [DNSBL] to see if there is
737 a strong correlation.
741 The descriptions and recommendations presented in this memo are based
742 on many years of experience with greylisting in the IPv4 Internet
743 environment, so they clearly pertain to IPv4 deployments only.
745 The greater size of an IPv6 address seems likely to permit
746 differences in behaviors by bad actors, and this could well mean
747 needing to alter the details for applying greylisting; it might even
748 negate any benefits in using greylisting at all. At a minimum, it is
749 likely to call for different specific choices for any greylisting
752 In addition, an obvious consideration is that the size of the
753 database required to store records of all of the IP addresses seen
754 will likely be substantially larger in the IPv6 environment.
7568. Security Considerations
758 This section discusses potential security issues related to
763 The discussion above highlights the fact that, although greylisting
764 provides some obvious and valuable defenses, it can introduce
765 unintentional and detrimental consequences for delivery of legitimate
766 mail. Where timely delivery of email is essential, especially for
767 financial, transactional, or security-related applications, the
768 possible consequences of such systems need to be carefully
771 Specific sources can be exempted from greylisting, but, of course,
772 that means they have elevated privilege in terms of access to the
773 mailboxes on the greylisting system, and malefactors can seek to
778 The database that has to be maintained as part of any greylisting
779 system will grow as the diversity of its SMTP clients' hosts grows
780 and, of course, is larger in general depending on the nature of the
781 tuple stored about each delivery attempt. Even with a record aging
782 policy in place, such a database could grow large enough to interfere
786Kucherawy & Crocker Standards Track [Page 14]
788RFC 6647 Greylisting June 2012
791 with the system hosting it, or at least to a point at which
792 greylisting service is degraded. Moreover, an attacker knowing which
793 greylisting scheme is in use could rotate parameters of SMTP clients
794 under its control, in an attempt to inflate the database to the point
795 of denial-of-service.
797 Implementers could consider configuring an appropriate failure policy
798 so that something locally acceptable happens when the database is
799 attacked or otherwise unavailable.
801 In practice, this has not appeared as a serious concern, because any
802 reasonable aging policy successfully moderates database growth. It
803 is nevertheless identified here as a consideration as there may be
804 implementations in some environments where this is indeed an issue.
8089.1. Normative References
810 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598,
813 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
814 Requirement Levels", BCP 14, RFC 2119, March 1997.
816 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
819 [SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for
820 Mail", STD 72, RFC 6409, November 2011.
8229.2. Informative References
824 [CIDR] Fuller, V. and T. Li, "Classless Inter-domain Routing
825 (CIDR): The Internet Address Assignment and Aggregation
826 Plan", BCP 122, RFC 4632, August 2006.
828 [DHCP] Droms, R., "Dynamic Host Configuration Protocol",
829 RFC 2131, March 1997.
831 [DNS] Mockapetris, P., "Domain names - implementation and
832 specification", STD 13, RFC 1035, November 1987.
834 [DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
837 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
842Kucherawy & Crocker Standards Track [Page 15]
844RFC 6647 Greylisting June 2012
847 [NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network
848 Address Translator (Traditional NAT)", RFC 3022,
851 [PUREMAGIC] Harris, E., "The Next Step in the Spam Control War:
852 Greylisting", August 2003,
853 <http://projects.puremagic.com/greylisting/
856 [SAUCE] Jackson, I., "GNU SAUCE", 2001,
857 <http://www.gnu.org/software/sauce>.
898Kucherawy & Crocker Standards Track [Page 16]
900RFC 6647 Greylisting June 2012
903Appendix A. Acknowledgments
905 The authors wish to acknowledge Mike Adkins, Steve Atkins, Mihai
906 Costea, Derek Diget, Peter J. Holzer, John Levine, Chris Lewis, Jose-
907 Marcio Martins da Cruz, John Klensin, S. Moonesamy, Suresh
908 Ramasubramanian, Mark Risher, Jordan Rosenwald, Gregory Shapiro, Joe
909 Sniderman, Roland Turner, and Michael Wise for their contributions to
910 this memo. The various participants of the MAAWG Open Sessions about
911 greylisting were also valued contributors.
917 128 King St., 2nd Floor
918 San Francisco, CA 94107
921 Phone: +1 415 946 3800
922 EMail: superuser@gmail.com
926 Brandenburg InternetWorking
931 Phone: +1.408.246.8253
932 EMail: dcrocker@bbiw.net
954Kucherawy & Crocker Standards Track [Page 17]