| < draft-brotman-srds-01.txt | draft-brotman-srds-02.txt > | |||
|---|---|---|---|---|
| Network Working Group A. Brotman | Network Working Group A. Brotman | |||
| Internet-Draft Comcast, Inc | Internet-Draft Comcast, Inc | |||
| Intended status: Standards Track 30 March 2022 | Intended status: Standards Track 4 April 2022 | |||
| Expires: 1 October 2022 | Expires: 6 October 2022 | |||
| SMTP Response for Detected Spam | SMTP Enhanced Status Codes for Potentially Unwanted Mail | |||
| draft-brotman-srds-01 | draft-brotman-srds-02 | |||
| Abstract | Abstract | |||
| Define a method by which an SMTP receiver can immediately notify a | We define a method by which an SMTP receiver can immediately notify a | |||
| sender that their message is suspected to be spam, though is still | sender that their message is suspected to be unwanted, although it | |||
| being accepted. | may still be accepted. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 1 October 2022. | This Internet-Draft will expire on 6 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 4. The 259 Reply Code . . . . . . . . . . . . . . . . . . . . . 3 | 4. Enhanced status codes . . . . . . . . . . . . . . . . . . . . 3 | |||
| 4.1. Sample conversation . . . . . . . . . . . . . . . . . . . 3 | 4.1. Sample conversation . . . . . . . . . . . . . . . . . . . 3 | |||
| 4.2. Disclosure of Assuredness . . . . . . . . . . . . . . . . 3 | 5. Rationale for the enhanced status codes . . . . . . . . . . . 3 | |||
| 5. Rationale for the 259 Response . . . . . . . . . . . . . . . 4 | ||||
| 5.1. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 4 | 5.1. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 5.2. Senders . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 5.2. Senders . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 | 8. Informative References . . . . . . . . . . . . . . . . . . . 9 | |||
| 9. Informative References . . . . . . . . . . . . . . . . . . . 5 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
| 1. Introduction | 1. Introduction | |||
| Today, a typical SMTP transaction ends with a "250 OK" and the | Today, a typical SMTP transaction ends with a "250 OK" and the | |||
| message is then inspected by the receiver and routed to the inbox or | message is then inspected by the receiver and processesd. In some | |||
| spam folder as appropriate. In some cases, it may be desirable for | cases, it may be desirable for the receiver to provide in-line | |||
| the receiver to provide in-line feedback. This could be done via the | feedback to inform the sender that the message may be considered to | |||
| SMTP response. This document proposes a new response code to | be unwanted. This could be done via enhanced SMTP status codes. | |||
| receivers to optionally use to provide this feedback. | This document proposes new response codes to receivers to provide | |||
| this feedback. | ||||
| This document is intended as an update to [RFC5321]. | ||||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| [RFC2119]. | [RFC2119]. | |||
| 3. Background | 3. Background | |||
| In the email ecosystem, there exist a few mechanisms by which a | In the email ecosystem, there exist a few mechanisms by which a | |||
| receiver or recipient can provide feedback to the sending entity, | receiver or recipient can provide feedback to the sending entity, | |||
| such as Feedback Reports [RFC5965] or Reputation portals. | such as Feedback Reports [RFC5965] or Reputation portals. | |||
| Historically, these have been out-of-band or delayed. In some cases, | Historically, these have been out-of-band or delayed. In some cases, | |||
| this is more than sufficient, and properly conveys information to the | sufficient, and properly conveys information to the sender. Given | |||
| sender. Given the out-of-band nature, these do not allow for | the out-of-band nature, these do not allow for immediate feedback to | |||
| immediate feedback to the sender that their messages may be construed | the sender that their messages may be construed as undesirable by the | |||
| as undesirable by the recipient or some automated system within the | recipient. By providing this feedback to responsible senders, they | |||
| platform. By providing this feedback to responsible senders, they | ||||
| may be able to more immediately use that feedback to remediate the | may be able to more immediately use that feedback to remediate the | |||
| responsible party. In the case of an Email Service Provider or | responsible party. In the case of an Email Service Provider or | |||
| Mailbox Provider, this information could allow them to cease delivery | Mailbox Provider, this information could allow them to track the | |||
| before incurring further risk to recipients. | quality of mail their users or customers send, and stop the user or | |||
| customer from sending when the quality is unacceptably low. | ||||
| 4. The 259 Reply Code | 4. Enhanced status codes | |||
| This document adds the 259 reply code, and defines this as a signal | This document adds ten new enhanced status codes, x.6.20 to x.6.29, | |||
| to the sender that the receiving system believes the attempted | to inform a sender that a message was potentially unwanted. The | |||
| message to be malicious or undesirable in some way. The receiving | codes MUST only be used in the response after the . that indicates | |||
| system intends to accept the message, and then deliver this to the | the end of the message. They can be used either in a 250 response to | |||
| spam folder of the recipients. The code SHOULD only be used when the | accept the message, or a 550 response to refuse it. | |||
| receiving system has already determined the message has been | ||||
| determined to be undesirable. This implies that the receiving system | ||||
| will have evaluated various parts of the message before fully | ||||
| accepting the message. The 259 response code MUST only be used after | ||||
| the . has been used to indicate the end of the message. | ||||
| A sample response could be: | A sample response could be: | |||
| 259 OK - Delivering to spam folder | 250 2.6.23 Message accepted, 40% chance of being unwanted. | |||
| 4.1. Sample conversation | or conversely | |||
| ... | 550 5.6.28 Message refused, 90% chance of being unwanted | |||
| C:DATA | ||||
| S:354 OK | ||||
| C:From: Bob@example.com | ||||
| C:To: Alice@example.net | ||||
| C:Subject: Sample spam message | ||||
| C: | ||||
| C:XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X | ||||
| C: | ||||
| C:. | ||||
| S:259 OK - Delivery to spam folder | ||||
| C:QUIT | ||||
| S:221 mailhost.example.net closing connection | ||||
| 4.2. Disclosure of Assuredness | The ten reply codes are used to indicate a range from 10% to 100% | |||
| likelihood that the message is unwanted. Codes from a single system | ||||
| are expected to be comparable. That is, if a system replies 2.6.22 | ||||
| for one message and 2.6.24 for a second, its evaluation says the | ||||
| second is more likely to be unwanted than the first. Since each | ||||
| system uses its own methods to score incoming mail, there is no | ||||
| expectation that the same message sent to different systems will | ||||
| receive the same code. | ||||
| It may be desirable for the receiver to disclose some sort of value | 4.1. Sample conversation | |||
| to denote assuredness of the malicious verdict. So consider a scale | ||||
| of 0-100 where 0 is a legitimate message and 100 is definitively | ||||
| spam, perhaps the receiver may disclose this as such: | ||||
| 259 OK - Delivery to spam folder (85/100) | ... | |||
| Doing so could aid the sender in determining the strength of this | C:DATA | |||
| signal. Other options could include more detailed information, | S:354 OK | |||
| though the receiver should reference the Security Considerations | C:From: Bob@example.com | |||
| before doing so. | C:To: Alice@example.net | |||
| C:Subject: Sample spam message | ||||
| C: | ||||
| C:blah blah spam blah | ||||
| C: | ||||
| C:. | ||||
| S:250 2.6.23 Message accepted, 40% chance of being unwanted. | ||||
| C:QUIT | ||||
| S:221 mailhost.example.net closing connection | ||||
| 5. Rationale for the 259 Response | 5. Rationale for the enhanced status codes | |||
| Understandably, there are some questions about what benefit this can | Senders would use these codes when they expect a benefit to both the | |||
| provide on both the sending and receiving side. This should be | sending and receiving side. This should be considered from both | |||
| considered from both sides and understand that this could allow for a | sides and understand that this could allow for a more collaborative | |||
| more collaborative interaction. | interaction. | |||
| 5.1. Receivers | 5.1. Receivers | |||
| Receivers could realize some benefit from deploying this signal. The | Receivers could realize some benefit from deploying this signal. The | |||
| signal could help deter senders from continuing to send messages that | signal could help deter senders from continuing to send messages that | |||
| you will only filter into the spam folder. This could help to reduce | their users do not want. This could help to reduce volume into thri | |||
| volume into your platform, reduce storage requirements, and generally | platform, reduce storage requirements, and otherwise reduce incoming | |||
| reduce load on your platform. In the case of an attack, the sender | mai, load. In the message is part of an attack, the sender could see | |||
| could see this signal and terminate the offending sending account. | this signal and block mail from the account. | |||
| 5.2. Senders | 5.2. Senders | |||
| As a sender, using this information can help you understand when your | A sender can use this information to help understand when messages | |||
| messages are spam. Depending on the sources of these messages, that | from its customers or users are unwanted by recipients. Depending on | |||
| could imply that the sender has a bad list of recipients, a malformed | the sources of these messages, that could imply that the sender has a | |||
| message, or truly is spam. An additional possibility is that the | bad list of recipients, a malformed message, or other problems. An | |||
| sending account is compromised or has been created fraudulently for | additional possibility is that the sending account is compromised or | |||
| the express reason of attempting to send undesirable messages. | has been created fraudulently for the express reason of attempting to | |||
| send unwanted messages. | ||||
| 6. Security Considerations | 6. Security Considerations | |||
| When providing information to a sender, care should be taken to give | When providing information to a sender, care should be taken to give | |||
| information to reasonable and reliable entities. Using this code to | information to reasonable and reliable entities. Providing these | |||
| inform an intentionally malicious sender may have an undesirable | codes to a malicious sender may have an undesirable effect. | |||
| effect. The malicious party could attempt to more easily circumvent | It could help the malicious party circumvent a receiving party's mail | |||
| a receiving party's anti-spam mechanisms. By delaying the 259 until | filtering mechanisms. Delaying the codes until the end of data may | |||
| the end of DATA, that allows for some obfuscation as to which data | obfuscate details of why the message would be considered unwanted. | |||
| points caused the receiver to believe the message to be undesirable. | ||||
| A receiver should take precautions to utilize the 259 response only | ||||
| when speaking with parties they believe will use that data | ||||
| responsibly. This could be accomplished via a number of methods or | ||||
| ACLs. These methods could include IP, CIDR, PTR, DKIM/SPF, ASN, | ||||
| internal reputation mechanisms, and so on. | ||||
| Additionally, as the message resulting in a 259 response is accepted | A receiver should take precautions to provide the enhanced status | |||
| by the remote system, there should not be an NDR to notify the sender | codes only to senders they believe will use that data responsibly. | |||
| that their messages have been regarded as spam. | The method to identify such senders is left up to the receiving | |||
| system. | ||||
| 7. IANA Considerations | 7. IANA Considerations | |||
| An associated Enhanced Status Code will be requested. The code would | IANA is requested to add a block of ten consecutive codes in the | |||
| then be listed in the table at IANA, with a reference to this | x.6.x range to the table of the "Simple Mail Transfer Protocol (SMTP) | |||
| document. | Enhanced Status Codes Registry": | |||
| https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp- | ||||
| enhanced-status-codes.xhtml (https://www.iana.org/assignments/smtp- | ||||
| enhanced-status-codes/smtp-enhanced-status-codes.xhtml) | ||||
| 8. Normative References | +==================+=======================================+ | |||
| | Code: | X.6.20 | | ||||
| +==================+=======================================+ | ||||
| | Sample Text: | Message has 10% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 0-10% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.21 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 20% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 10-20% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.22 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 30% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 20-30% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.23 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 40% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 30-40% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.24 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 50% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 40-50% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.25 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 60% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 50-60% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.26 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 70% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 60-70% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.27 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 80% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 70-80% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.28 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 90% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 80-90% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | ----- | ----- | | ||||
| +------------------+---------------------------------------+ | ||||
| | Code: | X.6.29 | | ||||
| +------------------+---------------------------------------+ | ||||
| | Sample Text: | Message has 100% likelihood of being | | ||||
| | | unwanted, but was accepted | | ||||
| +------------------+---------------------------------------+ | ||||
| | Associated basic | 250 or 550 | | ||||
| | status code: | | | ||||
| +------------------+---------------------------------------+ | ||||
| | Description: | This status code is returned when a | | ||||
| | | message is determined to have 90-100% | | ||||
| | | likelihood of being unwanted. | | ||||
| +------------------+---------------------------------------+ | ||||
| | Reference: | [this document] | | ||||
| +------------------+---------------------------------------+ | ||||
| | Submitter: | A. Brotman | | ||||
| +------------------+---------------------------------------+ | ||||
| | Change | IESG | | ||||
| | controller: | | | ||||
| +------------------+---------------------------------------+ | ||||
| [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | Table 1 | |||
| DOI 10.17487/RFC5321, October 2008, | ||||
| <https://www.rfc-editor.org/info/rfc5321>. | ||||
| 9. Informative References | 8. Informative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An | [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An | |||
| Extensible Format for Email Feedback Reports", RFC 5965, | Extensible Format for Email Feedback Reports", RFC 5965, | |||
| DOI 10.17487/RFC5965, August 2010, | DOI 10.17487/RFC5965, August 2010, | |||
| <https://www.rfc-editor.org/info/rfc5965>. | <https://www.rfc-editor.org/info/rfc5965>. | |||
| End of changes. 28 change blocks. | ||||
| 107 lines changed or deleted | 296 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||