Re: SMTP Code for Undesirable Messages

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: John C Klensin <[email protected]>
> Sent: Thursday, January 13, 2022 12:54 PM
> To: Brotman, Alex <[email protected]>
> Cc: Murray S. Kucherawy <[email protected]>; [email protected]
> Subject: Re: SMTP Code for Undesirable Messages
>
> (Note that, as Murray suggested, I've moved this response to the SMTP list
> from DISPATCH.  I obviously think that is good advice.
> More inline.)
>
> --On Thursday, January 13, 2022 15:06 +0000 "Brotman, Alex"
> <[email protected]> wrote:
>
> >   1.  I'd asked someone who spends more time working within the IETF,
> > and dispatch was their suggestion.  I'm happy to take it anywhere else
> > that is suggested.
>
> >  2.  I'm not
> > opposed to both.  I suspect there will be a fair bit of discussion
> > about the general idea of the proposal, and this had already crossed
> > my mind.  I would imagine there are some MTAs that may not understand
> > enhanced codes, though that may mean they wouldn't know how to deal
> > with any new response codes at all.
>
> Just some quick comments:
>
> * For conventional response codes, RFC 5321 specifies exactly how
> unrecognized codes are handled, so "wouldn't know how to deal with..." is
> not possible for a conforming implementation.
> A quick review of RFC 3463 (the Enhanced Status Code definition) suggests it
> is less explicit but there is at least implicit
> guidance there too.    So I don't see that particular issue as a
> problem.

Ah, okay, thank you.  That certainly helps.

>
> * The bigger problem --one that, IIR, we discussed before what became 5321
> was completed -- is that a message identifying the reason for rejection of an
> incoming message was a determination that it was spam is that such a
> message would give the spammer for too much information and would
> encourage retries with modified messages in an attempt to beat the anti-
> spam system.
> It is possible that things have changed and the idea would be better received
> today but I would think that any proposal today would have to address that
> issue.
>

The receiving site can optionally choose to not give this response, or give it only in certain situations.  I understand the hesitancy though.  If the site admin were to deem it too dangerous or believes it leaks too much data, that's understandable.  Hopefully the MTA authors would provide a configuration flag.  However, there could be situations where notifying the sender could help them fight abuse coming from their system.  Today, many platforms do this already, though usually without accepting the messages.  We routinely see sites that say they're rejecting a message due to questionable content.

For example, taken from logs:

"Permanent failure: 554-10 BAYES_99 BODY: Bayesian spam probability is 99 to 100%\r\n554-[score: 1.0000]\r\n554-0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%\r\n554-[score: 1.0000]\r\n554-2.5 MDAEMON_SPF_SOFTFAIL MDaemon: soft-failed SPF verification\r\n554-0.8 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar to\r\n554-background\r\n554-0.0 HTML_90_100 BODY: Message is 90% to 100% HTML\r\n554-1.0 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME\r\n554-0.1 HTML_TAG_EXIST_TBODY BODY: HTML has \"tbody\" tag\r\n554-0.0 T_KAM_HTML_FONT_INVALID Test for Invalidly Named or Formatted\r\n554-Colors in HTML\r\n554-0.8 RDNS_NONE Delivered to internal network by a host with no rDNS\r\n554-1.0 FONT_INVIS_POSTEXTRAS Invisible text + suspicious URI\r\n554-0.0 NORDNS_LOW_CON
 TRAST No rDNS + hidden text\r\n550 5.6.0 Sorry, message looks like SPAM to me\r\n"

The difference would be that the receiver would still accept the message, and (ideally) wouldn't divulge as much information. This is meant to formalize a response where the receiver accepts the mail for delivery, though also notes that they believe it to be spam and will route it accordingly.

> * While a discussion on this list might be helpful, my experience has been
> that the IETF is far better at dealing with specific proposals in I-D form, even if
> it ends up changing them significantly, than with more general discussions on
> mailing lists.  No suggestions about how you determine when the point has
> been reached that a proposal in I-D form is needed, but you should at least
> watch for symptoms of trying to create the details of such a proposal in a
> mailing list discussion.

Understood. I'll polish it up a bit and send it into the ietf-smtp list.

>
>     john
>
>
> > From: Murray S. Kucherawy <[email protected]>
> > Sent: Wednesday, January 12, 2022 10:44 AM
> > To: Brotman, Alex <[email protected]>
> > Cc: [email protected]
> > Subject: Re: [dispatch] SMTP Code for Undesirable Messages
> >
> > On Fri, Dec 17, 2021 at 9:05 AM Brotman, Alex
> > <[email protected]<mailto:40comcast.co
> > [email protected]>> wrote: I've been wondering if it may be beneficial
> > for a mailbox provider to be able to signal back to the sender that
> > the message is being accepted, but is undesirable based on some
> > criteria.  The idea would be that a provider may evaluate some
> > characteristics of the message, and before issuing a "250 Ok" have
> > already determined the message would be routed to the spam folder.
> > Something as simple as:
> >
> > 255 Ok - Routing to spam folder
> >
> > This would likely need some "Security Considerations" section about
> > how informing a malicious entity may be undesirable.
> > I'm willing to write this up as a proposed draft, though I'm not
> > entirely sure where to direct that draft.  Thank you for any advice
> > you could provide.
> >
> > Two things, one substantive and one procedural:
> > (1) On procedure: This might be better raised on either the SMTP
> > mailing list or the ART mailing list.  DISPATCH is mostly for talking
> > about live or proposed work items, like when there's a draft ready to
> > bring to the table for disposition.
> >
> > (2) On substance: Why not register an enhanced status code for this
> > instead of a new SMTP reply code?  See
> > https://urldefense.com/v3/__https://www.iana.org/assignments/smtp-
> enha
> > nced-status-codes/sm__;!!CQl3mcHX2A!SBTilEV0esdxpIP59dB2Donw5EgS-
> JHO2M
> > sRzjhkbt2S7UnMQtM3YJcKl9RYzCEAilFR$
> > tp-enhanced-status-codes.xhtml<https://urldefense.com/v3/__htt
> > ps:/www.iana.org/assignments/smtp-enhanced-status-codes/smtp-e
> > nhanced-status-codes.xhtml__;!!CQl3mcHX2A!QZTAt9Rk-meQu68EGjOK
> > 04SCXItePuipk4VkJXnY06PoqLxHr3flYy6-PsUqvno_cjMc$> and the RFC it
> > references.
> >
> > -MSK
>