RFC 6650

RFC 6650 💌 Creation and Use of Email Feedback Reports 🦋

Title: Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) 💅 Series: Internet Engineering Task Force (IETF), Request for Comments: 6650 ✨ Authors: J. Falk (Return Path) and M. Kucherawy, Ed. (Cloudmark) 🫶 Category: Standards Track 👑 Date: June 2012 🌸 ISSN: 2070-1721 Updates: RFC 5965 (this one builds on it, bestie 🧚) Obsoletes: not listed in the title block

Abstract 🌸

Okay so, RFC 5965 defines an extensible, machine-readable format that mail operators can use to send feedback about received email to other parties 📬. This applicability statement walks through common ways to use that format for reporting both abuse and authentication failure events 🔥. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a starting point and build their own procedures around whatever suits them best 💖. A few related optional mechanisms get discussed too ✨.

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/rfc6650. 🦋

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. 🫶

Table of Contents 🗂️

1. Introduction ....................................................3
2. Definitions .....................................................4
3. Solicited and Unsolicited Reports ...............................4
4. Generating and Handling Solicited Abuse Reports .................4
   4.1. General Considerations for Feedback Providers ..............4
   4.2. Where to Send Reports ......................................5
   4.3. What to Put in Reports .....................................5
   4.4. General Considerations for Feedback Consumers ..............5
   4.5. What to Expect .............................................6
   4.6. What to Do with Reports ....................................6
5. Generating and Handling Unsolicited Abuse Reports ...............6
   5.1. General Considerations .....................................6
   5.2. When to Generate Reports ...................................7
   5.3. Where to Send Reports ......................................7
   5.4. What to Put in Reports .....................................8
   5.5. What to Do with Reports ....................................9
6. Generating Automatic Authentication Failure Reports ............10
7. Security Considerations ........................................11
   7.1. Security Considerations in Other Documents ................11
   7.2. Forgeries .................................................11
   7.3. Amplification Attacks .....................................11
   7.4. Automatic Generation ......................................11
   7.5. Reporting Multiple Incidents ..............................12
8. Acknowledgements ...............................................13
9. References .....................................................13
   9.1. Normative References ......................................13
   9.2. Informative References ....................................14

1. Introduction ✨

So the Abuse Reporting Format (ARF) was originally built for two very specific use cases 🔥. First up, it was meant for feedback between big email operators, or from big email operators to end user network access operators. Those parties could be presumed to have automated abuse-handling systems 🤖. Second, those same big mail operators use it to send the same kinds of reports to other entities, including folks who send bulk email for commercial purposes 📣. In both cases, the reports get triggered by a user doing something directly, like clicking a "report spam" button in their email client 🙈.

Other uses for ARF as defined in [RFC5965] have been talked about (and might get documented similarly down the road 👀), but abuse reporting is still the main gig 💖. Authentication failure reporting, via extensions that enable it, has a small amount of adoption so far 🌸.

This applicability statement gives direction for using ARF in both of these contexts 💅. It also includes some statements about using ARF alongside other email technologies 🦋.

The whole point of reporting abusive messages is to stop them from happening again 🛑. The methods in this document focus on automating abuse reporting as much as is practical, so the site's abuse team has less work to do 🫶. There are other reasons why generating abuse feedback is worth it, like training mail filters or reputation trackers, or kicking off investigations into especially egregious abuse 🕵️‍♀️. Those other applications aren't discussed in this memo, so don't look for them here 🙅‍♀️.

If you want more intro to this topic, check out [RFC6449], which has more info about abuse reporting in general 📚. A lot of the specific ARF guidelines in this document were borrowed from the principles in [RFC6449] 💜.

At the time this document was published, five feedback types were registered 🎀. This document only covers two of them: "abuse" [RFC5965] and "auth-failure" [RFC6591]. They're seeing enough real use that applicability statements can be made about them ✨. The other three, "fraud" [RFC5965], "other" [RFC5965], and "not-spam" [RFC6430], are either too new or too seldom used to be included here 🥲.

2. Definitions 📖

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 [RFC2119], and they're meant to replace the Requirement Levels described in Section 3.3 of [RFC2026] 🫶.

