SMTP Response for Detected Spam
Comcast, Inc
alex_brotman@comcast.com
Applications
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.
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 .
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
.
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 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.
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
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
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.
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.
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.
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.
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.
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.
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
Normative References
Informative References