Skip to main content

SMTP Response for Detected Spam
draft-brotman-srds-01

The information below is for an old version of the document.
Document Type Active Internet-Draft (individual)
Author Alex Brotman
Last updated 2022-03-30 (Latest revision 2022-01-14)
Stream (None)
Formats plain text html xml htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-brotman-srds-01
Network Working Group                                         A. Brotman
Internet-Draft                                              Comcast, Inc
Intended status: Standards Track                           30 March 2022
Expires: 1 October 2022

                    SMTP Response for Detected Spam
                         draft-brotman-srds-01

Abstract

   Define a method by which an SMTP receiver can immediately notify a
   sender that their message is suspected to be spam, though is still
   being 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 1 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.

Brotman                  Expires 1 October 2022                 [Page 1]
Internet-Draft                    SRDS                        March 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  The 259 Reply Code  . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Sample conversation . . . . . . . . . . . . . . . . . . .   3
     4.2.  Disclosure of Assuredness . . . . . . . . . . . . . . . .   3
   5.  Rationale for the 259 Response  . . . . . . . . . . . . . . .   4
     5.1.  Receivers . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.2.  Senders . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   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
   spam folder as appropriate.  In some cases, it may be desirable for
   the receiver to provide in-line feedback.  This could be done via the
   SMTP response.  This document proposes a new response code to
   receivers to optionally use to provide this feedback.

   This document is intended as an update to [RFC5321].

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,
   this is more than 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 or some automated system within the
   platform.  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

Brotman                  Expires 1 October 2022                 [Page 2]
Internet-Draft                    SRDS                        March 2022

   Mailbox Provider, this information could allow them to cease delivery
   before incurring further risk to recipients.

4.  The 259 Reply Code

   This document adds the 259 reply code, and defines this as a signal
   to the sender that the receiving system believes the attempted
   message to be malicious or undesirable in some way.  The receiving
   system intends to accept the message, and then deliver this to the
   spam folder of the recipients.  The code SHOULD only be used when the
   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:

   259 OK - Delivering to spam folder

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

   It may be desirable for the receiver to disclose some sort of value
   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)

Brotman                  Expires 1 October 2022                 [Page 3]
Internet-Draft                    SRDS                        March 2022

   Doing so could aid the sender in determining the strength of this
   signal.  Other options could include more detailed information,
   though the receiver should reference the Security Considerations
   before doing so.

5.  Rationale for the 259 Response

   Understandably, there are some questions about what benefit this can
   provide on 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
   you will only filter into the spam folder.  This could help to reduce
   volume into your platform, reduce storage requirements, and generally
   reduce load on your platform.  In the case of an attack, the sender
   could see this signal and terminate the offending sending account.

5.2.  Senders

   As a sender, using this information can help you understand when your
   messages are spam.  Depending on the sources of these messages, that
   could imply that the sender has a bad list of recipients, a malformed
   message, or truly is spam.  An additional possibility is that the
   sending account is compromised or has been created fraudulently for
   the express reason of attempting to send undesirable messages.

6.  Security Considerations

   When providing information to a sender, care should be taken to give
   information to reasonable and reliable entities.  Using this code to
   inform an intentionally malicious sender may have an undesirable
   effect.  The malicious party could attempt to more easily circumvent
   a receiving party's anti-spam mechanisms.  By delaying the 259 until
   the end of DATA, that allows for some obfuscation as to which data
   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.

Brotman                  Expires 1 October 2022                 [Page 4]
Internet-Draft                    SRDS                        March 2022

   Additionally, as the message resulting in a 259 response is accepted
   by the remote system, there should not be an NDR to notify the sender
   that their messages have been regarded as spam.

7.  IANA Considerations

   An associated Enhanced Status Code will be requested.  The code would
   then be listed in the table at IANA, with a reference to this
   document.

   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

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

9.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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, August 2010,
              <https://www.rfc-editor.org/info/rfc5965>.

Author's Address

   Alex Brotman
   Comcast, Inc
   Email: alex_brotman@comcast.com

Brotman                  Expires 1 October 2022                 [Page 5]