Re: Updated draft for "SMTP Response for Detected Spam"

--On Wednesday, March 30, 2022 22:25 +0100 Richard Clayton
<[email protected]> wrote:

> In message <[email protected]>, Claus
> Assmann <ietf- [email protected]> writes
> 
>> Please don't use up all the 25x codes,
>> use the enhanced status code for this purpose.

Claus,  Yeah.  See the note I just posted for an extra reason or
two to use enhances codes rather than making up a new primary
one. 


> Since the receiver knows the message is spam I was wondering
> why the code was 259 rather than 559 ...
> 
> ... also, the text mentions all sorts of terms of art like
> "spam folder" and "Email Service Provider" which I can't find
> in RFC5598 or defined in later sections (assuming that their
> meaning is relevant ?)

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.

As Dave Crocker has at least hinted, there are several other
issues with (or at least questions about) this document.  As one
example, if one looks at SMTP, the introductory paragraph of
this I-D is just plain wrong.   All SMTP does is move mail
transactions from a sender-SMTP to a receiver-SMTP.  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).  As Dave
also more or less suggested, if a version of this document were
to be considered for Standards Track, I think all of those
issues would need to be sorted out.  For an Experiment, some of
them could probably be deferred.

   john