-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <EDDB8A4D3F9043845213F866@PSB>, John C Klensin <john-
ietf(_at_)jck(_dot_)com> writes
--On Wednesday, March 30, 2022 22:25 +0100 Richard Clayton
<richard(_at_)highwayman(_dot_)com> 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-----
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp