RFC 6647

Email Greylisting: An Applicability Statement for SMTP

📅 published June 2012, from ietf

Title Block 📜

Okay bestie, here's the paperwork! This is RFC 6647, titled Email Greylisting: An Applicability Statement for SMTP 🦋 It came out in June 2012 from the IETF (Internet Engineering Task Force) and it's a Standards Track doc, so it's meant to be implemented 💅 The authors are M. Kucherawy from Cloudmark and D. Crocker from Brandenburg InternetWorking 🫶 The ISSN is 2070-1721. The title block doesn't list anything this RFC obsoletes or updates, so it's not replacing or patching any older docs 🌸

Abstract

Okay so this doc is all about email greylisting 💖 It's the practice of giving unknown email clients a temporarily worse service as an anti-abuse move. Think bouncer making you wait outside the club until they know you're legit 🚪✨

Greylisting is an established mechanism, and it's basically considered essential in the current anti-abuse email filtering toolkit 👑 Iconic, honestly.

Status of This Memo

This is an Internet Standards Track document 🎀

This doc is a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🌈

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6647 🔗

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) as they stand on the date this was published. Please actually read these docs carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License 💜

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

1. Introduction ✨

Okay so the preferred ways to handle email abuse explicitly sort senders into good actors and bad actors, and they give each group a really different level of service 💅 Sometimes an actor has no known reputation at all. That can justify degraded service until there's a reason to upgrade them to better service. That in-between approach is what's called "greylisting" 🦋

Broadly, the term means any degradation of service for an unknown or suspicious source over a period of time, usually measured in minutes or a small number of hours ⏳ The narrow version refers to sending an SMTP temporary failure reply code to traffic from those sources. There are lots of different implementations of this basic idea, so, predictably, the terminology gets a little blurry 🌀

Here's the thing: without a perfect abuse-detection mechanism that costs nothing, filtering systems need a whole array of techniques 🧰 They vary in cost, in how effective they are, and in which types of abuse they target.

Greylisting is cheap, it runs early in the SMTP sequence, and it's surprisingly still useful 🔥 Some spamware does route around it, but a lot of it doesn't.

The firehose of spam on the Internet covers a wide range of sophistication levels. Greylisting is great for clearing out a big pile of simple-but-significant traffic 🧹

This memo documents common greylisting techniques and talks about their benefits and costs 📝 It also defines terminology so everyone can clearly tell these techniques apart and talk about them without confusion 🌈

Also, there's some confusion in the industry where people treat greylisting as the same thing as an SMTP temporary failure for any reason 🙈 Part of this memo's job is to clear that up, bestie.

1.1. Background 🧠

For years, a huge amount of spam has been sent through purpose-built software, called "spamware," that only supports a constrained version of SMTP 💀 The key thing is that this software doesn't retry after getting an SMTP temporary failure. If it can't deliver a message, it just moves on to the next address on its list, because for spammers, volume matters way more than reliability 📬

Greylisting takes advantage of that by rejecting mail from unfamiliar sources with a "transient (soft) fail" (4xx) [SMTP] error code 😈 Another use of greylisting is to delay mail from newly seen IP addresses. The theory is that if it's a spam source, then by the time it retries, it'll show up on a list of sources to be filtered, and the mail won't get 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 mostly happens during some phase of an SMTP session 💌 A set of attributes about the client-side SMTP server gets used to figure out whether to greylist. At its simplest, the attribute is the client's IP address, and the check is whether it has connected recently. You can do fancier attribute combos and more sophisticated checks too ✨ The discussion below covers the most common combinations, and it assumes you already know [SMTP], its commands, and the difference 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, the only info the receiving server knows is the incoming IP address. That address can often (but not always) be turned into a host name, which is neat 🌸

The usual move here is to keep a record of SMTP client IP addresses and/or host names (together called "sources") that have been seen 📒 That database works like a cache of known senders, and it might or might not expire records after some period. If the source isn't in the database, or its record hasn't reached some required minimum age (like 30 minutes since the initial connection attempt), the server does one of the following, which invites a later retry 🔁

  • returns a 421 SMTP reply and closes the connection, or
  • returns a different 4yz SMTP reply to all further commands in this SMTP session.

