Re: [EXTERNAL] Re: Updated draft for "SMTP Response for Detected Spam"

I wanted to use a code for some of the reasons below.  I would like to avoid a sender to having to guess at what the response means, whether it be a standard/extended code.  Senders (of all sorts) have to do entirely too much of that already.  Some receivers are intentionally vague, and then senders are left wondering if it's a me/you problem, or something else entirely.  I've seen several presentations about how someone is using ML to try to infer what the MBP means.  Hopefully this makes it easier to get helpful information.

As for the use case, the primary driver is to provide feedback to senders (again, of all sorts) so if they can recognize they're doing something bad, they may be able to lessen the abuse.  I'm not overly worried about divulging the information to malicious actors.  If it were an ESP, I'd hope they can either identify a spammer in their platform, or fire one who appears to be doing testing (and I’m not sure what kind of logs they share with customers anyway).  For an MBP, it's not likely that the sender/customer would get a notification of a successful delivery.  There's a section in the draft that talks about only using this with "trusted" partners/senders via some sort of ACLs.  I wouldn't imagine a MBP would use 259 with a netblock assigned to a wireless carrier's end-user space for example.

John, I see your point about defining the extension.  The receiver can't respond 259 (if this were deployed at large) unless they're reasonably sure the sender will treat it properly (as a successful delivery).

Thanks so far folks, much appreciated.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: John Levine <[email protected]>
> Sent: Wednesday, March 30, 2022 2:08 PM
> To: [email protected]
> Cc: Brotman, Alex <[email protected]>
> Subject: [EXTERNAL] Re: [ietf-smtp] Updated draft for "SMTP Response for
> Detected Spam"
>
> It appears that Brotman, Alex <[email protected]> said:
> >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.
>
> I'm still not thrilled but anyway
>
> It needs to define an SMTP extension so servers know that they can reply 259
> rather than 250 at the end of data, e.g.
>
> ehlo cruddy.mail.org
> 250-sceptical.server.com
> 250-STARTTLS
> 250-PIPELINING
> 250-ENHANCEDSTATUSCODES
> 250 MAYBESPAM
>
> mail from:<[email protected]> MAYBESPAM
> 250 2.1.0 Sender accepted.
>
> rcpt to:<[email protected]>
> 250 2.1.0 Recipient accepted.
>
> Although there used to be server replies that contained strings for the client to
> parse, they're all obsolete and these days clients only look at the three digit
> status code and the three part extended status code.
> Don't have a great suggestion for how else to encode it other than maybe a
> range of enhanced status codes 2.6.20 through 2.6.29 for spam scores 0/10 to
> 9/10.
>
> R's,
> John
_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp