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.

* 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.

* 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.

    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://www.iana.org/assignments/smtp-enhanced-status-codes/sm
> 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