SMTP Response for Detected Spam

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 .

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.

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.

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