doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6647.txt b/doc/rfc/rfc6647.txt
new file mode 100644
index 0000000..3bd0d11
--- /dev/null
+++ b/doc/rfc/rfc6647.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Kucherawy
+Request for Comments: 6647                                     Cloudmark
+Category: Standards Track                                     D. Crocker
+ISSN: 2070-1721                              Brandenburg InternetWorking
+                                                               June 2012
+
+
+         Email Greylisting: An Applicability Statement for SMTP
+
+Abstract
+
+   This document describes the art of email greylisting, the practice of
+   providing temporarily degraded service to unknown email clients as an
+   anti-abuse mechanism.
+
+   Greylisting is an established mechanism deemed essential to the
+   repertoire of current anti-abuse email filtering systems.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6647.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 1]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Background .................................................3
+      1.2. Definitions ................................................4
+   2. Types of Greylisting ............................................4
+      2.1. Connection-Level Greylisting ...............................4
+      2.2. SMTP HELO/EHLO Greylisting .................................5
+      2.3. SMTP MAIL Greylisting ......................................5
+      2.4. SMTP RCPT Greylisting ......................................5
+      2.5. SMTP DATA Greylisting ......................................6
+      2.6. Additional Heuristics ......................................7
+      2.7. Exceptions .................................................7
+   3. Benefits and Costs ..............................................8
+   4. Unintended Consequences .........................................9
+      4.1. Unintended Mail Delivery Failures ..........................9
+      4.2. Unintended SMTP Client Failures ...........................10
+      4.3. Address Space Saturation ..................................11
+   5. Recommendations ................................................12
+   6. Measuring Effectiveness ........................................13
+   7. IPv6 Applicability .............................................14
+   8. Security Considerations ........................................14
+      8.1. Trade-Offs ................................................14
+      8.2. Database ..................................................14
+   9. References .....................................................15
+      9.1. Normative References ......................................15
+      9.2. Informative References ....................................15
+   Appendix A.  Acknowledgments ......................................17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 2]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+1.  Introduction
+
+   Preferred techniques for handling email abuse explicitly identify
+   good actors and bad actors, giving each significantly different
+   service quality.  In some cases, an actor does not have a known
+   reputation; this can justify providing degraded service, until there
+   is a basis for providing better service.  This latter approach is
+   known as "greylisting".  Broadly, the term refers to any degradation
+   of service for an unknown or suspect source, over a period of time
+   (typically measured in minutes or a small number of hours).  The
+   narrow use of the term refers to generation of an SMTP temporary
+   failure reply code for traffic from such sources.  There are diverse
+   implementations of this basic concept and predictably, therefore,
+   some blurred terminology.
+
+   Absent a perfect abuse-detection mechanism that incurs no cost, the
+   current requirement is for an array of techniques to be used by each
+   filtering system.  They range in cost, effectiveness, and types of
+   abuse techniques they target.
+
+   Greylisting happens to be a technique that is cheap and early (in
+   terms of its application in the SMTP sequence) and surprisingly
+   remains useful.  Some spamware does indeed route around this
+   technique, but much does not.
+
+   The firehose of spam over the Internet represents a wide range of
+   sophistication.  Greylisting is useful for removing a large amount of
+   simplistic-but-significant traffic.
+
+   This memo documents common greylisting techniques and discusses their
+   benefits and costs.  It also defines terminology to enable clear
+   distinction and discussion of these techniques.
+
+   There is some confusion in the industry that conflates greylisting
+   with an SMTP temporary failure for any reason.  The purpose of this
+   memo is also to dispel such confusion.
+
+1.1.  Background
+
+   For many years, large amounts of spam have been sent through purpose-
+   built software, or "spamware", that supports only a constrained
+   version of SMTP.  In particular, such software does not perform
+   retransmission attempts after receiving an SMTP temporary failure.
+   That is, if the spamware cannot deliver a message, it just goes on to
+   the next address in its list since, in spamming, volume counts for
+   far more than reliability.  Greylisting exploits this by rejecting
+   mail from unfamiliar sources with a "transient (soft) fail" (4xx)
+   [SMTP] error code.  Another application of greylisting is to delay
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 3]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   mail from newly seen IP addresses on the theory that, if it's a spam
+   source, then by the time it retries, it will appear in a list of
+   sources to be filtered, and the mail will not be accepted.
+
+   Early references for greylisting descriptions and implementations can
+   be found at [SAUCE] and [PUREMAGIC].
+
+1.2.  Definitions
+
+1.2.1.  Keywords
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KEYWORDS].
+
+1.2.2.  Email Architecture Terminology
+
+   Readers need to be familiar with the material and terminology
+   discussed in [MAIL], [EMAIL-ARCH], and [SMTP].
+
+2.  Types of Greylisting
+
+   Greylisting is primarily performed at some phase during an SMTP
+   session.  A set of attributes about the client-side SMTP server are
+   used for assessing whether to perform greylisting.  At its simplest,
+   the attribute is the IP address of the client, and the assessment is
+   whether it has previously connected recently.  More elaborate
+   attribute combinations and more sophisticated assessments can be
+   performed.  The following discussion covers the most common
+   combinations and relies on knowledge of [SMTP], its commands, and the
+   distinction between envelope and content.
+
+2.1.  Connection-Level Greylisting
+
+   Connection-level greylisting decides whether to accept the TCP
+   connection from a "new" [SMTP] client.  At this point in the
+   communication between the client and the server, the only information
+   known to the receiving server is the incoming IP address.  This, of
+   course, is often (but not always) translatable into a host name.
+
+   The typical application of greylisting here is to keep a record of
+   SMTP client IP addresses and/or host names (collectively, "sources")
+   that have been seen.  Such a database acts as a cache of known
+   senders and might or might not expire records after some period.  If
+   the source is not in the database, or the record of the source has
+   not reached some required minimum age (such as 30 minutes since the
+   initial connection attempt), the server does one of the following,
+   inviting a later retry:
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 4]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   o  returns a 421 SMTP reply and closes the connection, or
+
+   o  returns a different 4yz SMTP reply to all further commands in this
+      SMTP session.
+
+   A useful variant of the basic known/unknown policy is to limit
+   greylisting to those addresses that are on some list of IP addresses
+   known to be affiliated with bad actors.  Whereas the simpler policy
+   affects all new connections, including those from good actors, the
+   constrained policy applies greylisting actions only to sites that
+   already have a negative reputation.
+
+2.2.  SMTP HELO/EHLO Greylisting
+
+   HELO/EHLO greylisting refers to the first command verb in an SMTP
+   session.  It includes a single, required parameter that is supposed
+   to contain the client's fully qualified host name or its literal IP
+   address.
+
+   Greylisting implemented at this phase retains a record of sources
+   coupled with HELO/EHLO parameters.  It returns 4yz SMTP replies to
+   all commands until the end of the SMTP session if that tuple has not
+   previously been recorded or if the record exists but has not reached
+   some configured minimum age.
+
+2.3.  SMTP MAIL Greylisting
+
+   MAIL command greylisting refers to the command verb in an SMTP
+   session that initiates a new transaction.  It includes at least one
+   required parameter that indicates the return email address
+   (RFC5321.MailFrom) of the message being relayed from the client to
+   the server.
+
+   Greylisting implemented at this phase retains a record of sources
+   coupled with return email addresses.  It returns 4yz SMTP replies to
+   all commands for the remainder of the SMTP session if that tuple has
+   not previously been recorded or if the record exists but has not met
+   some configured minimum age.
+
+2.4.  SMTP RCPT Greylisting
+
+   RCPT greylisting refers to the command verb in an SMTP session that
+   specifies intended recipients of an email transaction.  It includes
+   at least one required parameter that indicates the email address of
+   an intended recipient of the message being relayed from the client to
+   the server.
+
+
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 5]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   Greylisting implemented at this phase retains a record of tuples that
+   combines the provided recipient address with any combination of the
+   following:
+
+   o  the source, as described above;
+
+   o  the return email address; and
+
+   o  the other recipient addresses of the message (if any).
+
+   If the selected tuple is not found in the database, or if the record
+   is present but has not reached some configured minimum age, the
+   greylisting Mail Transfer Agent (MTA) [EMAIL-ARCH] returns 4yz SMTP
+   replies to all commands for the remainder of the SMTP session.
+
+   Note that often a match on a tuple involving the first valid RCPT is
+   sufficient to identify a retry correctly, and further checks can be
+   omitted.
+
+2.5.  SMTP DATA Greylisting
+
+   DATA greylisting refers to the command verb in an SMTP session that
+   transmits the actual message content, as opposed to its envelope
+   details.
+
+   This type of greylisting can be performed at two places in the SMTP
+   sequence:
+
+   1.  on receipt of the DATA command, because at that point the entire
+       envelope has been received (i.e., all MAIL and RCPT commands have
+       been issued); or
+
+   2.  on completion of the DATA command, i.e., after the "." that
+       terminates transmission of the message body, since at that point
+       a digest or other analysis of the message could be performed.
+
+   Some implementations do filtering here because there are clients that
+   don't bother checking SMTP reply codes to commands other than DATA.
+   Hence, it can be useful to add greylisting capability at that point
+   in an SMTP session.
+
+   Numerous greylisting policies are possible at this point.  All of
+   them retain a record of tuples that combine the various parts of the
+   SMTP transaction in some combination, including:
+
+   o  the source, as described above;
+
+   o  the return email address;
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 6]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   o  the recipients of the message, as a set or individually;
+
+   o  identifiers in the message header, such as the contents of the
+      RFC5322.From or RFC5322.To fields;
+
+   o  other prominent parts of the content, such as the RFC5322.Subject
+      field;
+
+   o  a digest of some or all of the message content, as a test for
+      uniqueness; and
+
+   o  analysis of arbitrary portions of the message body.
+
+   (The last four items in the list above are only possible at the end
+   of DATA, not on receipt of the DATA command.)
+
+   If the selected tuple is not found in the database, or if the record
+   exists but has not reached some configured minimum age, the
+   greylisting MTA returns 4yz SMTP replies to all commands for the
+   remainder of the SMTP session.
+
+2.6.  Additional Heuristics
+
+   Since greylisting seeks to target spam senders, it follows that being
+   able to identify spamware within the SMTP context beyond the simple
+   notion of "not seen before" would be desirable.  A more targeted
+   approach might also include in its selection heuristics such as the
+   following:
+
+   o  If a DNS blacklist [DNSBL] lists an IP address but the implementer
+      wishes to be cautious with mitigation actions rather than blocking
+      traffic from the IP address outright, then subject it to
+      greylisting.
+
+   o  If the value found in a PTR record follows common naming patterns
+      for dynamic IP addresses, then subject it to greylisting.
+
+2.7.  Exceptions
+
+   Most greylisting systems provide for an exception mechanism, allowing
+   one to specify IP addresses, IP address Classless Inter-Domain
+   Routing (CIDR) [CIDR] blocks, host names, or domain names that are
+   exempt from greylisting checks and thus whose SMTP client sessions
+   are not subject to such interference.
+
+   Likely candidates to be excepted from greylisting include those known
+   not to retry according to a pattern that will be observed as
+   legitimate and those that send so rarely that they will age out of
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 7]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   the database.  In both cases, the excepted source is known not to be
+   an abusive one by the site implementing greylisting.  Otherwise,
+   typical non-abusive senders will enter the exception list on the
+   first proper retry and remain there permanently.
+
+   One could also use a [DNSBL] that lists known good hosts as a
+   greylisting exception set.
+
+3.  Benefits and Costs
+
+   The most obvious benefit with any of the above techniques is that
+   spamware generally does not retry and is therefore less likely to
+   succeed, absent a record of a previous delivery attempts.
+
+   The most obvious detriment to implementing greylisting is the
+   imposition of delay on legitimate mail.  Some popular MTAs do not
+   retry failed delivery attempts for an hour or more, which can cause
+   expensive delays when delivery of mail is time critical.  Worse, some
+   legitimate MTAs do not retry at all.  (Note, however, that non-
+   retrying clients are not fully SMTP-capable, per Section 2.1 of
+   [SMTP].  A client does not know, nor is it entitled to know, the
+   reason for the temporary failure status code being returned;
+   greylisting could be in effect, or it could be caused by a local
+   resource issue at the server.  A client therefore needs to be
+   equipped to retry in order to be considered fully capable.)
+
+   The counterargument to this "false positive" problem is that email
+   has always been a "best-effort" mechanism; thus, this cost is
+   ultimately low in comparison to the cost of dealing with high volumes
+   of unwanted mail.  Still, the actual effect of such delays can be
+   significant, such as altering the tone or flow of a multi-participant
+   discussion to a mailing list.
+
+   When the clients are subjected to any kind of reconfiguration,
+   especially network renumbering, the cache of information stored about
+   SMTP client history does not benefit legitimate clients that are
+   already listed for acceptance.  To the greylisting implementation,
+   such clients are once again unknown, and they will once again be
+   subjected to the delay.
+
+   Another obvious cost is for the required database.  It has to be
+   large enough to keep the necessary history and fast enough to avoid
+   excessive inefficiencies in the server's operations.  The primary
+   consideration is the maximum age of records in the database.  If
+   records age out too soon, then hosts that do retry per [SMTP] will be
+   periodically subjected to greylisting even though they are well-
+
+
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 8]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   behaved; if records age out after too long a period, then eventually
+   spamware that launches a new campaign will not be identified as
+   "unknown" in this manner and will not be required to retry.
+
+   Presuming that known friendly senders will be manually configured as
+   exceptions to the greylisting check, a steady state will eventually
+   be reached wherein the only mail that is delayed is mail from an IP
+   address that has never sent mail before.  Experience suggests that
+   the vast majority of mail comes from places on a developed exception
+   list, so after a training period, only a small proportion of mail is
+   actually affected.  The training period could be replaced by
+   processing a history of email traffic and adding the IP addresses
+   from which most traffic arrives to the exception list.
+
+   Applying greylisting based on actual message content (i.e., post-
+   DATA) is substantially more expensive than any of the other
+   alternatives both in terms of the resources required to accept and
+   temporarily store a complete message body (which can be quite
+   substantial) and any processing that is done on that content.  As a
+   consequence, such methods incur more cost during the session and thus
+   are not typical practice.
+
+4.  Unintended Consequences
+
+4.1.  Unintended Mail Delivery Failures
+
+   There are a few failure modes of greylisting that are worth
+   considering.  For example, consider an email message intended for
+   user@example.com.  The example.com domain is served by two receiving
+   mail servers, one called mail1.example.com and one called
+   mail2.example.com.  On the first delivery attempt, mail1.example.com
+   greylists the client, and thus the client places the message in its
+   outgoing queue for later retry.  Later, when a retry is attempted,
+   mail2.example.com is selected for the delivery, either because
+   mail1.example.com is unavailable or because a round-robin [DNS]
+   evaluation produces that result.  However, the two example.com hosts
+   do not share greylisting databases, so the second host again denies
+   the attempt.  Thus, although example.com has sought to improve its
+   email throughput by having two servers, it has, in fact, amplified
+   the problem of legitimate mail delay introduced by greylisting.
+
+   Similarly, consider a site with multiple outbound MTAs that share a
+   common queue.  On a first outbound delivery attempt to example.com,
+   the attempt is greylisted.  On a later retry, a different outbound
+   MTA is selected, which means example.com sees a different source, and
+   once again greylisting occurs on the same message.  The same effect
+   can result from the use of [DHCP], where the IP address of an
+   outbound MTA changes between attempts.
+
+
+
+Kucherawy & Crocker          Standards Track                    [Page 9]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   For systems that do DATA-level greylisting, if any part of the
+   message has changed since the first attempt, the tuple constructed
+   might be different than the one for the first attempt, and the
+   delivery is again greylisted.  Some MTAs do reformulate portions of
+   the message at submission time, and this can produce visible
+   differences for each attempt.
+
+   A host that sends mail to a particular destination infrequently might
+   not remain "known" in the receiving server's database and will
+   therefore be greylisted for a high percentage of mail despite
+   possibly being a legitimate sender.
+
+   All of these and other similar cases can cause greylisting to be
+   applied improperly to legitimate MTAs multiple times, leading to long
+   delays in delivery or ultimately the return of the message to its
+   sender.  Other side effects include out-of-order delivery of related
+   sequenced messages.
+
+   Address translation technologies such as [NAT] cause distinct MTAs to
+   appear to come from a common IP address.  This can cause greylisting
+   to be applied only to the first connection attempt from the shared IP
+   address, meaning future MTAs connecting for the first time will be
+   exempted from the protection greylisting provides.
+
+4.2.  Unintended SMTP Client Failures
+
+   Atypical SMTP client behaviors also need to be considered when
+   deploying greylisting.
+
+   Some clients do not retry messages for very long periods.  Popular
+   open source MTAs implement increasing backoff times when messages
+   receive temporary failure messages and/or degrade queue priority for
+   very large messages.  This means greylisting introduces even more
+   delay for MTAs implementing such schemes, and the delay can become
+   large enough to become a nuisance to users.
+
+   Some clients do not retry messages at all, in violation of [SMTP].
+   This means greylisting will cause outright delivery failure right
+   away for sources, envelopes, or messages that it has not seen before,
+   regardless of the client attempting the delivery, essentially
+   treating legitimate mail and spam the same.
+
+   If a greylisting scheme requires a database record to have reached a
+   certain age rather than merely testing for the presence of the record
+   in the database, and the client has a retry schedule that is too
+   aggressive, the client could be subjected to rate limiting by the MTA
+   independent of the restrictions imposed by greylisting.
+
+
+
+
+Kucherawy & Crocker          Standards Track                   [Page 10]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   Some SMTP implementations make the error of treating all error codes
+   as fatal, contrary to [SMTP]; that is, a 4yz response is treated as
+   if it were a 5yz response, and the message is returned to the sender
+   as undeliverable.  This can result in such things as inadvertent
+   removal from mailing lists in response to the perceived rejections.
+
+   Some clients encode message-specific details in the address parameter
+   to the [SMTP] MAIL command.  If doing so causes the parameter to
+   change between retry attempts, a greylisting implementation could see
+   it as a new delivery rather than a retry and disallow the delivery.
+   In such cases, the mail will never be delivered and will be returned
+   to the sender after the retry timeout expires.
+
+   A client subjected to greylisting might move to the next host found
+   in the ordered [DNS] MX record set for the destination domain and re-
+   attempt delivery.  This has several considerations of its own:
+
+   o  Traffic to those alternate servers increases merely as a result of
+      greylisting.
+
+   o  Alternate (MX) servers SHOULD share the same greylisting database.
+      When they do not -- as is often true when the servers occupy
+      different Administrative Management Domains (ADMDs) -- SMTP
+      clients can see variable treatment if they try to send to
+      different MX hosts.
+
+   o  When alternate MX servers relay mail back to the "primary" MX
+      server, the latter SHOULD be configured to permit the other
+      servers to relay mail without being subjected to greylisting.
+
+   There are some applications that connect to an SMTP server and
+   simulate a transaction up to the point of sending the RCPT command in
+   an attempt to confirm that an address is valid.  Some of these are
+   legitimate applications (e.g., mailing list servers), and others are
+   automated programs that attempt to ascertain valid addresses to which
+   to send spam (a "directory harvesting" attack).  Greylisting can
+   interfere with both instances, with harmful effects on the former.
+
+4.3.  Address Space Saturation
+
+   Greylisting is obviously not a foolproof solution to avoiding abusive
+   traffic.  Bad actors that send mail with just enough frequency to
+   avoid having their records expire will never be caught by this
+   mechanism after the first instance.
+
+
+
+
+
+
+
+Kucherawy & Crocker          Standards Track                   [Page 11]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   Where this is a concern, combining greylisting with some form of
+   reputation service that estimates the likely behavior for IP
+   addresses that are not intercepted by the greylisting function would
+   be a good choice.
+
+5.  Recommendations
+
+   The following practices are RECOMMENDED based on collected
+   experience:
+
+   1.  Implement greylisting based on a tuple consisting of (IP address,
+       RFC5321.MailFrom, and the first RFC5321.RcptTo).  It is
+       sufficient to use only the first RFC5321.RcptTo as legitimate
+       MTAs appear not to reorder recipients between retries.  Including
+       RFC5321.MailFrom improves accuracy where the IP address is being
+       matched in clusters (e.g., CIDR blocks) rather than precisely
+       (see below).  After a successful retry, allow all further [SMTP]
+       traffic from the IP address in that tuple regardless of envelope
+       information.
+
+   2.  Include a configurable range of time within which a retry from a
+       greylisted host is considered and outside of which it is
+       otherwise ignored.  The range needs to cover typical retry times
+       of common MTA configurations, thus anticipating that a fully
+       capable MTA will retry sometime after the beginning of the range
+       and before the end of it.  The default range SHOULD be from one
+       minute to 24 hours.  Retries within the range are permitted and
+       satisfy the greylisting test, and the client is thus no longer
+       likely to be a sender of spam.  Retries after the end of the
+       range SHOULD be considered to be a new message for the purposes
+       of greylisting evaluation (i.e., reset the "first seen" timestamp
+       for that IP address).  Some sites use a higher time value for the
+       low end of the time range to match common legitimate MTA retry
+       timeouts, but additional benefit from doing so appears unlikely.
+
+   3.  Include a timeout for database entries, after which records for
+       IP addresses that have generated no recent traffic are deleted.
+       This step is intended to re-enable greylisting for an IP address
+       in the event that it has changed "owners" and will subject the
+       client to another round of greylisting.  The default SHOULD be at
+       least one week.
+
+   4.  For an Administrative Management Domain (ADMD), all inbound
+       border MTAs listed in the [DNS] SHOULD share a common greylisting
+       database and common greylisting policies.  This handles sequences
+       in which a client's retry goes to a different server after the
+       first 4yz reply, and it lets all servers share the list of hosts
+       that did retry successfully.
+
+
+
+Kucherawy & Crocker          Standards Track                   [Page 12]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   5.  To accommodate those senders that have clusters of outgoing mail
+       servers, greylisting servers MAY track CIDR blocks of a size of
+       its own choosing, such as /24, rather than the full IPv4 address.
+       (Note, however, that this heuristic will not work for clusters
+       having machines on different networks.)  A similar grouping
+       capability MAY be established based on the domain name of the
+       mail server if one can be determined.
+
+   6.  Include a manual override capability for adding specific IP
+       addresses or network blocks that always bypass checks.  There are
+       legitimate senders that simply don't respond well to greylisting
+       for a variety of reasons, most of which do not conflict with
+       [SMTP].  There are also some highly visible online entities such
+       as email service providers that will be certain to retry; thus,
+       those that are known SHOULD be allowed to bypass the filter.
+
+   7.  Greylisting SHOULD NOT be applied by an ADMD's submission service
+       (see [SUBMISSION]) for authenticated client hosts.  It also
+       SHOULD not be applied against any authenticated ADMD session.
+       Authentication can include whatever mechanisms are deemed
+       appropriate for the ADMD, such as known internal IP addresses,
+       protocol-level client authentication, or the like.
+
+   There is no specific recommendation as to the specific choice of 4yz
+   code to be returned as a result of a greylisting delay.  Per [SMTP],
+   however, the only two reasonable choices are 421 if the
+   implementation wishes to terminate the connection immediately and 450
+   otherwise.  It is possible that some clients treat different 4yz
+   codes differently, but no data is available on whether using 421
+   versus some other 4yz code is particularly advantageous.
+
+   There is also no specific recommendation as to the choice of text to
+   include in the SMTP reply, if any.  Some implementers argue that
+   indicating that greylisting is in effect can give spamware a hint as
+   to when to try again for successful delivery, while others suspect
+   that it won't matter to spamware and thus the more likely audience is
+   legitimate senders seeking to understand why their mail is being
+   delayed.
+
+6.  Measuring Effectiveness
+
+   A few techniques are common when measuring the effectiveness of
+   greylisting in a particular installation:
+
+   o  Arrange to log the spam versus legitimate determinations of
+      messages and what the greylisting decision would have been if
+      enabled; then determine whether there is a correlation (and, of
+      course, whether too much legitimate email would also be affected).
+
+
+
+Kucherawy & Crocker          Standards Track                   [Page 13]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   o  Continuing from the previous point, query the set of IP addresses
+      subjected to greylisting in any popular [DNSBL] to see if there is
+      a strong correlation.
+
+7.  IPv6 Applicability
+
+   The descriptions and recommendations presented in this memo are based
+   on many years of experience with greylisting in the IPv4 Internet
+   environment, so they clearly pertain to IPv4 deployments only.
+
+   The greater size of an IPv6 address seems likely to permit
+   differences in behaviors by bad actors, and this could well mean
+   needing to alter the details for applying greylisting; it might even
+   negate any benefits in using greylisting at all.  At a minimum, it is
+   likely to call for different specific choices for any greylisting
+   algorithm variables.
+
+   In addition, an obvious consideration is that the size of the
+   database required to store records of all of the IP addresses seen
+   will likely be substantially larger in the IPv6 environment.
+
+8.  Security Considerations
+
+   This section discusses potential security issues related to
+   greylisting.
+
+8.1.  Trade-Offs
+
+   The discussion above highlights the fact that, although greylisting
+   provides some obvious and valuable defenses, it can introduce
+   unintentional and detrimental consequences for delivery of legitimate
+   mail.  Where timely delivery of email is essential, especially for
+   financial, transactional, or security-related applications, the
+   possible consequences of such systems need to be carefully
+   considered.
+
+   Specific sources can be exempted from greylisting, but, of course,
+   that means they have elevated privilege in terms of access to the
+   mailboxes on the greylisting system, and malefactors can seek to
+   exploit this.
+
+8.2.  Database
+
+   The database that has to be maintained as part of any greylisting
+   system will grow as the diversity of its SMTP clients' hosts grows
+   and, of course, is larger in general depending on the nature of the
+   tuple stored about each delivery attempt.  Even with a record aging
+   policy in place, such a database could grow large enough to interfere
+
+
+
+Kucherawy & Crocker          Standards Track                   [Page 14]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   with the system hosting it, or at least to a point at which
+   greylisting service is degraded.  Moreover, an attacker knowing which
+   greylisting scheme is in use could rotate parameters of SMTP clients
+   under its control, in an attempt to inflate the database to the point
+   of denial-of-service.
+
+   Implementers could consider configuring an appropriate failure policy
+   so that something locally acceptable happens when the database is
+   attacked or otherwise unavailable.
+
+   In practice, this has not appeared as a serious concern, because any
+   reasonable aging policy successfully moderates database growth.  It
+   is nevertheless identified here as a consideration as there may be
+   implementations in some environments where this is indeed an issue.
+
+9.  References
+
+9.1.  Normative References
+
+   [EMAIL-ARCH]  Crocker, D., "Internet Mail Architecture", RFC 5598,
+                 July 2009.
+
+   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SMTP]        Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+                 October 2008.
+
+   [SUBMISSION]  Gellens, R. and J. Klensin, "Message Submission for
+                 Mail", STD 72, RFC 6409, November 2011.
+
+9.2.  Informative References
+
+   [CIDR]        Fuller, V. and T. Li, "Classless Inter-domain Routing
+                 (CIDR): The Internet Address Assignment and Aggregation
+                 Plan", BCP 122, RFC 4632, August 2006.
+
+   [DHCP]        Droms, R., "Dynamic Host Configuration Protocol",
+                 RFC 2131, March 1997.
+
+   [DNS]         Mockapetris, P., "Domain names - implementation and
+                 specification", STD 13, RFC 1035, November 1987.
+
+   [DNSBL]       Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
+                 February 2010.
+
+   [MAIL]        Resnick, P., Ed., "Internet Message Format", RFC 5322,
+                 October 2008.
+
+
+
+Kucherawy & Crocker          Standards Track                   [Page 15]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+   [NAT]         Srisuresh, P. and K. Egevang, "Traditional IP Network
+                 Address Translator (Traditional NAT)", RFC 3022,
+                 January 2001.
+
+   [PUREMAGIC]   Harris, E., "The Next Step in the Spam Control War:
+                 Greylisting", August 2003,
+                 <http://projects.puremagic.com/greylisting/
+                 whitepaper.html>.
+
+   [SAUCE]       Jackson, I., "GNU SAUCE", 2001,
+                 <http://www.gnu.org/software/sauce>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy & Crocker          Standards Track                   [Page 16]
+
+RFC 6647                       Greylisting                     June 2012
+
+
+Appendix A.  Acknowledgments
+
+   The authors wish to acknowledge Mike Adkins, Steve Atkins, Mihai
+   Costea, Derek Diget, Peter J. Holzer, John Levine, Chris Lewis, Jose-
+   Marcio Martins da Cruz, John Klensin, S. Moonesamy, Suresh
+   Ramasubramanian, Mark Risher, Jordan Rosenwald, Gregory Shapiro, Joe
+   Sniderman, Roland Turner, and Michael Wise for their contributions to
+   this memo.  The various participants of the MAAWG Open Sessions about
+   greylisting were also valued contributors.
+
+Authors' Addresses
+
+   Murray S. Kucherawy
+   Cloudmark
+   128 King St., 2nd Floor
+   San Francisco, CA  94107
+   US
+
+   Phone: +1 415 946 3800
+   EMail: superuser@gmail.com
+
+
+   Dave Crocker
+   Brandenburg InternetWorking
+   675 Spruce Dr.
+   Sunnyvale, CA  94086
+   USA
+
+   Phone: +1.408.246.8253
+   EMail: dcrocker@bbiw.net
+   URI:   http://bbiw.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy & Crocker          Standards Track                   [Page 17]
+