Re: 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/mpcAoMOD
0hsemthvTBWkHJGtNf2iYGJS
=nzaR
-----END PGP SIGNATURE-----