Internet-Draft SRDS April 2022
Brotman Expires 6 October 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-brotman-srds-02
Published:
Intended Status:
Standards Track
Expires:
Author:
A. Brotman
Comcast, Inc

SMTP Enhanced Status Codes for Potentially Unwanted Mail

Abstract

We define a method by which an SMTP receiver can immediately notify a sender that their message is suspected to be unwanted, although it may still be accepted.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 October 2022.

Table of Contents

1. Introduction

Today, a typical SMTP transaction ends with a "250 OK" and the message is then inspected by the receiver and processesd. In some cases, it may be desirable for the receiver to provide in-line feedback to inform the sender that the message may be considered to be unwanted. This could be done via enhanced SMTP status codes. This document proposes new response codes to receivers to provide this feedback.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Background

In the email ecosystem, there exist a few mechanisms by which a receiver or recipient can provide feedback to the sending entity, such as Feedback Reports [RFC5965] or Reputation portals. Historically, these have been out-of-band or delayed. In some cases, sufficient, and properly conveys information to the sender. Given the out-of-band nature, these do not allow for immediate feedback to the sender that their messages may be construed as undesirable by the recipient. By providing this feedback to responsible senders, they may be able to more immediately use that feedback to remediate the responsible party. In the case of an Email Service Provider or Mailbox Provider, this information could allow them to track the quality of mail their users or customers send, and stop the user or customer from sending when the quality is unacceptably low.

4. Enhanced status codes

This document adds ten new enhanced status codes, x.6.20 to x.6.29, to inform a sender that a message was potentially unwanted. The codes MUST only be used in the response after the . that indicates the end of the message. They can be used either in a 250 response to accept the message, or a 550 response to refuse it.

A sample response could be:

250 2.6.23 Message accepted, 40% chance of being unwanted.

or conversely

550 5.6.28 Message refused, 90% chance of being unwanted

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.

4.1. Sample conversation

...
C:DATA
S:354 OK
C:From: Bob@example.com
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 enhanced status codes

Senders would use these codes when they expect a benefit to both the sending and receiving side. This should be considered from both sides and understand that this could allow for a more collaborative interaction.

5.1. Receivers

Receivers could realize some benefit from deploying this signal. The signal could help deter senders from continuing to send messages that their users do not want. This could help to reduce volume into thri platform, reduce storage requirements, and otherwise reduce incoming mai, load. In the message is part of an attack, the sender could see this signal and block mail from the account.

5.2. Senders

A sender can use this information to help understand when messages from its customers or users are unwanted by recipients. Depending on the sources of these messages, that could imply that the sender has a bad list of recipients, a malformed message, or other problems. An additional possibility is that the sending account is compromised or has been created fraudulently for the express reason of attempting to send unwanted messages.

6. Security Considerations

When providing information to a sender, care should be taken to give information to reasonable and reliable entities. Providing these codes to a malicious sender may have an undesirable effect.
It could help the malicious party circumvent a receiving party's mail filtering mechanisms. Delaying the codes until the end of data may obfuscate details of why the message would be considered unwanted.

A receiver should take precautions to provide the enhanced status codes only to senders they believe will use that data responsibly. The method to identify such senders is left up to the receiving system.

7. IANA Considerations

IANA is requested to add a block of ten consecutive codes in the x.6.x range to the table of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry":

Table 1
Code: X.6.20
Sample Text: Message has 10% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.21
Sample Text: Message has 20% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.22
Sample Text: Message has 30% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.23
Sample Text: Message has 40% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.24
Sample Text: Message has 50% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.25
Sample Text: Message has 60% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.26
Sample Text: Message has 70% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.27
Sample Text: Message has 80% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.28
Sample Text: Message has 90% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG
----- -----
Code: X.6.29
Sample Text: Message has 100% likelihood of being unwanted, but was accepted
Associated basic status code: 250 or 550
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 controller: IESG

8. Informative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5965]
Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, DOI 10.17487/RFC5965, , <https://www.rfc-editor.org/info/rfc5965>.

Author's Address

Alex Brotman
Comcast, Inc