Subject: Re: [ietf-smtp] Updated draft for "SMTP Response for Detected Spam"

From: Alessandro Vesely <[email-masked]>
Date: Fri, 1 Apr 2022 12:19:30 +0200

On Wed 30/Mar/2022 19:37:27 +0200 Brotman, Alex wrote:
> Hey folks,
> 
> I wanted to send an update for this draft.  I received (negative) feedback from one person via the list, though several outside of the list were supportive.  I wanted to try to clear up some of the language in the draft.  Appreciate feedback from those who are interested to read.
> 
> https://www.ietf.org/archive/id/draft-brotman-srds-01.txt
> https://datatracker.ietf.org/doc/html/draft-brotman-srds-01

I think the last paragraph in Security Considerations doesn't belong there.

    Additionally, as the message resulting in a 259 response is accepted
    by the remote system, there should not be an NDR to notify the sender
    that their messages have been regarded as spam.

AIUI, it says it spares the sender the need to produce an NDR.  I that case, it 
should go to Section 5.2.

However, in some cases —when the message is not bulk— an NDR-like thing would 
be useful, so the sender can text the recipients to look in their spam folders. 
  The (non capitalized) should must not be understood as a prohibition to do that.

As for the code/ extended status question, I agree that shortage of digits 
demands to think twice before allocating one.  However, while the dotted format 
introduced by RFC 3463 enjoys the boundlessness of natural numbers, those 
tokens are difficult to understand, often inexact and not universally supported.

In case 259 is not going to be used, I'd suggest to experiment with keywords 
rather than with extended status code.  To wit, when writing regular 
expressions to catch specific responses, I'd find it much easier to write 
something like:

/^.*courieresmtp: id[^,]*,from=[^,]*,addr=[^>]*>:.2\d\d.*\bMAYBESPAM\b/

rather than:

/^.*courieresmtp: id[^,]*,from=[^,]*,addr=[^>]*>:.2\d\d.2\.[67]\.1[123]?/

And I'd guess the former would be much more reliable than the latter.

Best
Ale
--

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 1 Apr 2022 17:33:59 +0000

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 <[email-masked]> On Behalf Of Richard Clayton
> Sent: Thursday, March 31, 2022 5:35 AM
> To: [email-masked]
> 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-
> [email-masked]> writes
>
> >--On Wednesday, March 30, 2022 22:25 +0100 Richard Clayton
> ><[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 4 Apr 2022 17:46:16 +0000

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.

> From: ietf-smtp <[email-masked]> On Behalf Of Brotman, Alex
> Sent: Friday, April 1, 2022 1:34 PM
> To: [email-masked]
> 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
>
> > >> 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
> > >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.
> >
> > 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
> > >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
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf
> > -
> smtp__;!!CQl3mcHX2A!X_iYwKNNRyptsukvSxeKdca4FEk8ZRNr9CR9kQ57Bhgovq
> KXr
> > tSm1GkxrJiTE3h8bVjsrLuC9Q$
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-
> smtp__;!!CQl3mcHX2A!X_iYwKNNRyptsukvSxeKdca4FEk8ZRNr9CR9kQ57Bhgovq
> KXrtSm1GkxrJiTE3h8bVjsrLuC9Q$

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Apr 2022 16:18:50 -0400

Good idea Alex.

I like and support this idea for a "259" reply code to indicate a 
message was accepted but imported/move to the MSA/MDA "spam" folder.  
This can drastically reduce/address support questions regarding 
unsolved non-inbox deliveries.   I can add support to Wildcat! SMTP as 
an experiment.

I take it, there are no legacy clients who will "fail" on a 259 reply 
code.  I think overall, 259 or just 250, MSA/MDA receivers should help 
delivery support issues by describing inbox versus non-inbox reception 
in the acceptance response text.

In fact, it should be extended to beyond spam, for example, mail 
accepted but discarded for local policy reasons.  I hope Google would 
support this because I have a few cases where customer mail is 
received (250 positive response) by gmail but are not delivered, nor 
found in any folder, i.e. as if it was discarded.

Thanks

On 3/30/2022 1:37 PM, Brotman, Alex wrote:
> Thanks

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos