< 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/