Some of the terminology used in this document comes from [RFC5598] 🧠.

"Mailbox Provider" refers to an organization that accepts, stores, and offers access to [RFC5322] messages ("email messages") for end users 📬. That kind of organization has typically implemented SMTP [RFC5321], and it might give access to messages through IMAP [RFC3501], the Post Office Protocol (POP) [RFC1939], a proprietary interface designed for HTTP [RFC2616], or a proprietary protocol 💻.

3. Solicited and Unsolicited Reports 💌

The original application of [RFC5965], and still by far the most common one, is when two mail systems make a private agreement to swap abuse reports. Those reports are usually due to recipients manually reporting messages as spam 🙋‍♀️. We call these solicited reports 💖.

Other uses of ARF involve reports sent between parties that don't know each other 👀. These unsolicited reports are sent without any prior arrangement about the context and meaning of the reports 🌀. So the constraints on how unsolicited reports need to be structured, so they're likely to be useful to the recipient, are very different 🥹. That includes things like which address(es) they can usefully be sent to, what issues they can be used to report, and how the receiver can handle them 📋.

The next sections cover the two cases separately 🦋.

4. Generating and Handling Solicited Abuse Reports 🚨

4.1. General Considerations for Feedback Providers 📤

A Mailbox Provider gets reports of abusive or unwanted mail from its users, most often through a "report spam" button (or something with a similar name) in the MUA (Mail User Agent) 💅. How that message and its associated metadata get moved from the MUA to the Mailbox Provider's ARF processing system isn't defined by any standards document 🤷‍♀️. It's discussed further in Section 3.2 of [RFC6449], though 📚. Policy concerns about collecting this data are discussed in Section 3.4 of [RFC6449] 🔐.

To carry out the recommendations of this memo, the reports are formatted per [RFC5965] and sent as an email message [RFC5322], typically using SMTP [RFC5321] 📨.

Ongoing maintenance of an ARF processing system is discussed in Section 3.6 of [RFC6449] 🛠️.

4.2. Where to Send Reports 📍

The Mailbox Provider SHOULD NOT send reports to addresses that haven't explicitly asked for them 🚫. A valid deviation might come from local policy instructions 📋. How those parties can request the reports is discussed in Section 3.5 of [RFC6449] 🧚.

4.3. What to Put in Reports 📝

The reports SHOULD use Feedback-Type: abuse for the report type 💖. A Mailbox Provider generating the reports can use other types that fit the nature of the abuse being reported. But the operator receiving the reports might not treat different feedback types differently, so keep that in mind 👀.

The following fields are optional in [RFC5965], but they SHOULD be used in this context when their corresponding values are available: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To 🎀. Other optional fields can be included as the implementer sees fit 🌸.

User-identifiable data MAY be obscured as described in [RFC6590] 🫣.

4.4. General Considerations for Feedback Consumers 📥

ARF report streams get set up proactively between Feedback Providers and Feedback Consumers 🤝. Recommendations for getting ready to request feedback are discussed in Section 4.1 of [RFC6449] 📚.

Operators MUST be able to accept ARF [RFC5965] reports as email messages [RFC5322] over SMTP [RFC5321] 📬. These messages, and other types of email messages that can be received, are discussed in Section 4.2 of [RFC6449] 💅.

Recipients of feedback reports that are part of formal feedback arrangements have to be able to handle large volumes of reports 📈. This could mean automating report processing, as discussed in Section 4.4 of [RFC6449] 🤖💖.

4.5. What to Expect 🎀

Okay so the list of valid Feedback-Types is defined in [RFC5965], which set up an IANA registry for valid values so it can be extended 🧚. But here's the tea: to make room for new types that aren't supported yet, an automated report processing system MUST NOT reject (in the SMTP sense) a report based solely on an unknown Feedback-Type. ✨ It can just set reports of unknown types aside for manual handling. However, Mailbox Providers might only make use of the "abuse" Feedback-Type 👀. So report receivers might need to do extra analysis to separate different types of abuse reports after receipt, if they don't already know specifically who sent the report.

Report receivers MUST accept reports that have obscured their user-identifiable data as described in [RFC6590] 🔒. That document also talks about how to handle these reports. This technique is also discussed in Section 4.4 of [RFC6449] 💅.

4.6. What to Do with Reports 🌸

Section 4.3 of [RFC6449] goes over the actions that mail operators might take when they get a report (or a bunch of reports) 🍓.

---

5. Generating and Handling Unsolicited Abuse Reports 💖

5.1. General Considerations 🫶

It is essential for report recipients to be able to throttle the reports being sent to them, so they don't wreck their own installations 😭. That's why Feedback Providers MUST provide a way for report recipients to request that no further reports be sent. Unfortunately, there's no standardized mechanism for these requests yet, and every existing way of meeting this requirement is out-of-band 💀.

Message authentication is generally a good idea, but it's especially important for unsolicited reports, because it helps them be taken seriously and actually get a response 🔥. So, like with any other message, Feedback Providers sending unsolicited reports SHOULD send reports that they expect will pass the Sender Policy Framework (SPF) [RFC4408] and/or DomainKeys Identified Mail (DKIM) [RFC6376] checks ✨.

5.2. When to Generate Reports 🧐

Handling unsolicited reports costs the report receiver a lot, ngl 😩. So senders of unsolicited reports, especially the ones blasting out large volumes automatically, SHOULD NOT send reports that can't be used as a basis for action by the recipient. That includes reports about an incident that isn't abuse-related, reports sent to an email address that won't lead to any action, and reports where the content or format is hard for the recipient to read or use 🙈.

Feedback Providers SHOULD NOT report all mail from a particular sender just because some of it was judged to be abusive 🚫. It's giving overreach.

Mechanical reports of mail that "looks like" spam, based only on the results of inline content analysis tools, SHOULD NOT be sent 🤖. They're subjective, so they're unlikely to give the recipient anything to act on. Complaints that end users make about mail they consider abusive, or mail delivered to "spam trap" or "honeypot" addresses, are way more likely to be accurate, and they MAY be sent 💜.

If a Feedback Provider applies SPF [RFC4408] to arriving messages, a report SHOULD NOT be generated to the RFC5321.MailFrom domain if the SPF evaluation produced a "Fail", "SoftFail", "TempError", or "PermError" report 🙅‍♀️. The reason is that nobody can make a reliable assertion or assumption that use of the domain was authorized. The one valid exception is specific knowledge that the SPF result isn't definitive for that domain under those circumstances. For example, a message that's also signed with DKIM [RFC6376] by the same domain, where that signature validates 🦋.

5.3. Where to Send Reports 📬

Instead of making feedback reports themselves, MUAs SHOULD create abuse reports and send them back to their Mailbox Providers, so the providers can generate and send ARF messages on behalf of end users (see Section 3.2 of [RFC6449]) 🌈. This gives centralized processing and tracking of reports, and it provides training input to filtering systems. The catch is that there's no standard mechanism for this signaling between MUAs and Mailbox Providers to trigger abuse reports 😅.

Feedback Providers SHOULD NOT send reports to recipients that are uninvolved or only peripherally involved 🙅‍♀️. For example, they SHOULD NOT send reports to the operator of every Autonomous System in the path between the apparent originating system and the operator generating the report. Instead, they need to send reports to recipients that are both responsible for the messages and able to do something about them 💅.

Choosing where to send an unsolicited report usually relies on heuristics 🧠. Abuse addresses in WHOIS [RFC3912] records for the IP address relaying the subject message, and/or for the domain name found in the results of a PTR ("reverse lookup") query on that address, are likely reasonable candidates. So is the abuse@domain role address (see [RFC2142]) of related domains 🎀. Unsolicited reports SHOULD NOT be sent to email addresses that aren't clearly intended to handle abuse reports. Legitimate candidates are the ones found in WHOIS records or on a web site that are either explicitly described as an abuse contact or are of the form "abuse@domain" ✨.

When an abusive message is authenticated with a domain-level technology like DKIM [RFC6376] or SPF [RFC4408], the domain that the authentication mechanism verified is often a reasonable candidate for feedback about the message 🦋. For DKIM, though, the authenticated domain does have some responsibility for the mail it sent, but it can be a poor contact point for abuse issues. For example, it could represent the message's author but not its sender, it could identify the bad actor responsible for the message, or it could refer to a domain that can't receive mail at all 💀.

Often, unsolicited reports will mean nothing if they're sent to abuse reporting addresses belonging to the abusive parties themselves 🙃. It's even possible that such reports might reveal information about complainants, which is not it 😭. So reports SHOULD NOT be sent to such addresses if they can be identified beforehand, except where the abusive party is known to be responsive to such reports 🍓.

5.4. What to Put in Reports 📝

Reports SHOULD use Feedback-Type: abuse, but they can use other types as appropriate 💖. Just know that the Mailbox Provider generating the reports can't assume the operator receiving them will treat different Feedback-Types differently 👀.

Reports SHOULD include these optional fields whenever their corresponding values are available and applicable to the report: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To 📋. Other optional fields can be included if the implementer thinks they're appropriate 🌸.

Experience suggests that ARF is a good call in most contexts ✨. Automated recipient systems can handle abuse reports sent in ARF at least as well as any other format, like plain text, with or without a copy of the message attached 💅. That holds even for systems that didn't ask for ARF reports, as long as the reports are generated with the possibility of recipients who don't use automated ARF parsing in mind. Anyone sending unsolicited reports in ARF can legitimately assume that some recipients will only be able to read the human-readable (first, text/plain) part, so they SHOULD include all information needed in this part too 🥹. They SHOULD also make sure the report is readable when viewed as plain text, so low-end ticketing systems get as much help as possible. In extreme cases, skipping these steps may get the report discarded or ignored 🚨.

5.5. What to Do with Reports 🎉

Receivers of unsolicited reports can use the standardized parts of ARF to automate their processing 🤖. No matter who sent the report, they can improve things by separating valid reports from invalid ones. For example, they can look for references to IP address ranges, domains, and mailboxes that the recipient organization is responsible for in the copy of the reported message, and they can correlate multiple reports of similar messages to spot bulk email senders 🔍.

Per Section 4.4 of [RFC6449], a network service provider MAY use ARF data to automatically forward feedback messages to the originating customer 💌.

Published abuse mailbox addresses SHOULD NOT reject non-ARF messages based only on their format, since generating ARF messages can sometimes be unavailable or not applicable 🙏. Deviating from this requirement could happen because of local policy decisions about other message criteria.

Now, [RFC6449] suggests that replying to feedback isn't useful 🙄. But if ARF reports come in and no feedback arrangement has been set up, a non-automated reply might be a good idea, to say what action resulted from the complaint. That can head off more severe filtering by the Feedback Provider 🛡️. Also, using an address that can't receive replies blocks any requests for more information and makes it more likely that future reports get discarded or blocked 😤. So a Feedback Provider sending unsolicited reports SHOULD NOT generate reports for which a reply can't be received. And when an unsolicited report leads to contact with a responsible and responsive party, that data can be saved for future complaint handling and a possible formal (solicited) feedback arrangement later on 🫶. See Section 3.5 of [RFC6449] for a discussion of establishing feedback arrangements 🦋.

6. Generating Automatic Authentication Failure Reports ✨

Okay so, sometimes a report gets made by a robot instead of a person clicking a button 🤖. A big example is reporting, using ARF (or its extensions), on messages that fail certain message authentication checks. [RFC6651] and [RFC6652] are both examples of this. The stuff below applies to those cases 💅.

The applicability statement for this use case is a bit smaller, bestie. A lot of the issues that come with abuse reports just don't apply to reports about authentication failures 🫶.

Automatic feedback generators MUST select actual message recipients based on data provided by willing report receivers. Recipients MUST NOT be selected using heuristics, no exceptions 🙅‍♀️.

If the message under evaluation by the Verifier is an ARF [RFC5965] message, a report MUST NOT be automatically generated 💀.

The message for a new report sent via SMTP MUST be constructed so as to avoid amplification attacks, deliberate or otherwise. The envelope sender address of the report MUST be chosen so that these reports will not generate mail loops 🔁. Similar to Section 2 of [RFC3464], the envelope sender address of the report MUST be chosen to ensure that no feedback reports will be issued in response to the report itself. So when an SMTP transaction is used to send a report, the MAIL FROM command SHOULD use the NULL reverse-path, i.e., MAIL FROM:<> 🌸. The one exception is a reverse-path picked so that SPF checks on the report will pass. In that case, the operator needs to make provisions to avoid the amplification attack or mail loop some other way 👀.