There's a useful variant of the basic known/unknown policy where you only greylist addresses that appear on some list of IP addresses known to be tied to bad actors 🕵️‍♀️ The simpler policy hits all new connections, including the good actors. The constrained policy only applies greylisting actions to sites that already have a negative reputation, so it's way more targeted 🎯

2.2. SMTP HELO/EHLO Greylisting 👋

HELO/EHLO greylisting is about the first command verb in an SMTP session 💬 It has a single, required parameter that's supposed to contain the client's fully qualified host name or its literal IP address.

Greylisting at this phase keeps a record of sources paired with HELO/EHLO parameters 📋 It returns 4yz SMTP replies to all commands until the end of the SMTP session if that tuple hasn't been recorded before, or if the record exists but hasn't reached some configured minimum age ⏰

2.3. SMTP MAIL Greylisting 📬

MAIL command greylisting is about the command verb in an SMTP session that starts 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 at this phase keeps a record of sources paired with return email addresses 🗂️ It returns 4yz SMTP replies to all commands for the rest of the SMTP session if that tuple hasn't been recorded before, or if the record exists but hasn't met some configured minimum age 🙃

2.4. SMTP RCPT Greylisting 💌

RCPT greylisting is about the command verb in an SMTP session that specifies the 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.

Greylisting at this phase keeps a record of tuples that combine the provided recipient address with any combination of the following:

  • the source, as described above;
  • the return email address; and
  • the other recipient addresses of the message (if any).

If the selected tuple isn't in the database, or the record is there but hasn't reached some configured minimum age, the greylisting Mail Transfer Agent (MTA) [EMAIL-ARCH] returns 4yz SMTP replies to all commands for the rest of the SMTP session 🛑

Note that a match on a tuple involving the first valid RCPT is often enough to identify a retry correctly, so further checks can be skipped 🦋✨

2.5. SMTP DATA Greylisting ✨

okay bestie, so DATA greylisting is about the command verb in an SMTP session that actually carries the message content 💌, as opposed to the envelope details (the stuff about who's sending and who's receiving) 📮

this can happen in two spots in the SMTP sequence 👀:

  1. when the DATA command comes in, because at that point the whole envelope has already arrived (aka every MAIL and RCPT command has been sent) 📬; or
  2. when the DATA command wraps up, i.e., after the "." that ends the message body, since at that point you can do a digest or other analysis of the message 🧠

some implementations filter here because there are clients that don't bother checking SMTP reply codes for commands other than DATA 💀, so it can be super useful to add greylisting at that point in the session 🫶

there are tons of greylisting policies possible here ✨. they all keep a record of tuples that mash together different parts of the SMTP transaction in some combo, like:

  • the source, as described above;
  • the return email address;
  • the recipients of the message, as a set or individually;
  • identifiers in the message header, like the contents of the RFC5322.From or RFC5322.To fields;
  • other prominent parts of the content, like the RFC5322.Subject field;
  • a digest of some or all of the message content, as a test for uniqueness; and
  • analysis of arbitrary portions of the message body.

(the last four items above only work at the end of DATA, not when DATA first comes in 🙈)

if the chosen tuple isn't in the database, or the record exists but hasn't reached some configured minimum age, the greylisting MTA returns 4yz SMTP replies to all commands for the rest of the SMTP session 🫠

2.6. Additional Heuristics 🔍

since greylisting is all about targeting spam senders, it makes sense that being able to spot spamware within the SMTP context, beyond the simple "not seen before" thing, would be 😍 desirable. a more targeted approach might also include selection heuristics like these:

  • If a DNS blacklist [DNSBL] lists an IP address but the implementer wants to be cautious with mitigation actions instead of blocking traffic from that IP address outright, then subject it to greylisting.
  • 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 have an exception mechanism 💫 that lets you specify IP addresses, IP address Classless Inter-Domain Routing (CIDR) [CIDR] blocks, host names, or domain names that are exempt from greylisting checks, so their SMTP client sessions aren't subject to that interference.

likely candidates to be excepted are those known not to retry on a pattern that will be seen as legitimate, and those that send so rarely that they'll age out of the database 💅. in both cases, the site doing greylisting knows the excepted source isn't abusive. otherwise, typical non-abusive senders will land on the exception list on their first proper retry and stay there forever 🥹

one could also use a [DNSBL] that lists known good hosts as a greylisting exception set 🫶

3. Benefits and Costs 💸

the most obvious benefit of any of these techniques is that spamware generally doesn't retry, so it's less likely to succeed, unless there's a record of a previous delivery attempt 🚫

the most obvious downside of greylisting is the delay it puts on legitimate mail 😭. some popular MTAs don't retry failed delivery attempts for an hour or more, which can cause expensive delays when mail is time critical. worse, some legitimate MTAs don't retry at all 💀. (note, though, that non-retrying clients aren't fully SMTP-capable, per Section 2.1 of [SMTP]. a client doesn't know, and isn't entitled to know, the reason for the temporary failure status code it's getting. greylisting could be in effect, or it could be caused by a local resource issue at the server. so a client 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, so this cost is ultimately low compared to the cost of dealing with high volumes of unwanted mail 📩. still, the actual effect of these delays can be significant, like altering the tone or flow of a multi-participant discussion on a mailing list 🗣️

when clients get any kind of reconfiguration, especially network renumbering, the cache of information stored about SMTP client history doesn't help legitimate clients that are already listed for acceptance. to the greylisting implementation, those clients are once again unknown, so they'll be subjected to the delay again 🔄

another obvious cost is 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're well-behaved 😤. if records age out after too long a period, then eventually spamware that launches a new campaign won't be identified as "unknown" this way, and won't be required to retry 👀

presuming that known friendly senders are manually configured as exceptions to the greylisting check, a steady state will eventually be reached, where the only mail that's delayed is mail from an IP address that has never sent mail before ✨. experience suggests 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 that most traffic arrives from to the exception list 🧾

applying greylisting based on actual message content (aka 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's done on that content. as a consequence, those methods incur more cost during the session, and so they aren't 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, say there's 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, so the client places the message in its outgoing queue for a 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. but the two example.com hosts don't share greylisting databases, so the second host again denies the attempt 😩. so even though example.com 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.

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 ✨

Okay so, not every SMTP client behaves like the textbook says, and you have to plan for that when you deploy greylisting 🫶

Some clients don't retry for very long periods 😭 Popular open source MTAs back off more and more when they get a temporary failure, and some drop the queue priority of very large messages. That means greylisting adds even more delay for MTAs like that, and the delay can get big enough to be a real nuisance for users 💀

Some clients don't retry at all, which violates [SMTP] 🙅‍♀️ So greylisting straight up causes an immediate delivery failure for any sources, envelopes, or messages it hasn't seen before. It doesn't care who's trying to deliver, so legit mail and spam get treated exactly the same 💅

If a greylisting scheme needs a database record to have reached a certain age, instead of just checking that the record exists, and the client's retry schedule is too aggressive, the MTA could rate limit that client on top of whatever greylisting is already doing 🚦

Some SMTP implementations make the mistake of treating every error code as fatal, which goes against [SMTP]. So a 4yz response gets handled like a 5yz, and the message gets bounced back to the sender as undeliverable. That can lead to stuff like accidental removal from mailing lists because of those perceived rejections 💔

Some clients encode message-specific details in the address parameter of the [SMTP] MAIL command. If that parameter changes between retry attempts, the greylisting implementation might think it's a brand new delivery instead of a retry, and then disallow it. In that case the mail never gets delivered and gets returned to the sender once the retry timeout expires 📭

A client hit by greylisting might move on to the next host in the ordered [DNS] MX record set for the destination domain and try again there. This comes with a few considerations of its own:

  • Traffic to those alternate servers goes up purely because of greylisting 📈
  • Alternate (MX) servers SHOULD share the same greylisting database. When they don't (which is often the case when the servers sit in different Administrative Management Domains (ADMDs)), SMTP clients can get variable treatment depending on which MX host they try 🎀
  • When alternate MX servers relay mail back to the "primary" MX server, the latter SHOULD be configured to let the other servers relay mail without being subjected to greylisting 🧚

There are apps that connect to an SMTP server and simulate a transaction right up to the RCPT command, just to check whether an address is valid 🔍 Some are legit (mailing list servers, for example), and others are automated programs hunting for valid addresses to spam (a "directory harvesting" attack). Greylisting can interfere with both, and it does more harm to the legit ones 😤

4.3. Address Space Saturation 🙃

Greylisting is obviously not a foolproof way to dodge abusive traffic. Bad actors who send mail just often enough to keep their records from expiring will never get caught by this mechanism after the first instance.

If that's a concern, pairing greylisting with some kind of reputation service that estimates how likely IP addresses are to behave, for the ones greylisting doesn't intercept, 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). Only the first RFC5321.RcptTo is needed, since legit MTAs don't seem to reorder recipients between retries. Including RFC5321.MailFrom improves accuracy where the IP address is matched in clusters (e.g., CIDR blocks) instead of 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 in which a retry from a greylisted host is considered, and outside of which it's ignored. The range needs to cover the typical retry times of common MTA configurations, so a fully capable MTA will retry sometime after the start 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, so the client is no longer likely to be a sender of spam ✨ Retries after the end of the range SHOULD be treated as a new message for greylisting evaluation (i.e., reset the "first seen" timestamp for that IP address). Some sites use a higher value for the low end of the range to match common legit MTA retry timeouts, but extra benefit from doing so seems unlikely 🤔
  3. Include a timeout for database entries, after which records for IP addresses with no recent traffic get deleted. This step is meant to re-enable greylisting for an IP address that has changed "owners," so the new owner goes through 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 where a client's retry goes to a different server after the first 4yz reply, and it lets all the servers share the list of hosts that retried successfully 🫶
  5. To accommodate senders with clusters of outgoing mail servers, greylisting servers MAY track CIDR blocks of a size of their own choosing, such as /24, instead of the full IPv4 address. (Note, however, that this heuristic will not work for clusters with 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 legit senders that simply don't respond well to greylisting for a variety of reasons, most of which don't conflict with [SMTP]. There are also highly visible online entities, like email service providers, that will be certain to retry, so 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's no specific recommendation on which 4yz code to return for a greylisting delay. Per [SMTP], though, the only two reasonable choices are 421 if the implementation wants to terminate the connection immediately, and 450 otherwise. Some clients might treat different 4yz codes differently, but there's no data on whether using 421 over some other 4yz code is particularly advantageous 🧐

There's also no specific recommendation on the text to include in the SMTP reply, if any. Some implementers argue that saying greylisting is in effect could give spamware a hint about when to try again, while others suspect it won't matter to spamware, and the more likely audience is legit senders who want to understand why their mail is being delayed 🤷‍♀️

6. Measuring Effectiveness 📊

A few techniques are common when measuring how well greylisting works in a particular installation:

  • Log the spam versus legitimate determinations for messages, plus what the greylisting decision would have been if it were enabled. Then figure out whether there's a correlation (and, of course, whether too much legit email would also be affected) 💅
  • Continuing from the previous point, query the set of IP addresses subjected to greylisting in any popular [DNSBL] to see if there's a strong correlation 🔥

7. IPv6 Applicability 🌐

The descriptions and recommendations 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 different behaviors by bad actors. That could mean needing to change the details for applying greylisting, and it might even negate any benefits of using greylisting at all 😬 At a minimum, it's likely to call for different specific choices for any greylisting algorithm variables.

An obvious consideration too: the database needed to store records of all the IP addresses seen will likely be substantially larger in an IPv6 environment 📦

8. Security Considerations 🔒

This section discusses potential security issues related to greylisting. Pay attention, bestie, this part matters 🚨

8.1. Trade-Offs ⚖️

The discussion above highlights that, although greylisting provides some obvious and valuable defenses, it can introduce unintentional and detrimental consequences for the delivery of legitimate mail. Where timely delivery of email is essential, especially for financial, transactional, or security-related applications, the possible consequences of these 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 grows as the diversity of its SMTP clients' hosts grows. It's also 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 with the system hosting it, or at least to the point where greylisting service is degraded. Moreover, an attacker who knows 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 hasn't appeared to be a serious concern, because any reasonable aging policy successfully moderates database growth. It's still identified here as a consideration, though, since there may be implementations in some environments where this is indeed an issue 🌈

9. References ✨

9.1. Normative References

Okay, these are the must-read ones bestie 📚✨

  • [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

These ones are the extra reading that's lowkey so good for background 🧠💜

  • [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. 📨
  • [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>. 🍝

Appendix A. Acknowledgments ✨

Huge thank-you to everyone who helped make this memo happen 🫶 The authors want to shout out 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, and they absolutely deserve their flowers 💐🌈

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
📦 where this page comes from