Re: Updated draft for "SMTP Response for Detected Spam"

Thanks for all the feedback.  JohnL graciously created an updated draft that proposes enhanced codes instead of the standard code.

https://www.ietf.org/archive/id/draft-brotman-srds-02.txt
https://datatracker.ietf.org/doc/draft-brotman-srds/

I hope folks will find this more agreeable (other than still pointing at Standards Track).  Thanks again for feedback.

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

> -----Original Message-----
> From: ietf-smtp <[email protected]> On Behalf Of Brotman, Alex
> Sent: Friday, April 1, 2022 1:34 PM
> To: [email protected]
> Subject: Re: [ietf-smtp] Updated draft for "SMTP Response for Detected Spam"
>
> Hey folks,
>
> Thanks for all the feedback.  I can work on some of the wording around "spam"
> to make it more generic.  As to the idea of making this Experimental, and using
> only an enhanced code, I think that's a fine idea.   I'd be happy if this were to
> eventually become a part of the "5321bis" effort, though that doesn't seem
> necessary (especially to run this as a trial).
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
>
> > -----Original Message-----
> > From: ietf-smtp <[email protected]> On Behalf Of Richard
> > Clayton
> > Sent: Thursday, March 31, 2022 5:35 AM
> > To: [email protected]
> > Subject: Re: [ietf-smtp] Updated draft for "SMTP Response for Detected
> Spam"
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > In message <EDDB8A4D3F9043845213F866@PSB>, John C Klensin <john-
> > [email protected]> writes
> >
> > >--On Wednesday, March 30, 2022 22:25 +0100 Richard Clayton
> > ><[email protected]> wrote:
> >
> > >> Since the receiver knows the message is spam I was wondering why
> > >> the code was 259 rather than 559 ...
> > >
> > >Richard, as I understand the text, the plan is to tell the
> > >sender-SMTP that the message is believed to be spam, but then
> > >deliver it to one of those "spam folders" anyway.   That calls
> > >for a 2yz code (I think 250 with one or more new enhanced status
> > >codes for different cases) because returning a 5yz code and then
> > >delivering the message anyway (no matter to whom and which folders,
> > >whatever a folder is) would be a rather serious violation of the SMTP
> > >specification and model.
> >
> > I was aware of that :-) ... my point being, as I'm sure you know but I
> > want to labour it, that "spam folders" are not actually used for spam
> > (people would hate it if every possible message addressed to them was
> > actually accepted! they'd receive 6 to 10 times as many messages as
> > they do at present)
> >
> > Spam folders are a common (but not ubiquitous) mechanism for the
> > temporary storage of messages where the MTA, despite all the machine
> > learning and heuristics, cannot be entirely sure whether or not the
> > message is actually going to be wanted by the recipient, but on balance it is
> felt to be unlikely.
> >
> > But given that the intent of 259 is to allow "grown-ups" to adjust
> > behaviour dynamically in the middle of mail sending campaign, a 559
> > serves pretty much the same purpose of forcing a rethink.
> >
> > Perhaps a rewrite which doesn't use such ill-defined terms as "spam"
> > will make it more obvious that there are message which an MTA is
> > prepared to accept, but somewhat reluctantly.
> >
> > >If we are
> > >talking about an "inbox" or some sort of folder, that isn't about
> > >SMTP any more.  It might be something specific to what SMTP calls the
> > >final delivery server or system, but there we need to start thinking
> > >about exactly how to define what is often known as a Message Delivery
> > >Agent
> > >(MDA) and, while we use the term informally and there is at least one
> > >clear definition (in RFC 5598), there has never been a
> > >standards-track specification for what one of those does and how it
> > >behaves (i.e., one paralleling RFC 6409 at the other end of the pipeline).
> >
> > When the IETF strays from "on the wire" then what it proposes, or the
> > language it uses (one might soon need a dictionary to understand the
> > notion of
> > "secretary") seldom stands the test of time -- because it's no longer
> > about interoperability but about user convenience or developer innovation ...
> >
> > - --
> > richard                                                   Richard Clayton
> >
> > Those who would give up essential Liberty, to purchase a little
> > temporary Safety, deserve neither Liberty nor Safety. Benjamin
> > Franklin 11 Nov 1755
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPsdk version 1.7.1
> >
> >
> iQA/AwUBYkV1q92nQQHFxEViEQJWMgCfRHiIxqiG8c0Rgxgxl6hWjNu/mpcAoMO
> > D
> > 0hsemthvTBWkHJGtNf2iYGJS
> > =nzaR
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > ietf-smtp mailing list
> > [email protected]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf
> > -
> smtp__;!!CQl3mcHX2A!X_iYwKNNRyptsukvSxeKdca4FEk8ZRNr9CR9kQ57Bhgovq
> KXr
> > tSm1GkxrJiTE3h8bVjsrLuC9Q$
>
> _______________________________________________
> ietf-smtp mailing list
> [email protected]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-
> smtp__;!!CQl3mcHX2A!X_iYwKNNRyptsukvSxeKdca4FEk8ZRNr9CR9kQ57Bhgovq
> KXrtSm1GkxrJiTE3h8bVjsrLuC9Q$