Reports SHOULD use Feedback-Type: auth-failure, but they MAY use other types as appropriate 🦋. Just know that the Mailbox Provider generating the reports can't assume the operator receiving them will treat different Feedback-Types differently 🙈.

These reports SHOULD include the following fields whenever their corresponding values are available. They're optional in [RFC5965], but still lowkey important: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To 📋. Other optional fields can be included if the implementer thinks they're a good idea 💖.

---

7. Security Considerations 🔐

7.1. Security Considerations in Other Documents

Implementers are strongly urged to review, at a minimum, the Security Considerations sections of [RFC5965] and [RFC6449]. Seriously, do not skip these 😭.

7.2. Forgeries

Feedback Providers that relay user complaints directly, rather than by reference to a stored message (e.g., IMAP or POP), could be duped into sending a complaint about a message that the complaining user never actually received. That's an attack on the purported originator of the falsified message 😱. Feedback Providers need to be resilient to such attack methods 🛡️.

Also, these reports may be forged as easily as ordinary Internet electronic mail 📧. User agents and automatic mail handling facilities (such as mail distribution list exploders) that wish to make automatic use of reports of any kind should take appropriate precautions to minimize the potential damage from denial-of-service attacks 🚨.

The simplest way to mitigate this threat is to assert that these reports should themselves be signed with something like DKIM and/or authorized by something like SPF ✍️. Note, though, that if there's a problem with the email infrastructure at either end, DKIM and/or SPF may result in reports that aren't trusted or even accepted by their intended recipients. So it's important to make sure those components are properly configured 🧐. Using both technologies in tandem can resolve this concern to a degree, since they generally have disjoint failure modes. Iykyk 💜.

7.3. Amplification Attacks

Failure to comply with the recommendations regarding selection of the envelope sender can lead to amplification denial-of-service attacks 📢. This is discussed in Section 6 as well as in [RFC3464]. Read them both, no cap 🤓.

7.4. Automatic Generation

ARF [RFC5965] reports have historically been generated individually, as a result of some kind of human request. Think someone clicking a "Report Abuse" button in a mail reader 🖱️. In contrast, the mechanisms described in some extension documents (i.e., [RFC6651] and [RFC6652]) are focused around automated reporting. This obviously implies the potential for much larger volumes or higher frequency of messages, and thus greater mail system load (both for Feedback Providers and report receivers) 📈. It's giving "the server is on fire" energy 🔥.

Those mechanisms are primarily intended for generating reports to help implementers of DKIM [RFC6376], Author Domain Signing Practices (ADSP) [RFC5617], and SPF [RFC4408], and other related protocols during development and debugging 🛠️. They aren't generally intended for prolonged forensic use, specifically because of these load concerns 🙅‍♀️. Extended use is possible, though, by ADministrative Management Domains (ADMDs) that want to keep a close watch for fraud or infrastructure problems 👀. It's important to consider the impact of doing so on both Feedback Providers and the requesting ADMDs 🫶.

A sender requesting these reports can overwhelm its own mail servers. This happens if it sends out signed messages whose signatures fail to verify for some reason, which provokes a large number of reports from Feedback Providers 😵. It works the other way around too: a Feedback Provider could be overwhelmed by a large volume of messages requesting reports whose signatures fail to validate, because it now needs to send reports back to the Signer 💀.

Limiting the rate of generation of these messages may be appropriate, but it threatens to hold back important and possibly time-sensitive information ⏰. It's a tough balance, bestie 🥺.

In general ARF feedback loop terms, it's often suggested that Feedback Providers only create these (or any) ARF reports after an out-of-band arrangement has been made between two parties 🤝. These extension mechanisms give you ways to adjust the parameters of an authorized abuse report feedback loop that's configured and activated by private agreement ✨. The alternative, sending reports automatically based solely on data found in the messages, may have unintended consequences 🙈.

7.5. Reporting Multiple Incidents

