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 <ietf-smtp-bounces(_at_)ietf(_dot_)org> On Behalf Of Brotman,
Alex
Sent: Friday, April 1, 2022 1:34 PM
To: ietf-smtp(_at_)ietf(_dot_)org
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 <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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf
-
smtp__;!!CQl3mcHX2A!X_iYwKNNRyptsukvSxeKdca4FEk8ZRNr9CR9kQ57Bhgovq
KXr
tSm1GkxrJiTE3h8bVjsrLuC9Q$
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-
smtp__;!!CQl3mcHX2A!X_iYwKNNRyptsukvSxeKdca4FEk8ZRNr9CR9kQ57Bhgovq
KXrtSm1GkxrJiTE3h8bVjsrLuC9Q$
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp