SMTP Enhanced Status Codes for Potentially Unwanted Mail

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

Copyright Notice

Copyright (c) 2022 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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

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

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":¶

Author's Address