Re: [ietf-smtp] Updated draft for "SMTP Response for Detected Spam"

["Brotman, Alex" <[e-mail]>]

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 <[e-mail]> On Behalf Of Richard Clayton
> Sent: Thursday, March 31, 2022 5:35 AM
> To: [e-mail]
> 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-
> [e-mail]> writes
>
> >--On Wednesday, March 30, 2022 22:25 +0100 Richard Clayton
> ><[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-smtp