SMTP Response for Detected Spam
draft-brotman-srds-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Alex Brotman | ||
| Last updated | 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-00
Network Working Group A. Brotman
Internet-Draft Comcast, Inc
Intended status: Standards Track 14 January 2022
Expires: 18 July 2022
SMTP Response for Detected Spam
draft-brotman-srds-00
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 18 July 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 18 July 2022 [Page 1]
Internet-Draft SRDS January 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. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . 4
8. Informative References . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
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 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
Mailbox Provider, this information could allow them to cease delivery
before incurring further risk to recipients.
Brotman Expires 18 July 2022 [Page 2]
Internet-Draft SRDS January 2022
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)
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.
Brotman Expires 18 July 2022 [Page 3]
Internet-Draft SRDS January 2022
5. Security Considerations
When providing information 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 reciever to believe the message to be undesirable.
A receiver should take reasonable 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,
and so on.
6. 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)
7. Normative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
8. 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
Brotman Expires 18 July 2022 [Page 4]
Internet-Draft SRDS January 2022
Alex Brotman
Comcast, Inc
Email: alex_brotman@comcast.com
Brotman Expires 18 July 2022 [Page 5]