If it's known that a particular host generates abuse reports upon certain incidents, an attacker could forge a high volume of messages that will trigger such a report 😈. The recipient of the report could then get inundated with reports. This could easily be extended to a distributed denial-of-service attack by finding a bunch of report-generating servers 🕸️.

The incident count referenced in ARF [RFC5965] provides a limited form of mitigation 🧢. The host that generates reports can elect to send reports only periodically, with each report representing a number of identical or nearly identical incidents. One might even go inverse-exponentially: send reports for each of the first ten incidents, then every tenth incident up to 100, then every 100th incident up to 1000, and so on, until there's some period of relative quiet, after which the limitation resets 📉.

Using this technique for "nearly identical" incidents in particular does cause a dip in reporting quality, though 😬. Say a large number of pieces of spam arrive from one attacker. A reporting agent could decide to send a report about only a fraction of those messages. That averts a flood of reports to a system administrator, but the precise details of each incident aren't sent either 🥲.

Other rate-limiting provisions might be considered. For example, the host could detect a temporary failure response from the report destination and halt report generation to that destination for some period. Or it could simply impose or negotiate a hard limit on the number of reports sent to a particular receiver in a given time frame 🚦.

---

8. Acknowledgements 🫶

The author and editor wish to thank Steve Atkins, John Levine, Shmuel Metz, S. Moonesamy, and Alessandro Vesely for their contributions to this memo 🎀.

All of the best practices referenced by this document are found in [RFC6449], written within the Collaboration Committee of the Messaging Anti-Abuse Working Group (MAAWG) 💜.

Finally, the original author wishes to thank the doctors and staff at the University of Texas MD Anderson Cancer Center for doing what they do 🌈.

---

9. References 📚

9.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
           October 2008.

[RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
           October 2008.

[RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
           July 2009.

[RFC5965]  Shafranovich, Y., Levine, J., and M. Kucherawy, "An
           Extensible Format for Email Feedback Reports", RFC 5965,
           August 2010.

[RFC6591]  Fontana, H., "Authentication Failure Reporting Using the
           Abuse Reporting Format", RFC 6591, April 2012.

9.2. Informative References

[RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
           STD 53, RFC 1939, May 1996.

[RFC2026]  Bradner, S., "The Internet Standards Process --
           Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2142]  Crocker, D., "Mailbox Names for Common Services, Roles and
           Functions", RFC 2142, May 1997.

[RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
           Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
           Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
           for Delivery Status Notifications", RFC 3464,
           January 2003.

[RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
           VERSION 4rev1", RFC 3501, March 2003.

[RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
           September 2004.

[RFC4408]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
           for Authorizing Use of Domains in E-Mail, Version 1",
           RFC 4408, April 2006.

[RFC5617]  Allman, E., Fenton, J., Delany, M., and J. Levine,
           "DomainKeys Identified Mail (DKIM) Author Domain Signing
           Practices (ADSP)", RFC 5617, August 2009.

[RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
           "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
           September 2011.

[RFC6430]  Li, K. and B. Leiba, "Email Feedback Report Type Value:
           not-spam", RFC 6430, November 2011.

[RFC6449]  Falk, J., Ed., "Complaint Feedback Loop Operational
           Recommendations", RFC 6449, November 2011.

[RFC6590]  Falk, J., Ed., and M. Kucherawy, Ed., "Redaction of
           Potentially Sensitive Data from Mail Abuse Reports",
           RFC 6590, April 2012.

[RFC6651]  Kucherawy, M., "Extensions to DomainKeys Identified Mail
           (DKIM) for Failure Reporting", RFC 6651, June 2012.

[RFC6652]  Kitterman, S., "Sender Policy Framework (SPF)
           Authentication Failure Reporting Using the Abuse Reporting
           Format", RFC 6652, June 2012.

---

Authors' Addresses 🎀

J.D. Falk
Return Path
100 Mathilda Place, Suite 100
Sunnyvale, CA  94086
USA

URI:   http://www.returnpath.net/


Murray S. Kucherawy (editor)
Cloudmark
128 King St., 2nd Floor
San Francisco, CA  94107
US

EMail: superuser@gmail.com