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 <ietf-smtp-bounces(_at_)ietf(_dot_)org> On Behalf Of Richard
Clayton
Sent: Thursday, March 31, 2022 5:35 AM
To: ietf-smtp(_at_)ietf(_dot_)org
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-
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/mpcAoMO
D
0hsemthvTBWkHJGtNf2iYGJS
=nzaR
-----END PGP SIGNATURE-----
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp